自架推理服務的完整調校：從裝好到跑滿
裝起來能跑，跟跑到硬體極限之間差了三到五倍。這是逐項調校的順序。
推理延遲的組成：先知道時間花在哪裡
優化之前先拆解。多數團隊優化錯地方，是因為沒量過各段耗時。
多區部署與故障轉移：模型服務的高可用設計
GPU 資源稀缺讓高可用比一般服務更難。這是務實的分級策略。
推測解碼：在不換硬體的前提下加速生成
用小模型草擬、大模型驗證，生成速度常能提升一到兩倍。
連續批次處理：吞吐量提升最大的一個開關
同樣的硬體，開啟連續批次後吞吐量常常翻好幾倍。理解它為什麼有效。
GPU 資源排程：讓訓練與推論共用叢集
訓練與推論搶卡是常見痛點。這是可運作的分時與優先權設計。
前綴快取：把重複的系統提示只算一次
如果你的每個請求都帶著兩千字的系統提示，前綴快取幾乎是免費的加速。
邊緣與本地部署：離線環境的模型服務
不能連外網的環境有自己的一套限制。這是實務上的取捨。
量化怎麼選：INT8、FP8 與 4-bit 的實際差異
量化能省記憶體也能加速，但不同精度的取捨很不一樣。這篇給選擇順序。
延遲預算分配：從使用者體驗反推每一段的上限
先決定使用者能忍受多久，再把時間分配給各個環節。
串流回應的正確實作：SSE 與中途中斷
串流不只是把字吐出來，還要處理中斷、錯誤與部分結果的保存。
成本歸因到功能：知道每個功能花了多少錢
帳單只有一個總數，無法做決策。這是把成本拆到功能層級的做法。
模型服務的健康檢查：光看行程還活著不夠
模型服務可以「行程還在但已經不能用」。健康檢查必須做真實推論。
自架還是用 API：把成本算清楚再決定
自架的成本不只是顯示卡租金。這篇把常被忽略的項目列出來一起算。
限流與排隊：流量尖峰時怎麼不整個垮掉
模型服務的資源無法瞬間擴充，所以入口的排隊策略比擴容更重要。
把模型服務包成 Docker：一份可用的基礎設定
GPU 容器化有幾個固定要處理的點，這是可以直接改用的骨架。
灰度發布模型版本：怎麼安全地換模型
換模型跟改程式不一樣，行為變化沒辦法用單元測試涵蓋。要靠流量分配。
語意快取：相似問題直接回舊答案，可以嗎
語意快取能省下大量成本，但誤命中的代價很高。要有明確的適用邊界。
模型路由：用小模型接住八成流量
不是每個請求都需要最貴的模型。路由做得好，成本可以砍掉一半以上。