AI推理：如何实现吞吐翻倍、时延降90%与GPU资源节省26%？

引言：AI规模化落地，推理系统面临全新挑战

 

全球领先的市场研究和咨询公司IDC预测，到2028年，75%的新 AI 工作负载将实现容器化，从而显著提升模型与工作负载更新的速度、一致性与安全性。容器化技术将成为 AI 推理时代的“默认交付形态”。当前随着大模型技术快速演进与业务场景的深度融合，AI业务对推理基础设施的需求呈现爆发式增长。在早期小流量场景下，手动部署与定制化方案尚可应对；然而当模型规模、并发请求与业务复杂度攀升至新高度时，传统推理系统在以下四个主要方面逐渐暴露出瓶颈。

1. 稳定性不足：

◦单点故障风险：手动部署的静态架构缺乏多副本与故障自愈机制，单节点宕机易引发服务中断；

◦负载不均衡：缺乏智能流量调度，高并发时部分节点过载导致响应延迟，低负载时资源闲置；

◦故障恢复滞后：依赖人工排查与重启，恢复周期长，影响业务连续性。

2.资源利用率低下：

◦静态资源分配：固定规模的GPU集群无法适应流量波动，高峰时段资源争抢，低谷期GPU闲置率超40%；

◦缺乏弹性机制：无法根据请求队列长度、KV缓存利用率等指标动态扩缩容，导致周级别GPU卡时浪费超5000+。

3.推理性能瓶颈：

◦混合请求排队：长、短文请求混合处理时，短文首字时延（TTFT）因排队激增90%以上；

◦缓存复用率低：多副本场景下相同前缀请求随机调度，重复计算导致KV缓存命中率不足60%；

◦硬件拓扑未优化：跨交换机部署引发传输延迟，人工调整拓扑亲和性成本高且易出错。

4.定制成本高昂：

◦多引擎适配复杂：vLLM、SGLang等引擎需独立开发接入层，版本迭代与兼容性维护成本攀升；

◦运维依赖人工：从部署、监控到故障修复全流程手动操作，人力成本占比超30%，且易引入人为错误。

 

为此，京东云结合实际业务需求与技术趋势，全面拥抱云原生技术栈，积累了丰富的云原生与高性能推理经验。自主研发了新一代云原生AI推理框架。推动推理系统完成了一次体系化升级，实现了从手动部署到全场景AutoScale，从资源浪费到GPU利用率最大化。

•流量高峰自动扩容、低谷自动缩容，GPU卡时节省高达26%；

•智能流量调度与KV缓存复用，最高提升吞吐124%，首次生成时延TTFT降低90%；

•具备多级高可用能力，支持流量隔离、故障自愈与深度可观测；

•模型量化、引擎调优、算子开发等多项优化，推理引擎单点性能呈现局部领先优势。

 

详细了解一套生产级分布式AI训练推理平台（JoyBuilder）的云原生改造全纪实。京东云云原生AI推理框架。

 

一、系统架构设计：面向生产级的高性能云原生推理平台

设计理念：

我们遵循三大核心设计原则，确保系统长期迭代的灵活性：

1.解耦与组合 各模块尽量松耦合，优先复用开源成熟组件，同时避免被社区绑定，保留核心模块的可替换能力。

2.扩展性优先 支持以插件化方式集成智能调度算法（流量调度、扩缩容决策、Prefix Cache打分等）；容器编排能力可扩展，目前已支持跨机部署与基于角色的调度策略。

3.引擎无感接入 目前可同时支持vLLM、SGLang等主流推理引擎，最终实现任意推理引擎的低成本接入。

系统架构：

 

模块详解：

1. 智能流量调度网关

基于云原生Gateway API与Inference Extension框架，我们构建了支持多引擎、高可用、高扩展的智能推理网关，支持多层次调度策略：

 

核心能力	说明
长短文分桶推理 流量调度	网关基于高效的长短文分桶算法，构建跨模型集群的分流调度，显著降低短文TTFT（首字生成时延）；
前缀缓存感知KV复用流量调度	面向不同模型上下文特征，基于 HashTrie 算法构建集群内全局pod的近似前缀缓存画像，支持prefix cache的亲和调度，有效降低推理 TTFT(首字生成时延)；
多维负载均衡流量调度	毫秒级实时采集KV Cache Utilization、Waiting Queue等server load指标，支持load aware 亲和调度；
交换机拓扑感知流量调度	为减少PD group组内KV cache传输的耗时，构建网络拓扑感知，支持全局最优prefill + 局部最优decode的网络亲和调度；
多引擎PD分离流量编排调度	已支持vLLM(PD串行)、SGLang(PD异步并行) 异构引擎无差别流量调度
多LoRA动态流量调度、模型切换的流量调度	实现不同引擎多LoRA的动态装、卸载，集成LoRA-aware 的动态流量感知调度能力；
精确的前缀感知Cache-aware流量调度	实时订阅引擎侧KV Events Metrics，构建精确的前缀缓存画像，实现更高效的prefix cache亲和调度，进一步降低推理TTFT；
基于时延预测的SLO-aware 流量优先级感知调度	利用延迟预测来估算每个请求在每个可用节点上的首次生成时间（TTFT）和每个输出令牌时间（TPOT），实现基于时延预测的SLO-aware智能调度；

2. 容器编排与资源调度

 

•部署灵活：PD分离部署，具有Group和Pool两种模式，实现弹性扩缩容与拓扑感知调度。

•高可用机制：多副本部署，避免单点故障。同时支持故障时自动摘流与容器自愈，保障服务持续可用，用户无感知。

 

核心能力	说明
容器编排	根据推理引擎工作特点，基于容器之间的协作关系（Kimi多容器跨机推理、PD分离架构等），将各个推理引擎容器一定的组织方式部署成一组Pods，并联动服务发现、重启策略。
GPU资源调度	自动将各个新创建的Pod调度到具有足够GPU资源的机器节点。
拓扑感知调度	Kimi跨机推理， TP16部署的2台机器保证在同一个交换机下；PD分离部署，协作关系的P和D在同一个交换机下。
优先级调度和抢占	支持在线服务和离线任务的混合调度，高优的在线服务可以抢占低优任务的GPU资源。

3. 系统稳定性与可观测

•集成流量镜像、全链路告警与主备值班协同机制。

•通过网关大盘、调度模块监控、模型性能面板等多层次观测体系，实现问题快速发现与定位。

 

 

4. 引擎优化与性能突破

针对MoE、多模态等模型特点，通过算子优化、引擎调优与量化等手段，在多项关键性能指标上实现行业领先。

 

二、关键场景落地与收益量化

1. 长短文混合调度

问题：长、短文请求混合排队时，短文TTFT急剧上升，集群吞吐下降。 方案：通过长短文分桶与跨集群调度，实现长短文分离处理。

收益（以Kimi-K2与DeepSeek-V3压测为例）：

•Kimi-K2：短文TTFT降低90.97%，吞吐提升124.46%；长文吞吐提升33.89%，集群整体吞吐提升67%。

•DeepSeek-V3：短文TTFT降低79.09%，吞吐提升36.7%；长文吞吐提升14.34%，集群整体吞吐提升21.82%。

 

2. KV Cache全局感知的流量调度

问题：多副本场景下相同前缀请求被随机调度，导致每个实例都重复计算并缓存相同前缀。 方案：持续刻画更新集群级KV Cache缓存画像，实现前缀匹配的智能路由，KV Cache高效复用。

收益：

•DeepSeek-V3场景下，集群吞吐提升29.9%，首Token时延TTFT降低28.7%；

•Kimi-K2场景下，KV Cache命中率整体提升20%~30%。

旧系统：均值 60%、22%、12%	云原生系统：均值 90%、45%、22%

3. 全场景自动弹性伸缩

问题：夜间或周末的流量低谷期GPU资源闲置严重。 方案：通过多种弹性部署模式并基于排队长度与KV使用率等多项指标，实现全场景自动扩缩容。

收益：

•周级别节省GPU卡时5000+，资源利用率提升26%；

 

占用卡量：随负载 弹性扩缩

 

4. 硬件拓扑亲和调度

问题：跨交换机部署导致性能下降；人工修正部署成本高，维护压力大。 方案：

•通过节点标签与亲和性规则，实现交换机级自动拓扑亲和调度；

•Router实现按组进行PD配对流量调度。

收益：

•组容器间通信不跨交换机，数据高效传输，全程自动化，无需人工干预，保证服务SLA。

 

 

 

5. 稳定性与业务连续性

问题：容器故障后，因分发机制导致持续的客户影响。故障恢复强依赖人工，导致故障时间长，修复难度大。

方案：通过实时健康监测，快速感知故障容器，进行隔离。启动新副本，实现故障自愈。

收益：

•实现自动隔离，自动自愈，无需人工干预，节点人力成本，提高用户体验。

 

 

6.推理引擎无感接入

问题：多引擎支持成本高，定制化开发量大，维护成本高。 方案：构建统一推理引擎调度接入层，支持vLLM、SGLang等不同推理引擎一键接入。

收益：

•推理引擎无感快速接入。

•降低开发与维护成本。

 

 

三、收益总结

京东云云原生AI推理框架通过多维度调度与系统级优化，显著提升了推理效率与资源利用率。短文与长文吞吐均有大幅增长，首 token 延迟明显降低，并结合自动弹性扩缩容与 KV Cache 感知调度，进一步提升集群吞吐与缓存命中率，同时节省可观的 GPU 卡时成本。在此基础上，引入硬件拓扑亲和调度，实现更高效的自动化部署与调度，降低大规模集群运维压力；配合故障自愈、高可用机制与更精细的可观测体系，使系统运行更加稳定、可控、易排障。通过针对引擎瓶颈的持续优化，不同模型场景下的吞吐能力均得到明显增强。

能力	量化结果与效益
长短文调度	吞吐：短文提升120%+，长文提升30%+ TTFT：短文降低90%
自动弹性扩缩容	GPU卡时：节省GPU卡时约26%
KV Cache感知调度	提升KV Cache命中率：增长约20%~30% TTFT：降低29% 集群吞吐：增长30%
硬件拓扑亲和调度	实现自动化部署与调度，降低大规模集群运维成本
故障自愈与高可用	自动检测故障、自动恢复故障，减少对人工的依赖，更具可控性
可观测性	具备更细致的监控告警体系、提升故障发现和排查效率
引擎瓶颈优化	DS-MoE模型吞吐提升9%，多模态模型吞吐最高提升39%

四、客户案例

客户背景

客户原系统面临AI规模化落地的挑战，在推理系统的稳定性、性能和资源利用率方面遇到了明显瓶颈。京东云通过帮助客户升级至云原生架构，成功改造了其推理系统，实现显著的性能提升和资源节约。见证了新系统如何带来切实的业务效益。

解决方案

京东云通过云原生AI推理框架对客户原78台节点进行逐步云原生改造，在不到一个月时间内从最初的2%切流比率提升到达到40%，实现对用户AI推理系统的云原生重构，助力企业实现高效、稳定、低成本的AI规模化落地。核心方案包括：采用智能流量调度技术，通过长短文分桶、KV缓存复用及拓扑感知调度；基于流量波动的弹性扩缩容机制；高可用架构通过多副本部署与故障自愈保障服务连续性；支持vLLM、SGLang等主流引擎的无感接入；硬件拓扑优化实现跨交换机亲和调度，减少传输延迟。

 

 

客户收益

 

•GPU吞吐能力：切换云原生系统后，GPU吞吐提升幅度达74%。这一增强使客户在高负载情况下依然能够维持高效的模型推理速度。

•限流数量：云原生AI推理框架系统将需要限流的请求显著减少82%，这意味着更多的客户请求在高峰时段得到及时响应，提高了用户体验和满意度。

	整体	旧版系统	云原生系统	收益
机器规模	78 (100%)	50 (64%)	28 (36%)	-
请求数量	36671 (100%)	17091 (47%)	19580 (53%)	-
GPU吞吐 (TGS)	-	183	319	提升74%
限流数量	687 ( 1.87%)	570 (3.3%)	117 (0.59%)	减少82%
备注： 1、数据来源基于Kimi-K2-instruct-0905模型。

客户对于系统的云原生改造表示高度认可：“云原生AI系统的导入，让我们不仅在资源利用上实现了显著的性价比提升，同时在关键业务高峰期的响应能力也大大增强，显著减少了因限流带来的服务瓶颈问题。”

 

 

五、未来展望

京东云将继续优化云原生AI推理框架，致力于为客户提供更智能、高效、稳定的AI基础设施。通过在各个行业和应用场景中的深化应用，我们的客户可以持续依赖这一平台，实现业务的长期可持续发展。

这个成功案例不仅展示了京东云云原生AI推理框架系统的技术优势，也为其他企业提供了一个可借鉴的成功模型，期待更多客户从中获益。

京东云云原生AI推理框架的研发升级并非一蹴而就。从架构设计、配置调试再到全量上线，每一步都围绕着业务价值、性能提升与运维提效展开。我们相信，只有将稳定性、性能、成本三者统筹兼顾的基础设施，才能真正支撑AI业务规模化、可持续地落地与增长。如您有类似场景或技术交流需求，欢迎随时联系我们。