【導讀】摩爾線程最近發布了一份技術白皮書，圍繞MTT S5000智算卡提出了一個叫“Prefill-as-a-Service”的方案。核心邏輯不復雜：大模型推理有兩個階段，Prefill算力密集型，Decode訪存密集型，放在同一套硬件上跑必然互相浪費。摩爾線程的做法是把兩者拆開，各跑各的資源池，MTT S5000專門負責Prefill這一端，用高稠密算力和原生FP8支持來壓榨首字時延。
背景：長上下文時代，“算力錯配”成為推理成本的核心瓶頸
隨著大模型輸入上下文規模快速邁入數百K到1M 級別，長文本輸入帶來的算力消耗與首字時延壓力持續攀升，正日益成為制約企業推理服務效率與總擁有成本（TCO）的關鍵瓶頸。傳統同構集群的算力部署模式，已難以應對不同計算階段對硬件資源的差異化需求。
核心痛點在于結構性錯配：在大模型在線推理中，輸入階段的Prefill（預填充）屬計算密集型任務，受浮點算力約束；輸出階段的Decode（解碼）屬訪存密集型任務，受顯存帶寬約束。兩者在同一物理資源池中混跑，必然導致雙向浪費——按Decode帶寬選型，則Prefill的大容量顯存長期低效；按Prefill算力選型，則Decode計算單元大面積空轉。
破局：Prefill-Decode異構解耦，重構推理資源池
《白皮書》指出，突破這一瓶頸的關鍵在于將Prefill與Decode徹底解耦，使二者各自運行在最契合自身計算特性的硬件資源池上：
Prefill算力池：專攻高算力利用率與極低首字延遲（TTFT）；
Decode資源池：專攻高并發與穩定的每Token延遲（ITL）。
通過硬件分層投入，算力配置從“通用冗余”轉向“按需匹配”，在滿足服務質量（SLO）約束的前提下，實現單位Token基礎設施成本大幅下降。
底座：MTT S5000構筑高吞吐Prefill專屬算力池
作為一款全功能通用AI加速卡，MTT S5000在硬件特性上與Prefill任務高度契合，展現出出色的工程適配與規模化落地能力：
高計算密度，壓縮首字時延。針對Prefill的計算密集型特征，MTT S5000提供高稠密算力，有效壓縮首Token生成時延（TTFT）；在長上下文場景下，以GLM-5.2為例，單機8卡可實現接近十萬級Prefill吞吐，為Agent、長文檔分析等業務提供確定性的SLO承諾與容量規劃能力。
原生FP8支持，消除格式轉換開銷。支持FP8至FP64全精度計算，天然適配主流大模型原生精度，Prefill過程不引入額外精度損耗；原生FP8 KV Cache與Decode池保持高度兼容，消除跨節點傳輸前的格式轉換成本，顯著降低KV Cache傳輸時延。
生態成熟兼容，降低落地門檻。依托MUSA軟件生態，全面兼容CUDA及PyTorch、SGLang、vLLM等主流推理框架，企業可基于現有代碼資產實現平滑遷移與快速適配。
實測驗證：嚴苛SLO約束下，64K上下文場景單機吞吐可達到5.8 MTokens TPM
《白皮書》基于超大參數模型智譜GLM-5.2-FP8，在90%前綴緩存命中率、首字時延P50 TTFT ≤ 6,000ms的嚴苛硬性SLO約束下，完成了64K至400K序列的極限壓測。
以智譜官網API定價為基準（輸入8元/百萬Token、緩存命中2元/百萬Token，綜合單價2.6元/百萬Token）進行測算，基于實測性能，在理想狀態下的商業價值表現如下：
在典型Agent混合上下文負載下，單機更具確定性算力變現能力與清晰的投資回收周期。
結語：以“推理效率+商業回報”重構產業競爭邏輯
大模型產業競爭的下半場，本質上是推理效率與商業回報的較量。摩爾線程通過MTT S5000與Prefill-as-a-Service方案，不僅重塑了長上下文推理的性能與成本邊界，更幫助企業在萬億參數與Agent時代牢牢掌握TCO主動權。
完整白皮書請參見：《MTT S5000 Prefill-as-a-Service技術白皮書》
https://developer-hscdn.mthreads.com/public/MTT-S5000-Prefill-as-a-Service-%E6%8A%80%E6%9C%AF%E7%99%BD%E7%9A%AE%E4%B9%A6.pdf
總結
從技術路徑來看，Prefill和Decode解耦不是什么新概念，業內早有討論，但真正拿出具體硬件方案和實測數據的還不多。摩爾線程這次把MTT S5000卡在Prefill這個節點上，等于給算力分層提供了一個可落地的參考。實測數據說明在長上下文場景下，這套打法能在SLO約束下跑出穩定的吞吐，而且用FP8精度跑起來沒有額外的格式轉換開銷，生態上也兼容了主流框架和CUDA代碼。
