3 篇文章
在 I-00 篇中，我們列出了 LLM 推論與傳統模型服務的五項差異。前四項——可變長度運算、兩階段資源特徵、不斷增長的記憶體需求，以及快取感知路由——每一項都已經在本系列的專文中討論過了。第五項則只用一句話帶過：「有些現代 LLM 使用混合專家模型（mixture-of-experts, MoE）架構，模型的不同部分會因不同的輸入而被啟用。把 MoE 模型分散到多個 GPU 上，需要跟密集模型不同的分片（sharding）策略。」
I-00 追蹤了單一請求通過推論流程的完整路徑：預填充（prefill）以平行方式處理所有輸入 token，解碼（decode）逐一生成輸出 token，而 KV 快取（key-value cache）隨著每一步不斷增長。在那篇文章的結尾，我們注意到還有另外 49 位旅遊顧問幾乎同時提交了查詢。這個觀察不是隨口帶過——它直接指向推論服務的核心運作問題。
你已經建好一個旅遊 Copilot。使用者輸入一段查詢，你的應用程式把它送到 LLM 供應商的 API，幾秒後回應串流回來。對應用程式開發者來說，那就是一次函式呼叫。但從基礎設施的角度來看，這一次呼叫觸發了一整條流程（pipeline），牽涉到不同的運算階段、專用的記憶體結構、排程決策，還有硬體限制。這些因素加在一起，決定了使用者實際感受到的延遲、吞吐量和成本。