生產環境

一個很快的 GPU process 還不是正式服務。先封裝可重現的 runtime，量出 concurrency envelope，用有限 queue 保留超額工作，在延遲失守之前增加 replica，依可用狀態把請求送到正確目的地，並讓 cold start 足夠短，使 scaling policy 能及時反應。容量與 failure domain 要刻意配置，上線要依 live evidence 逐步推進，資料與 weights 要受到保護，成本要算入 total cost of ownership（TCO），觀測則要涵蓋整個請求。time to first token（TTFT）和 tokens per second（TPS）固然重要，但 client setup、network、queue 與 protocol 也會消耗 service-level agreement（SLA）的預算。

先建立 immutable serving artifact。Container image 由經過驗證的 base、精確的 application 與 system dependency、configuration，以及執行時才出現的 ephemeral layer 疊成。鎖定版本並刪除未使用套件，讓 image 可重現、更小、更快搬移，也更容易 audit。大型 model weights 如果遠大於 image，就應分開存放；compiled engine 只能搭配它所要求的完全相同硬體與軟體 identity 來 cache 和重用。

2026 年 1 月版快照：NVIDIA Inference Microservices（NIMs）把受支援的 model 與 GPU 組合封裝成現成 container，包含較彈性的模型家族 image，以及針對特定模型高度最佳化的 image。它可以直接成為服務、reference implementation 或 base layer。經過測試的 opinionated configuration 若符合需求，可以縮短上線時間；若產品限制需要更深控制，從較低階 base 開始通常比硬改既定方案清楚。

設定 autoscaling 前先量出 replica envelope。Continuous batching 會在 slot 釋出時加入新 sequence；較大的 active batch 能增加 aggregate throughput，也會讓每個請求變慢。Engine batch limit 與 autoscaler concurrency target 必須來自同一組測試。Traffic signal 能提前預測需求，GPU utilization 則能揭露昂貴 sequence shape，兩者要一起使用；再加上 measurement window、最小與最大 replica、cooldown，以及對 forecast error 的 headroom，policy 才不會對短暫雜訊過度反應。

Scale-up decision 只有在 replica ready 之後才產生價值。把 cold start 拆成 hardware allocation、image transfer、weight transfer 與 engine startup；縮小 bytes、把 cache 放在靠近 GPU 的位置，並在相容條件下安全重用 compiled artifact。容量到達前，用有限的 first-in-first-out 或 priority queue 保留工作。Replica ready 後，依 load、sequence length、key-value prefix state 或 low-rank adaptation（LoRA）weights routing，並立刻把 queued work 填到新 replica 的 concurrency limit。

跨出單一 cluster 後，要把 global control plane 與能獨立持續服務的 workload plane 分開。Reserved capacity 承接 baseline demand，on-demand 或可中斷資源處理 peak；workload 要靠近使用者，同一個 multi-stage request 內則避免 cross-cluster hop。Active-active region 平時就承載 live traffic，故障時能平順切換；active-passive 降低常態使用量，但 standby readiness 必須反覆驗證。Security policy 要涵蓋 user data、model weights、infrastructure access、encryption、isolation、retention 與 geographic processing constraint。

Deployment 本身就是 capacity event。先做 manual test 與 load test，再 shadow 一部分真實 traffic。Canary 讓新版本從很小的 live volume 開始，觀察 correctness、latency、error、quality 與 scaling，再依 guardrail 分段增加流量。Rollback 要隨時可用，每一步也要先 warm 足夠 replica；否則量到的會是 cold queue，而不是新服務。這種方法不需要像 blue-green cutover 一樣先準備完整的雙倍 GPU fleet。

成本應至少用具有代表性的一週來估算。先依 input、output 與 cache behavior 計算 application programming interface（API）帳單，再與 dedicated hardware 在真實 utilization、batch 與 sequence distribution 下的成本比較，並把工程與維運工時納入 TCO。觀測時要把 request volume、sequence size、response code、percentile latency、replica state、host 與 accelerator utilization、queue depth 放在一起；server log 與 change audit 才能解釋這些數值為何同時移動，並支援快速 rollback。

Client 也是 inference 的一部分。重用 transport layer security（TLS）session，避免每個請求重付 setup；若 P95 端到端延遲目標是 300 毫秒，TLS handshake 就可能占掉至少一成預算。有限時間的呼叫使用同步 Hypertext Transfer Protocol（HTTP）；重視 throughput 的長工作用 async job 與 webhook；連續、較少結構的雙向 stream 用 WebSocket；具有固定 schema 的 service communication 則用 gRPC。WebSocket 適合未結構化即時資料；gRPC 則以預先定義的 schema 與 validation 支援結構化雙向 stream。

想像一次 traffic burst 正好發生在 scale-down 之後，所有 replica 很快到達 concurrency limit。Queue 能保存已被接受的工作，但 oldest age 會開始消耗 SLA；它不是可以無限延長的倉庫，而是一個正在倒數的 deadline buffer。Traffic rate 與 active concurrency 應比單看 utilization 更早觸發 scale-up，controller 同時用實測 cold-start distribution 推估新 replica 能否在 deadline 前 ready。若 max replica 仍不足，admission policy 必須拒絕、降級或延後低優先工作，不能接受明知無法及時完成的請求。新 replica ready 後要立刻被 router 發現，但只能接收到它實測 envelope 允許的 queued work，否則剛啟動就再次 overload。需求下降後，cooldown 要跨過常見的第二波，而不是看到瞬間空檔就縮容。這個 scenario 同時測試 queue、concurrency、autoscaling、cold start、routing 與 admission；steady-state throughput test 只證明 engine 在流量穩定時能跑多快，無法證明整個 feedback loop 在突波時會保住使用者延遲。

接著在持續流量下移除一個 GPU node，再讓一個 region 失聯。Health automation 必須停止新 placement、cordon 有問題的 node、替換受影響 replica，並把 regional demand 移往其他 capacity，同時遵守 data-location policy，不能為了快速 failover 把受限制資料送到錯誤國家。即使 global controller 暫時不可用，既有 workload plane 仍應繼續接受並處理本地流量；這是 control plane 與 workload plane 分離真正要保護的能力。Active capacity 要能吸收轉移，standby capacity 則要用演練證明它真的載有正確 image、weights、keys、network policy 與 routing rule，而不是只存在於 inventory。Operator 透過 audit log 追蹤 interrupted request、deployment change、access 與可能的 model-state exposure。Recovery 不能只以 replacement process 啟動為終點；必須確認 latency、error rate、queue age、capacity margin、replica health 與 security control 全部回到明定範圍，並保存 timeline 供後續修正 runbook。

Incident timeline 要把 product、system 與 cost signal 串在一起。某次 deployment 可能讓 input sequence 變長，接著提高 prefill utilization、加深 queue、觸發更多 replica；大量 replica 同時啟動又會競爭 image 與 weight bandwidth，讓 cold start 變慢，最後同時推高 latency 和 spend。只看其中任何一張圖，都可能得到錯誤修法，例如盲目增加 max replica，反而讓啟動競爭更嚴重。應在同一個 request identity 與 time window 下連結 release identity、request shape、routing choice、cache behavior、queue age、replica lifecycle、client timing、response code 與 cost allocation。Operator 先判斷 causal chain，再選擇 rollback、限制輸入、調整 routing、增加 bandwidth 或擴容，並觀察下游 signal 是否按預期恢復。同一份 record 也能在事後回答 economics：把 idle headroom、failover reserve、測試 GPU、transfer 與 engineering labor 納入 TCO 後，dedicated capacity 是否仍優於 API；若答案只在理想 utilization 下成立，就還不是可持續的 production decision。

Data handling 要直接寫進 serving contract。若 request input 與 model output 在工作完成後沒有用途，最安全也最省事的做法就是不保存，從源頭縮小 attack surface；不能因為 logging 預設方便，就長期留下使用者內容。若 quality review、audit 或 future training 確實需要 retention，收集之前要先定義 purpose、允許 region、保存時間、encryption、access role、deletion workflow、使用者約定與 incident evidence，並確認 provider 也能執行相同要求。規則不能只套用 primary database；model weights、server log、prompt cache、queue payload、object storage、debug dump、temporary file 與備份都可能殘留敏感內容，也要有相同 inventory、access control 與清除期限。多個 cloud provider 之間的 portability 只有在每個 destination 都維持同等 control、compliance 與 geographic restriction 時才有價值；若 failover 會把資料送出允許範圍，可靠度設計本身就製造了 security incident。