作者：马国忠
引言：AI规模化落地，推理系统面临全新挑战
全球领先的市场研究和咨询公司IDC预测，到2028年，75%的新 AI 工作负载将实现容器化，从而显著提升模型与工作负载更新的速度、一致性与安全性。容器化技术将成为 AI 推理时代的"默认交付形态"。当前随着大模型技术快速演进与业务场景的深度融合，AI业务对推理基础设施的需求呈现爆发式增长。在早期小流量场景下，手动部署与定制化方案尚可应对；然而当模型规模、并发请求与业务复杂度攀升至新高度时，传统推理系统在以下四个主要方面逐渐暴露出瓶颈。
- 稳定性不足：
◦单点故障风险：手动部署的静态架构缺乏多副本与故障自愈机制，单节点宕机易引发服务中断；
◦负载不均衡：缺乏智能流量调度，高并发时部分节点过载导致响应延迟，低负载时资源闲置；
◦故障恢复滞后：依赖人工排查与重启，恢复周期长，影响业务连续性。
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业务规模化、可持续地落地与增长。如您有类似场景或技术交流需求，欢迎随时联系我们。