# 模型在筆記本裡跑得再好，憑什麼上線就垮？少了這層殼 模型在 Jupyter 筆記本裡準確率再高，只要還躺在筆記本裡，對業務就是零價值。想讓它產生影響，就… · @swordBluesy · TwKit

@swordBluesy

# 模型在筆記本裡跑得再好，憑什麼上線就垮？少了這層殼 模型在 Jupyter 筆記本裡準確率再高，只要還躺在筆記本裡，對業務就是零價值。想讓它產生影響，就得把它包成一個能可靠接進應用系統的 API，還要能扛住流量。原文約 2026 年 10 月 27 日發布。 ## 這篇解決什麼 路線是三段：FastAPI 包推理邏輯、Docker 包成可複現的容器、Kubernetes 管擴容和可用性。外加三件上線必備的事：認證、資源限制、監控延遲和資料漂移。原文先把觀念講清：第一次上線的人最容易犯的錯，是把推理邏輯直接耦合在 HTTP 處理函式裡，沒有驗證、沒有錯誤處理，生產環境一出錯就全垮。 ## 動手步驟 第一步，用 FastAPI 包推理。FastAPI 的好處是三樣：非同步支援，能同時處理多個高併發推理請求；自動生成互動式 API 文件，別人不用猜介面怎麼用；Pydantic 內建資料驗證，輸入格式不對先攔下來。範例程式是這樣的：載入 joblib 存的 model.pkl，定義 InputData，兩個浮點欄位 feature1 和 feature2，POST 到 /predict/，回傳 prediction.tolist()。模型要在啟動時載入一次，不要每個請求都重載。 第二步，用 Docker 包成容器。Dockerfile 用 tiangolo/uvicorn-gunicorn-fastapi:python3.8 當基礎映像，把 /app 複製進去、工作目錄設 /app、裝 requirements.txt，最後用 uvicorn main:app、監聽 0.0.0.0 的 80 埠啟動。這一步的價值是環境一致：本機跑得起來的地方，打包之後到哪都一樣。 第三步，用 Kubernetes 管擴容。部署設定叫 fastapi-inference，副本數 3，匹配標籤 app: fastapi-inference，容器埠 80；再加一個 Service，類型 LoadBalancer，埠 80 轉到目標埠 80。Kubernetes 的價值也是三樣：按需求自動擴容、內建負載均衡把請求分到多個實例、容器掛了自動重啟、健康管理保證高可用。 ## S1哥觀點 這篇最值得記住的是一句話：模型是軟體資產，不是實驗結果。實驗結果只要準，軟體資產還要介面、限制、失敗模式，缺一樣，上線就等於裸奔。 爭論點在這裡：有人說小服務根本用不上 Kubernetes，Docker 加一台機器就夠了。這話對了一半：流量小的時候確實夠，但「夠」和「能扛」是兩回事，流量一來、容器一掛，沒有編排層就是手工救火。先把 FastAPI 和 Docker 這層殼包好，再談要不要上 Kubernetes，順序不能反。另外提醒一句：原文範例用的基礎映像版本偏舊，照抄之前先核對當前版本，別把舊版當成最新版。 原文連結：https://bugfree.ai/knowledge-hub/scaling-inference-fastapi-kubernetes 原文：Bugfree（由 S1哥 編譯）

曝光 231 · 评论 2 · 点赞 3 · 书签 0