大模型“造夢”，推理引擎“還債”，CTO們正在還AI的“應用賬”

站在2025年中，回顧半年來大模型的發展，以年初DeepSeek爆火為標志，大模型快速蛻變角色，走出實驗室，真正融入企業核心業務系統，在政務、金融、醫療、能源等領域加速落地。

隨著大模型走向深度應用，CTO從關注基礎模型轉向推理引擎，推理過程中的資源消耗，每一度電、每一塊錢、每一分鐘所能產出的Token數量，正在成為衡量一家公司在AI時代先進性的關鍵指標。

怎么用推理引擎提升推理效率、榨干每一塊算力的價值、盡可能降低推理成本，已經成為CTO們必須解決的問題。

01 大模型跑不動，是因為推理引擎不給力

什么是推理引擎？

簡單來說就是一套專門負責讓大模型“跑”起來的系統，既負責“怎么算”，又負責“在哪算”和“算得多快”，盡可能提高大模型推理的響應速度、并發能力和算力資源利用率。

如果說大模型是發動機，推理引擎就是動力總成，決定了發動機在不同道路、不同油品、不同氣候下是否能高效運轉。調校得當，就能低延遲、高吞吐、低成本；調校不佳，再強的模型也可能“燒油多、輸出低”。

大約從2023年開始，推理引擎開始作為一個獨立賽道興起，陸續出現了TGI、vLLM、TensorRT、SGLang等面向推理效率優化的開源項目。彼時業界的注意力還停留在“大煉模型”上，對推理引擎的需要求不高——能用就行。

2025年初是一個分水嶺。

DeepSeek為代表的一批大模型開源后，企業對AI的態度由觀望轉向行動，紛紛采購算力、治理數據、微調模型，落地部署時卻發現：推理響應慢、吞吐跟不上、成本高昂。

90%的算力花在了推理上，結果又貴又慢，連“謝謝”都不敢多說一句，幾乎談不上性價比。

大模型推理到底難在哪里呢？答案是效果、性能、成本的“不可能三角”。

想要效果好，就得用更大的模型、更高的精度、更長的上下文，但算力開銷就上去了；想要跑得快、響應快，就要用緩存、做批處理、圖優化，可能影響模型輸出的質量；想要成本低，就要壓縮模型、降低顯存、用更便宜的算力，又可能會犧牲推理的性能或準確率。

企業的CTO們在為大模型推理焦慮時，推理引擎賽道也“熱鬧”了起來，不少在AI應用上“搶跑”的大廠，同樣意識到了推理引擎的短板，試圖將自己摸索出的經驗，做成標準化產品和服務，幫企業壓下這筆越來越沉重的應用賬。

比如英偉達發布了推理框架Dynamo；AWS的SageMaker提供了多項增強功能提高大模型推理的吞吐量、延遲和可用性；京東云推出了JoyBuilder推理引擎，可將推理成本降低90%

一句話來總結：大模型能力再強，沒有高效的推理引擎，就像一輛發動機不行的跑車，只能原地轟油門。

02 為了推理快、省、穩，大廠都在死磕工程創新

過去為了提高推理能力，思路主要放在模型上，通過剪枝、蒸餾、量化等技術給大模型“瘦身”。越來越多企業發現，如果推理過程上存在太多短板，模型再怎么輕，推理的效能也上不去，必須要優化推理流程。

在理解工程創新的思路前，先把大模型的推理過程拆解一下：

第一階段（Prefill）：先聽懂你在說什么。

就像人聊天前要先把對方說的話聽清楚、理解透，大模型的第一步，就是認真“讀題”，一字一句地“消化”，并在腦子里畫好一套“思考地圖”（KVCache）。

第二個階段（Decode）：一字一句地回答你。

不是一下子把答案全說完，而是一字一句地往下寫，每寫一個字，都會根據剛才的思路更新一下自己的“思路地圖”，確保后面寫的內容更連貫、更合理。

AWS、京東云、英偉達、谷歌云等，都在“死磕”工程創新。

比如優化“思考地圖”，如果“思考地圖”又大又亂，占了GPU大量空間還查得慢，就會成為性能瓶頸。

AWS SageMaker和谷歌云Vertex AI的做法是給“思考地圖”建了一個“緩存共享中心”，動態調度顯存資源：誰先用、誰能共用、誰暫時擱置，都安排得明明白白，盡可能讓GPU的價值“壓榨到極致”。

京東云JoyBuilder推理引擎和英偉達的Dynamo，則進一步給出一種“以存代算”的解法：直接把“思考地圖”從GPU挪出去。其中京東云通過自研的云海AI存儲，支持PB級緩存擴展，并配合高效檢索算法與負載感知調度，直接將多輪對話和長文本處理的響應時延壓縮了60%。

再比如將“聽”和“說”分離，相當于開會時讓“準備”和“發言”同步進行，避免出現“干等閑耗”的場景。

其中AWS不只實現了“聽”和“說”分離，還改變了大模型說話的方式，不再是“想到哪說到哪”，而是提前整理好了大綱，省下了大量來回思考的時間。

京東云JoyBuilder推理引擎的方案稍有不同：第一招和AWS相似，整體吞吐提升了30%以上；第二招是將“聽”和“說”交給不同的GPU處理，兩邊像流水線一樣并行工作，中間用“傳送帶”快速傳遞信息，大幅提升了推理吞吐量。

對CTO們而言，技術大廠的深度參與，不失為一個好消息，相當于是把推理引擎打磨成了能直接用的高性能“電子電氣架構”。

03 異構算力是挑戰，也是低成本取勝的機會

我們在和幾位CTO溝通時，除了普遍焦慮的推理性能，還涉及到另一個問題——異構算力。

隨著大模型應用的深入，以CPU為中心的架構在支持AI原生應用上面臨挑戰，需要以GPU為中心重塑基礎設施；此外，面對激增的推理需求，計算資源持續增加，企業需要思考資源投入產出的問題，都指向需要一套AI Native的基礎設施。

而異構算力，通俗來說就是將不同品牌的芯片“拼著用”。就像是一支臨時組成的軍隊，語言、指令、作戰邏輯全都不統一。以至于一位CTO打趣說：“我們要想打仗，得先發明統一的語言和作戰地圖。”

vLLM、SGLang等比較熱門的開源引擎，目前都還停留在同類型GPU之間高效調度，對“異構”集群依然捉襟見肘。但國內的研究機構和科技大廠都已經試圖解決：怎樣讓不同芯片“聽得懂一個指揮”，各司其職、取長補短。

一種主流思路是“把大鍋飯變自助餐”。

過去用GPU跑模型，就像是大鍋飯，一整張顯卡只能給一個任務用，哪怕只吃了一口，剩下的資源也不能被別人接著用。就像京東云JoyBuilder推理引擎的策略是把異構算力資源統一管理，把一張GPU“切成很多小份”（1%），顯存也能按MB級別來分，按需分給多個模型、多個任務使用，誰需要多少就用多少，GPU利用率最高可提升70%。

還有一種思路是把“拼芯片”和“拆流程”結合起來。

比如在MoE模型的部署上，京東云JoyBuilder推理引擎可以將不同專家部署在不同GPU上，讓每個GPU干最擅長的活。甚至可以將“輸入”部署在擅長高吞吐的昇騰集群，將“輸出”部署在N卡上確保低延遲，充分利用不同算力的優勢。

對于CTO們來說，在“推理成本決定最終勝利”的大模型競賽中，異構算力是挑戰，同樣也是機會。

04 高性能低成本，大模型推理正在重塑AI生產力

經歷了一段時間的高歌猛進后，越來越多企業對大模型的訴求，正在從“不能沒有”轉向要落地、要價值、要增長。我們看到，大模型已經在營銷推廣、協同辦公、客戶服務等場景深度應用，成為新的增長引擎。

例如在零售場景，包括面向用戶的AI生成商品圖、AI營銷內容生成、AI數字人，面向管理的AI客服與售后管理、AI經營托管、AI倉配優化，以及配送環節的自動分揀機器人、自動駕駛等需求。

JoyBuilder推理引擎源于京東自身復雜業務場景打磨，基于企業級的AI Native架構，正在廣泛服務于內外部眾多業務場景。

京東透露了一組數據：目前推理框架已經在內部多個場景應用，在可交互式導購、商品對比、商品總結、購物建議等環節，大幅提升了響應速度，節省了計算成本，同時還有效助力了用戶的活躍度；在核心的商品理解環節，也有效提升了大模型的理解能力和信息處理能力，模型推理成本最高可節省70%。

除了服務于京東內部，京東云推理引擎也廣泛服務于外部產業客戶，提供高性能、低成本的大模型服務。

在行業實踐中，京東云成功支持某新能源汽車頭部廠商、某全球新能源科技領導企業，打造覆蓋全集團的智能計算底座，實現千卡級AI算力集群的精細化管理。技術上一方面創新多元算力調度，顯著提升GPU利用率，另一方面創建全生命周期AI開發環境，實現開箱即用，大幅提升研發效率。

目前，該平臺已支撐起企業智能駕駛研發、人形機器人等20余個核心場景，成為集團的“數智發動機”。預計一年內，兩家企業大模型訓練周期將縮短40%，每年節省的算力成本相當于新建兩座數據中心。

05 寫在最后

盡管推理引擎已經在性能壓榨、資源調度和成本控制等方面取得了初步成果，但真正的競爭才剛剛開始。

尤其是在異構能力方面，無論是多種芯片的適配整合，還是對不同模型結構、大小、任務類型的統一支持，當前的技術體系還遠未成熟。同時也意味著，誰能率先構建起靈活、高效、可持續的推理能力，誰就有可能在AI大規模落地的浪潮中占據先機。

這是一場跨硬件、跨模型、跨場景的系統性挑戰，也將是未來十年AI競賽的核心主戰場。