文 | 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 仓配优化，以及配送环节的自动分拣机器人、自动驾驶等需求。
京东透露了一组数据：目前推理框架已经在内部多个场景应用，在可交互式导购、商品对比、商品总结、购物建议等环节，大幅提升了响应速度，节省了计算成本，同时还有效助力了用户的活跃度；在核心的商品理解环节，也有效提升了大模型的理解能力和信息处理能力，模型推理成本最高可节省 70%。
除了服务于京东内部，某新能源汽车头部厂商、某全球新能源科技领导企业，也在打造覆盖全集团的智能计算底座，实现千卡级 AI 算力集群的精细化管理。技术上一方面创新多元算力调度，显著提升 GPU 利用率，另一方面创建全生命周期 AI 开发环境，实现开箱即用，大幅提升研发效率。
目前，该平台已支撑起企业智能驾驶研发、人形机器人等 20 余个核心场景，成为集团的“ 数智发动机”。预计一年内，两家企业大模型训练周期将缩短 40%，每年节省的算力成本相当于新建两座数据中心。
05 写在最后
尽管推理引擎已经在性能压榨、资源调度和成本控制等方面取得了初步成果，但真正的竞争才刚刚开始。
尤其是在异构能力方面，无论是多种芯片的适配整合，还是对不同模型结构、大小、任务类型的统一支持，当前的技术体系还远未成熟。同时也意味着，谁能率先构建起灵活、高效、可持续的推理能力，谁就有可能在 AI 大规模落地的浪潮中占据先机。
这是一场跨硬件、跨模型、跨场景的系统性挑战，也将是未来十年 AI 竞赛的核心主战场。
更多精彩内容，关注钛媒体微信号 （ID：taimeiti），或者下载钛媒体 App
