從“算力”到“Token 生產力”，硅基流動助力央國企大模型規模化落地

在企業網 D1net 主辦的 2026 秋季央國企 CIO 及數科公司高管峰會（第 19 屆）上，硅基流動解決方案總監唐安波出席峰會並作主題分享：《從“算力”到“Token 生產力”：央國企大模型規模化落地的推理基礎設施與 ROI 實踐》。以下為分享內容精華。當下，AI 應用正處於爆發式增長的早期階段，Token 消耗量呈指數級增長。這背後，模型架構持續演進，版本更新節奏快速；同時，算力架構也在不斷演進。模型與算力之間，是相互推動的迭代過程。對於企業來說，一方面要適配這些變化，另一方面又要面向自己的業務場景提供多元化模型服務，還要把成本控制在合理範圍內。

硅基流動在做的事，就是打通從算力到 Token 之間的轉化層：把算力統一納管起來；通過自研推理引擎，讓模型跑得更快、更好。我們既在公有云端建設 Token 工廠，也幫助央國企在內部打造自己的 Token 工廠。簡言之，通過系統化的推理工程，做好模型與算力的多重適配。基於此，硅基流動提出 Token 生產力核心公式：Token 生產力 = 產能 × 利用率 × 交付質量。其中，產能由芯片硬件能力、模型優化水平共同決定；利用率依靠流量治理與算力智能調度實現；交付質量包含模型推理精度、工具調用等任務執行成功率，以及生產環境必備的 SLA 服務穩定性。

從統一納管到模型運營，把算力利用率真正做起來我們從業務和流量的視角，設計了四層解耦架構。把模型運營、模型運維、推理執行與算力調度連接起來，覆蓋一個模型從部署、加速到服務調度等全生命週期的各個環節。分層解耦的架構設計，也是為了適應央國企已有的平臺建設情況，避免重複建設；如果企業已有自研能力，可結合已有系統對接，不必推倒重來，即可以“能力組合”的方式直接補齊所需能力。模型網關：不僅是入口，也是模型運營平臺。這一層直接面向模型服務的使用方，如各地分子公司及下屬集團。所有大模型調用均經由該層完成計量、計費、鑑權等基礎工作。

更重要的是，它還提供豐富的調度與路由策略：如可根據不同業務場景對響應時間的要求，將請求路由至相應的模型服務，實現業務間互不影響，確保各方獲得滿意的 SLA；同時也支持按性能優先、成本優先等不同目標進行靈活調度。模型服務平臺：把部署與運維的最佳實踐交付給企業。這一層主要從運維角度管理模型上下架、模型倉庫等能力。我們會把模型部署的最佳實踐放進去，讓企業能夠一鍵拉起模型，而不是每次重新做適配。我們已經適配了近百款模型，新的主流模型持續適配，目標都是讓業務團隊能夠開箱即用。高性能推理框架：面向具體模型與硬件的優化迭代。

我們與不同算力廠商開展深入合作，圍繞具體模型與算力，自研算子庫、通信庫，儘可能釋放模型在對應硬件上的性能。

例如，與華為雲合作，在業內首次推出基於國產芯片的 DeepSeek R1/V3 Token 服務，並共同為 CloudMatrix 超節點集群開發並優化推理解決方案，在 DeepSeek-R1 上實現單卡 Decode 吞吐量超過 1,920 tokens/s；全球首發基於沐曦曦雲 C550 集群的 Kimi-K2 大模型商業化服務部署；在摩爾線程 MTT S5000 芯片上部署 DeepSeek-V3，實現單卡 Prefill 吞吐超過 4000 tokens/s、Decode 吞吐超過 1000 tokens/s。

同時，我們的推理技術也在持續演進：隨著模型處理任務的上下文不斷增長、併發持續提升，需要持續地對推理框架進行優化，如算子優化、通信優化、模型量化等，同時結合 PD 分離以及 KV Cache 分級卸載等手段，全面提升模型推理的整體性能與吞吐能力。算力調度：算力資源彈性管理。彈性靈活的算力調度是降低推理成本、提升算力利用效率的關鍵要素。但算力規劃常常面臨兩難：估得過於保守，可能很快滿負荷甚至過載；完全按白天峰值配置，又會在其他時段造成資源浪費。因此，既需要彈性擴縮容策略，也需要運營手段配合。

例如，央國企面向各分子公司提供模型服務時，可在內部結算中採用分時定價：白天按常規定價，夜間給予折扣，引導部分業務在夜間運行。各業務可能使用不同模型，這就要求平臺能夠基於請求隊列、性能等多維度指標動態調整模型實例。央國企案例：從“租機器”轉向“調用模型服務”我們服務過一家央國企集團，原來有大約 50 臺機器，向下屬分子公司提供服務。早期的服務方式很直接，各分子公司來申請機器，部署自己要用的模型，說白了，是在“租機器”。這樣一來，模型實例開了四五十個，但整體算力利用率很低。有的單位佔用機器後，只部署一個模型；有的白天用、晚上不用；還有的每週只用幾天。機器被佔住了，卻沒有持續產生有效負載。

我們和客戶深度協同，針對以上現狀進行重構：模型統一，算力統一。把重複模型收斂到大約十個；把按機器分配資源的方式，改為 Serverless 模型服務，大家統一調用 API，不再關心模型具體部署在哪裡、佔用了哪臺機器。這樣，同樣約 50 臺機器，就能做更多事情。例如，用部分機器承載原有的一些小模型後，可以騰出多臺機器來部署新的大參數模型，比如 GLM-5.2、DeepSeek-V4-Flash-0731 等。過去，這類模型在集團內部是沒有條件運行的。但事實上，大參數的新模型對業務探索非常重要，因為模型智力的上限，也決定了應用創新的上限。

通過模型收斂和算力集約化管理，我們把這些模型部署了進去，再結合性能優化，讓更多場景從“不可用”變成了“可用”，從“可以探索”走向“可以放量”。原來，業務側最大的擔憂是：做探索、做一個 Agent 沒問題，但能不能規模化上線？能不能承接更多調用？大家心裡是有問號的。新模型上線以後，在單併發到較多併發的測試中，輸出速度綜合下來基本保持在 30 tokens/s 以上。以編程為例，超過 30TPS 是獲得較好使用體驗的基礎要求。在相同模型的對比測試中，我們取得了40%～100% 的性能提升。當然，這取決於不同的輸入、輸出長度，具體收益並不相同。整體上，一是模型吞吐能力提高了，二是算力利用率提高了。

兩方面疊加，最終反映在每百萬 Token 的成本上，這是一個很多企業會用來衡量推理服務效率的指標。在這個案例中，原先一個 Qwen 模型的每百萬 Token 成本在一百多元，調整後降到了十元以下。成本下降明顯，但最關鍵的，還是打開了更多原本難以落地的業務場景。進一步提升 ROI，應用與基礎設施共同優化隨著 Agent 規模化落地，我們也觀察到一個問題：應用層與基礎設施層之間，存在一定脫節。過去做應用程序，即使主要負責前端，開發者通常也會對數據庫索引、SQL 優化有一些理解。現在，大模型應用與基礎設施的分層比較明顯，應用側未必充分理解底層推理與緩存機制，而這會直接影響效率。

以 Coding 為例，我們正在與客戶共同探索這方面的優化。央國企的軟件工程，不是今天寫一個 App、明天再做另一個演示，而是要在多年裡持續迭代。代碼倉庫會不斷更新，每天提交代碼、進行構建，都是長期工程的一部分。這些代碼怎樣構造為模型的 Context，非常關鍵。如果上下文構造不好，每次請求都無法命中緩存，動輒數十萬 Token 的輸入，會消耗大量算力。但如果構造得好，其中約九成的內容可能命中緩存，效率差距就體現出來了。舉例來說，在不命中緩存時，系統可能支持 100 個併發；提高緩存命中以後，可能支持 200 個併發。這個提升並沒有增加硬件，而是減少了重複計算。

因此，Context 構建本身，就需要面向推理進行優化。另一個方向，是結合 DevOps 做優化。算力使用有波峰波谷，白天大家都在用算力，而 Coding 場景的輸入又很長。如果所有代碼都等到白天發起請求時才處理、再生成緩存，就會佔用大量高峰時段的算力。那麼，能不能在每天晚上的日常構建過程中，通過工程化手段，讓模型對代碼倉庫進行預處理，把相應計算結果預先存入 KV Cache？這樣，白天就不必重複計算。這些方式，都有機會進一步提高算力利用率。但這部分能力，也依賴我們與場景方共同探索。硅基流動希望與央國企一起，探索更多 AI 落地場景，把真正的算力和產能釋放出來。