模型上線後，真正折磨人的是這五件事

去年我們幫一家做智慧客服的新創公司部署 RAG 系統。模型選型、資料清洗、Prompt 調優，這些「體面」的工作花了三週。上線第一天，客戶說「效果還行」。

然後惡夢開始了。

第一件事：Token 帳單比預期貴三倍

客戶給的預估 QPS 是 50，實際峰值衝到 200。更麻煩的是，他們把完整的使用者歷史對話都塞進上下文視窗——每條請求平均 4000 token 輸入，模型返回 800 token。

我們做了三件事：
- 用滑動視窗把上下文截斷到最近 20 輪對話
- 對超過 3 天的歷史做摘要壓縮
- 在閘道層加了 QPS 限流和排隊機制

結果：單次請求 token 量降到 1200 左右，月帳單從預估的 8000 塊壓到 3500 塊。

教訓：永遠按峰值的 1.5 倍做成本預算，別信客戶給的「正常值」。

第二件事：GPU 顯存洩漏，每週必崩

用的是開源模型 + vLLM 部署。一切正常，直到第七天——顯存佔用從 14GB 慢慢爬到 24GB，然後 OOM 崩潰。

排查發現是 vLLM 的 KV cache 在特定 batch size 下沒有正確釋放。臨時方案是寫了一個監控腳本，顯存超過 20GB 就自動重啟服務。根治方案是升級到最新版 vLLM 並調整 max_num_batched_tokens 參數。

教訓：開源模型部署不是「跑起來就行」，必須做顯存監控和自動恢復。

第三件事：客戶的資料格式每天都在變

第一天給的是 JSON，第二天變成了 CSV，第三天直接甩了個 Excel 過來，裡面還有合併儲存格。

我們被迫在資料接入層寫了一個「萬能解析器」，支援 JSON、CSV、Excel、甚至 PDF 表格提取。同時加了資料 schema 校驗，不符合格式的直接在接入層攔截，返回明確的錯誤訊息。

教訓：客戶不會按你的規範來。接入層要足夠寬容，校驗層要足夠嚴格。

第四件事：效果回退沒人通知

上線第三週，客服的滿意度評分從 85% 掉到 72%。客戶沒告訴我們，直到月底對帳時才發現。

原因是客戶那邊換了資料來源，新資料的標註品質差了很多。我們加了一個效果監控面板，每天自動跑 200 條樣本的準確率評估，低於閾值就發告警。

教訓：模型效果不是上線就結束的事，必須持續監控，而且監控指標要和客戶關心的業務指標對齊。

第五件事：回滾方案根本沒準備

有一次我們更新了指向的模型版本，結果新版本的輸出格式變了，下游解析全部報錯。因為沒有回滾腳本，花了兩個小時才恢復。

後來我們建立了標準流程：每次模型更新前，先在小流量（5%）上灰度，跑滿 24 小時沒問題再全量。同時保留上一個版本的映像檔和設定，一鍵回滾。

教訓：沒有回滾方案的上線，就是在賭博。

寫在最後

做 AI 專案交付，模型本身可能只佔 30% 的工作量。剩下的 70% 是工程維運——成本控制、穩定性保障、資料治理、效果監控、變更管理。

這些工作不性感，但決定了專案能不能活過第一個月。