LLM 推論系統
TEMPO 依實測執行時間分派 MoE 專家，Qwen3‑235B 的 p99 token 延遲降低約 15.6%
TEMPO 不再只平衡 token 或啟用專家數，而是同時估算 HBM 權重載入與 GEMM tile padding。SGLang 原型在部分 Qwen3‑235B 流量提高 4%至6%吞吐，但對通訊受限的 DeepSeek‑V3 反而只留下額外成本。
專家平行 MoE 推論每層都要等待最慢的 GPU，因此常見分派器會平均 token 數，或平均每卡啟用的專家數。TEMPO 的量測指出，兩種代理指標都忽略了 grouped GEMM 的分段成本：每位專家少於約 156 至 168 個 token 時，主要時間花在由 HBM 載入權重；超過門檻後，計算又按 128-token 的 M-tile 向上取整。把同一專家拆到更多副本，可能同時重複搬運權重並製造填充計算。
團隊以 `t=max(a+bG, c+βN)` 建模，其中 G 是 GPU 上啟用的專家副本數，N 是 token 數，再加入 tile 項處理較大的 prefill。實際 decode 批次通常同時包含少數熱門專家與大量冷門專家；四組軌跡中，92%至100%批次同時落在記憶體與計算兩種區域，令任何單一平衡指標都有失效範圍。
TEMPO 把每批分派寫成固定成本 makespan 問題，使用毫秒級啟發式求解器；求解移到獨立程序，分派與計數則融合成 CUDA graph 內的 kernel，再接入 SGLang。Qwen3‑235B-FP8 位於預測的有效區域時，端到端吞吐增加約4%至6%，中等 Poisson 負載下 p99 每 token 延遲由226降至191毫秒。DeepSeek‑V3 因每卡專家較多、通訊占比更高，所有自適應策略均落後靜態分派約2%至3%，證明它並非通用加速器。
工程上最值得採用的不是固定策略，而是先量測 kernel、模型形狀、批次與網路拓撲，再判斷是否存在可回收的不平衡。論文匿名化 GPU 型號，EP32 以上部分結果仍來自校準模擬；驅動或 kernel 更新也須重新校準，且目前尚未聯合最佳化專家放置與逐批分派。