最佳化技術

最佳化首先是診斷問題。Quantization 減少運算量與記憶體流量，但會使用品質預算；speculation 利用 decode 的閒置算力，改善 inter-token latency（ITL）與 tokens per second（TPS）；caching 避免重做 prefill，改善 time to first token（TTFT）；parallelism 讓模型放得下，或改變跨裝置的延遲與吞吐量；disaggregation 則在規模足夠時，把運算密集的 prefill 與記憶體密集的 decode 分開。先量出瓶頸，再用範圍最窄的合適手段，最後回頭重測整個系統，因為不同技術可能互相增益，也可能互相搶資源。

用四種預算思考：運算、記憶體容量與頻寬、通訊，以及可接受的品質變化。每項技術都把壓力從一種預算搬到另一種。Quantization 儲存與搬移較少 bit，代價是數值誤差風險；speculation 花額外算力減少 decode iteration；caching 花記憶體避免 prefill；parallelism 花通訊換容量或 concurrency；disaggregation 花硬體與傳輸頻寬換階段專門化。好的配置會消除主導限制，卻不讓接收壓力的另一項預算立刻成為新瓶頸。

假設量測顯示 prefill 受算力限制，decode 受頻寬限制，而且 weights 與 buffer 留給 key-value cache 的空間太少。一次經過審慎評估的精度調整，理論上可同時減少矩陣運算成本、weights 搬移 byte 數與 cache footprint，但不能因此把整個模型一口氣降到最低精度。先只轉換較不敏感的 linear weight，與原始模型比較 perplexity、公開 benchmark 及產品 eval；通過後再加入 activation；若長 context 或 disaggregation 真的受 cache 容量與傳輸限制，才評估 key-value state。輸入輸出層、outlier 明顯的區段與 attention 計算可保留較高精度，避免反覆使用的誤差逐 token 累積。每一階段都同時量 TTFT、TPS、記憶體、吞吐量與品質差異。目標不是使用 bit 數最少的格式，而是在品質差異仍落於多次實驗雜訊內時，找出延遲與成本最低的組合。

以互動式程式開發工作負載為例，先把穩定的 system prompt、工具定義與 repository context 放在前面，把目前編輯內容及使用者新問題放後面，讓 prefix caching 可以跳過大量 prefill。router 要盡可能把同一使用者或同一 codebase 的後續請求送回已有 hot cache 的 replica，同時保留負載上限，避免 affinity 讓單一節點過熱。進入低 batch decode 後，程式碼中高度重複的 token 序列可能讓 n-gram speculation 提出很長且常被接受的 draft，進一步減少 target model 的 forward pass。當 concurrency 升高、batch 吃滿算力時，就要縮短或停用 speculation，因為驗證 draft 會與正常請求爭用 compute；prefix cache 仍可繼續節省 prefill。兩項技術作用在不同階段，應分開追蹤跳過的輸入 token、cache hit、draft acceptance、每 iteration 接受 token 數及淨 ITL，而不是共用一個開關或只看總吞吐量。

當模型超過單一 GPU 容量時，先把 weights、runtime workspace、activation、目標 batch 與最長 context 的 cache headroom 全部算進去，再決定平行策略，而不是看到多張卡就直接套一個縮寫。tensor parallelism（TP）把每一層的 tensor 切開，能讓多張 GPU 共同讀 weights 與做 matmul，在高速節點內 interconnect 上通常可降低單一使用者延遲，但每一層都要同步結果；裝置增加到通訊超過節省的運算後，效益就會反轉。expert parallelism（EP）把完整 expert 分散到不同裝置，router 雖要搬移 token，卻不需要像 TP 一樣在每一層 all-reduce，因此較適合把 mixture of experts（MoE）系統吞吐量擴到更多 GPU 甚至多節點。pipeline parallelism（PP）把完整 layer stage 放到不同節點，請求依序穿過 pipeline，容易形成 bubble，主要是在 dense 模型無法用其他方式跨節點放下時解決容量。每增加一張 GPU，都要用 parallel efficiency 與 interconnect trace 證明有更多有效工作；模型若已舒適地放在一個節點，新增硬體建立另一個 replica 往往更簡單、更能服務獨立請求。

當大型模型承受穩定高流量，且大量長而未 cache 的輸入讓 compute-bound prefill 開始干擾 memory-bound decode 時，disaggregation 才進入候選。請求先到 decode 端做 cache check：完整 hit 或短 prefill 就在本機完成，避免為了專門化支付不必要的 queue 與 KV transfer；長而 miss 的輸入才送到 prefill pool。Prefill worker 可採用偏運算導向的 GPU 數、TP 與 batch 設定，產生第一個 token 及 key-value block 後，經選定 interconnect 傳到偏頻寬與 cache 容量導向的 decode worker，後者再生成剩餘 token。Prefill 與 decode 數量不是固定一比一，而是持續營運的控制變數：prefill queue 增長表示前段容量不足；decode cache eviction 或 occupancy 過高表示後段記憶體不足；傳輸時間過高可能需要 cache quantization、較近 topology 或更高 local-prefill 門檻；流量下降則可能表示應合併 worker，避免昂貴 GPU 閒置。

任何手段都先放在受控流量切片後面，保留未最佳化路徑與快速回退。結果要依輸入長度、輸出長度、cache hit 或 miss、batch、concurrency 量、硬體與 topology 切分；整體平均值可能掩蓋少數長 context 使用者的嚴重退步，也可能把低負載收益誤認為尖峰容量。上線 gate 至少同時包含 percentile latency、系統吞吐量、GPU 記憶體、單位成本、錯誤率與品質；quantization 還要比較產品 eval，speculation 要看不同 temperature 下的 acceptance，caching 要看實際跳過 token，而不是只看 hit rate。逐步提高流量前先經過完整尖峰週期，並保留能在前提消失時停用技術的 trigger，例如 batch 過高就關閉 speculation、品質分數越界就切回原始精度、熱門 replica 過載就降低 cache affinity。

Prefill 與 decode 的 worker 比例要隨工作負載調整。長輸入與 prefill-heavy 流量需要更多 prefill 容量；decode-heavy 流量則需要更多 decode 容量。監控 prefill queue 與 decode 端的 key-value cache，並在流量改變時於 runtime 調整比例，不要固定成一個 prefill engine 對一個 decode engine。短輸入或 cache hit 可以透過 conditional disaggregation 留在 decode engine 本地完成 prefill。流量較低時，直接水平擴增 replica 可能比 disaggregation 更有效率，因為後者會增加 GPU、queue 與 cache transfer 成本。

每項手段都留下完整因果鏈：量到哪一個 phase 與資源瓶頸、什麼流量條件讓技術成立、壓力被搬到哪一項預算、預期改善哪個使用者或成本指標、可能新增哪種故障、品質 gate 是什麼、何時自動停用，以及如何 rollback。例如「低 batch decode 有閒置算力，因此啟用短 draft speculation；若 acceptance 或淨 ITL 低於門檻就關閉」比「開啟 EAGLE」更能營運。這份紀錄把一次性設定轉成可觀測政策，也讓另一項最佳化改動同一份 compute、memory 或 communication 預算時，團隊能立刻看出互動與重新驗證範圍。