[2025年7月21日]() Best practices, New features
AIbrix, dynamo,inference engines, kserve,kubernetes,llm-d, Imignite,Modula,orchestration, orchestrator,production stack,scale, SGLang OME,
作者：Junchen Jiang, Hanchen Li and Jake Sonsini
简要总结：大语言模型正迅速成为企业AI中的主要工作负载。当越来越多的应用依赖实时生成，推理性能——速度、成本、可靠性——就成了头号瓶颈。如今，业界几乎把全部注意力都放在“加速推理引擎”上（vLLM、SGLang、TensorRT 等），却忽视了一片更大的优化疆域：引擎之上、跨引擎的整个系统层。
现状: 大规模复制推理引擎
如今的大语言模型推理系统由两大核心组件构成：
- 推理引擎： 针对单个模型实例优化推理性能。
- 编排层： 借助 Kubernetes 等工具，复制这些引擎以实现水平扩展。
这种“以引擎为中心”的思维假定，绝大部分性能增益都源于引擎内部；编排层被视为一层“薄”且几乎无状态的外壳——只需启动更多副本即可提升吞吐量。
该模型驱动了以下开源系统：
- vLLM 生产技术栈（主要由 LMCache 实验室维护）
- RedHat 的 Ilm-d 与 KServe
- Nvidia 的 Al Dynamo
- 字节跳动的 AlBrix
- Modular
- SGLang OME 及类似推理平台
这些方案在横向扩展方面表现良好，但当需要更深层次的系统级优化时，它们便会遇到瓶颈。
新前沿：超越引擎的 LLM 原生优化
真正的性能提升在于“跨引擎”的智能编排——通过共享状态、复用计算和全局优化。例如：
- 动态 prefill/decode 分离
- 跨会话的 KV cache共享（传输、压缩）
- 在线 KV cache更新（融合、编辑、翻译）
- 请求路径之外的休眠时间计算
- 查询迁移与跨 Agent 的流水线
这些优化需要“有状态的协同”和“智能调度”——原生 Kubernetes 方案很难直接提供。正因如此，在编排层进行创新，才能带来显著的性能收益。
问题不在 Kubernetes 本身——但它还不够
先说清楚：我们并不是在说 Kubernetes 没用。它是现代软件基础设施的核心组件。我们的意思是——仅靠 Kubernetes 来做 LLM 推理编排，会限制所能达到的上限。以下是现有基于K8s的开源系统不足的原因：
仅支持无状态的副本
Kubernetes 把所有 Pod 都当作无状态、同质的单元。
然而，LLM 工作负载依赖共享、有状态的组件，如 KV cache和中间工具调用状态。
LLM 时代的许多优化都要求态持久化并在请求和副本间共享——这正是 Kubernetes 原生所不支持的。
仅支持请求驱动执行
像缓存压缩、休眠时预取或后台融合这类优化，都需要在关键请求路径之外进行计算。
然而，基于 Kubernetes 的编排器是基于请求-响应模型构建的——没有简单的方法可以与主流推理工作同时调度或中断后台作业
不适合 LLM 特有的逻辑
特定于推理的调度（例如，优先考虑延迟敏感型作业而非后台作业）很难在现有的编排框架中实现。更糟的是，大多数系统用 Go 或 Rust 编写——这些语言并不适合张量密集型, 类Python 工作负载的快速原型设计。
部署与运维难度高
与 OpenAI、Claude、Fireworks 或 Together AI 这类 API 或专用端点方案相比，基于 Kubernetes 的推理栈部署和运维要复杂得多。即便拥有基础设施经验的团队，也随着更多优化和“补丁”被层层叠加到本就复杂的系统中而难以跟上。
归根结底：推理优化的前沿推进得越远，仅依赖 Kubernetes 的架构就越成为瓶颈
我们需要什么：LLM 原生的编排器
为支持下一代推理工作负载，我们需要一款专为 LLM 打造的编排器，它应：
- 支持面向张量的通信与状态共享（用于 KV 缓存复用、迁移与流水线）
- 允许可中断的后台任务（用于压缩、融合及非请求类计算）
- 在实时任务与后台任务之间调度，能感知延迟、资源占用和依赖关系
- 即使团队缺乏深厚基础设施经验，也能轻松部署与运维
这不是取代 Kubernetes，而是对其补充。Kubernetes 仍可负责容器生命周期、节点扩缩和集群管理；但推理工作负载本身需要理解 LLM 特有模式的编排逻辑
下一步
我们构建了一个 LLM 原生编排解决方案来满足这些需求，在不牺牲可用性的情况下支持强大的系统级优化。在下一篇文章中，我们将分享有关其架构、性能和实际部署的详细信息，敬请期待。
链接
LMCache Github: https://github.com/LMCache/LMCache
与开发者沟通 Interest Form
LMCache slack
vLLM生成技术栈 channel
发表评论