大模型“造梦”，推理引擎“还债”，CTO们正在还AI的“应用账单”

文｜Alter

站在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竞赛的核心主战场。