推論

訓練建立模型 weights，推論則讓這些 weights 實際處理生產請求。傳統機器學習模型的生產階段可能相對單純，但生成式模型改變了工程問題：只有 weights 與 GPU，並不會自然得到在負載下仍快速、經濟又可靠的服務。這門領域因此橫跨三個相互協作的層次。runtime 改善單一 GPU 服務 instance 上的模型效率；infrastructure 協調愈來愈大的資源池；tooling 則讓工程師以具生產力的方式保有適當控制。當一般化服務無法滿足已知產品要求時，專門化才開始值得投入。在那個門檻之前，額外機制只是營運負擔；越過門檻之後，若只修正其中一層，系統仍會受其他層的瓶頸限制。

快速的模型伺服器還不等於生產推論系統。流量可能超出單一 instance 的容量；某個區域故障可能讓再出色的 kernel 最佳化失去意義；介面也可能隱藏診斷品質或延遲退步時不可或缺的控制項。這些故障成因不同，使用者感受到的卻是同一個產品。把 runtime、infrastructure 與 tooling 當成一個系統，才能避免團隊慶祝局部加速時，整體結果仍被排隊、放置策略、容量或操作摩擦主導。

推論工程始於單純提供函式服務已經不夠用的地方。觸發點不是某項熱門最佳化，也不是固定的 GPU 數量，而是證據顯示工作負載需要刻意控制效能、規模、可用性或開發者體驗。規模小時，問題可能只是讓一個部署有效率；流量增加後，問題會依序轉為 autoscaling、跨區域與跨供應商容量，最後成為全球統一資源池的 scheduling。這條界線隨產品移動，因此團隊應回應實際限制逐步專門化，而不是預先搬進整套複雜堆疊。

規模階梯也是一套診斷工具。若單一 replica 浪費資源，直接增加 replica 只會成倍放大浪費，因此應先處理 runtime。若各 replica 已有良好效率，但流量抵達時間與位置不均，routing 和 autoscaling 就成為限制。若整體 GPU 數量其實足夠，卻被區域或供應商邊界切開，真正問題便是容量協調。若營運人員無法安全表達這些選擇，限制系統的就轉為抽象介面。這個順序讓團隊持續追問具體問題：是哪一項資源或控制，使下一單位需求無法在產品契約內得到服務？答案會指出今天該把工程力氣放在哪裡，也讓其他層準備面對下一次規模改變。這並不表示問題永遠照固定順序發生，而是要求每次擴張前重新量測。當使用形態、模型或區域分布改變，原本次要的層可能立刻成為主瓶頸；清楚保留各層責任與訊號，團隊才能在不推翻整個系統的情況下轉移優先順序。

有用的分層邊界是介面，不是牆。runtime 應回報容量與故障訊號，讓基礎設施能據此採取行動；基礎設施應揭露放置與負載狀況，解釋使用者觀察到的現象；tooling 則應把這些事實轉成可操作的控制，同時不能把原因抹去。這套模型也有助於釐清權責：團隊可以購買代管層、內部自建，或混合兩者，但仍必須知道每個邊界傳遞哪些保證。原書提供的地圖因此不只是元件清單，而是即使實作由多家供應商與內部團隊共同交付，仍能用來推理完整服務的方法。某個介面上的責任缺口，和某一層內部的低速元件同樣嚴重。若 runtime 沒有提供可信容量資料，autoscaling 便只能猜測；若基礎設施不說明請求去了哪裡，模型延遲就難以解釋；若 tooling 只提供按鈕而沒有狀態，營運者也無法建立信心。把介面契約寫清楚，才能讓每層獨立演進又維持整體一致。

這些訊號必須一起閱讀。單一 instance 容量提高，只有在機群能把工作 route 過去並維持其可用性時才有價值；預留容量只有在新 replica 及時就緒時才能保護突發流量；地理多樣性只有在流量真正能容錯移轉時才增加韌性；鄰近使用者的容量，也只有在放置策略沒有把機群切成無法互助的孤島時才改善延遲。最後還要檢查可營運性：技術上能力完整、卻無法理解或安全變更的堆疊，不可能長期可靠。沒有任何單一指標能代表推論工程，服務契約決定哪一組指標必須維持在界線內。團隊也要區分領先訊號與落後結果。機群餘裕和 replica 就緒時間能在使用者受影響前警告風險；端到端延遲與成功率則描述使用者已經感受到的結果；變更所需時間會透露 tooling 是否讓修正能安全落地。把三類訊號連起來，才能從症狀追到正確層次，而不是看到任何延遲上升就一律調整模型；量測窗口也應同時涵蓋日常流量、尖峰負載與故障切換，避免平穩時段的漂亮數字掩蓋真正風險。