Buoyant发布Kinference：面向Kubernetes与vLLM的开源推理控制平面

Buoyant，即 Linkerd 背后的公司，发布了 Kinference，一个用于在 Kubernetes 上构建推理平台的开源项目。Kinference 是面向 Kubernetes 和 vLLM 的推理控制平面。它位于一组 vLLM 工作节点之前，决定每个请求的去向。它在一层中实现了路由策略、token 速率限制、KV-cache 感知的负载均衡以及按租户的指标。对于需要向众多内部客户端提供众多开放权重模型的开发团队来说，它瞄准的是模型服务器之上的那一层。该项目在 GitHub 上以 Apache 2.0 许可证发布。当前版本为 v0.1.0-alpha.7。

TL;DR

• 规模：v0.1.0-alpha.7，使用 Rust 编写，Apache 2.0 许可证，通过 5 个 Kubernetes CRD 进行配置。
• 运行环境：任何运行 vLLM 的 GPU Kubernetes 集群。Buoyant 的基准测试每个池使用 3 块 L40S GPU。
• 性能：在前缀密集的流量上，相比普通的 Kubernetes Service 路由有大幅提升（自报数据）。
• 最佳情况：在共享前缀的工作负载上，中位 TTFT 从 6.88 秒降至 0.31 秒（95%）。
• 最差情况：在没有共享前缀的提示上，中位 TTFT 没有提升（6.92 秒 vs 6.83 秒）。

什么是 Kinference？

Kinference 是一个策略驱动的控制平面，将 Kubernetes 加 vLLM 转变为多租户推理平台。Buoyant 的 FAQ 简单明了地概括为：vLLM 是数据平面，Kinference 是控制平面。

Kinference 如何工作？

该系统由两部分组成：流量网关和推理处理器。GitHub README 指出，处理器暴露一个 gRPC 接口。它接收请求并返回选定的端点以及可能被修改的请求体。它与 Buoyant Gateway 之类的代理配合使用。 Kinference 监视 vLLM 的 KV-cache 事件和引擎指标。它目前使用 NVIDIA 的 dynamo-kv-router crate 来处理缓存事件。配置存放在 5 个 CRD 中：GatewayBackend、InferencePolicy、InferencePool、InferenceProvider 和 InferenceWorkerSet。

什么是推理策略？

推理策略是声明式规则，规定每个请求如何被路由或拒绝。规则可以基于租户、请求的模型、GPU 池状态和语义标签进行匹配。项目站点上的示例策略涵盖了 5 种模式：

• 简单任务转廉价模型：将低复杂度提示路由到较小的模型，除非缓存重叠使大模型更快。
• 突发流量转云：跳过排队超过 2 个提示的工作节点，然后回退到 Bedrock 等提供商。
• PII 留在本地：当 PII 标签触发时移除外部提供商，并通过 onEmpty: Reject 失败关闭。
• 空闲 GPU 上批处理：仅将批处理请求发送到 KV-cache 使用率低于 70% 的工作节点。
• 模型别名：发布一个稳定的名称，例如 standard-model，由多个模型支撑。 大多数规则以 minimize: PredictedTTFT 结尾。Kinference 利用缓存重叠和队列长度，预测每个候选端点的首 token 时间。策略存放在 git 中，可以通过 kinfctl CLI 离线验证。

Kinference 在基准测试中有多快？

Buoyant 发布了一项针对普通 Kubernetes 负载均衡的基准测试。每个实验组使用 3 个 vLLM 0.31.0 pod，每个 pod 运行在 1 块 L40S GPU 上。模型为 Qwen3.8-27B-FP8。负载来自 GuideLLM 0.8.1。基线是一个 ClusterIP Service，其中 kube-proxy 为每个连接随机选择一个 pod。 无负载延迟结果（中位 TTFT）： 工作负载Kubernetes ServiceKinference变化 对照组（无共享前缀）6.92 秒6.83 秒无显著差异 共享前缀6.88 秒0.31 秒约 -95% 多轮对话1.70 秒0.59 秒约 -65% 中位端到端延迟在共享前缀上下降了 45%，在多轮对话上下降了 32%。在对照流量上，p95 TTFT 仍从 21.46 秒降至 12.33 秒。Buoyant 将此归因于队列感知的负载均衡。 容量测试测量了有效吞吐量：满足 TTFT SLO 的每分钟请求数。在共享前缀上，峰值有效吞吐量为 103.0 对 14.0 req/min，约 7.4 倍。在多轮对话上为 82.7 对 23.8，约 3.5 倍。Service 基线在所有测试的并发级别下都从未满足 SLO。 这些数据是自报的。基线是随机路由，而非 llm-d 或 Dynamo 这样的缓存感知路由器。Buoyant 还指出，其 SLO（8 秒和 4 秒）适用于离线 agent，而非聊天。

Kinference 与 llm-d、Dynamo 和 Production Stack 相比如何？

特性Kinferencellm-dNVIDIA DynamovLLM Production Stack 支持方BuoyantCNCF 沙箱（Red Hat、Google Cloud、IBM、CoreWeave、NVIDIA）NVIDIAvLLM 项目 许可证Apache 2.0Apache 2.0Apache 2.0Apache 2.0 成熟度v0.1.0-alpha.7v0.7（2026 年 5 月）1.x（1.5.1 容器）参考栈 引擎vLLM（计划支持 SGLang、TensorRT-LLM）vLLM、SGLangvLLM、SGLang、TensorRT-LLMvLLM KV-cache 感知路由是，预测 TTFT是，前缀缓存和预测延迟是，KV 感知路由器基于会话；前缀感知列为进行中 声明式路由策略 CRD是（InferencePolicy）README 中未记录README 中未记录README 中未记录 突发到外部提供商是（InferenceProvider）README 中未记录README 中未记录README 中未记录 分离式 prefill/decode未披露是是路线图中 多租户控制按租户指标；速率限制计划中多租户服务的流控通过 GAIE 的网关级速率限制README 中未记录 主要结果相比 kube-proxy 中位 TTFT -95%（3x L40S）相比轮询吞吐量 3 倍，TTFT 快 2 倍（4x MI300X）KV 感知路由下 TTFT 快 2 倍（Baseten）未披露 Kinference 的独特角度是治理：策略、别名、提供商回退和租户核算。llm-d 和 Dynamo 在原始服务性能、分离和引擎覆盖方面领先。

部署与可用性

根据入门指南，安装需要 5 个步骤。团队先安装 Gateway API v1.5.1 CRD、Buoyant gateway Helm chart，然后安装 Kinference chart。Kinference 附带 Prometheus 指标和 Grafana 仪表板。指标包括 TTFT、ITL、端到端延迟以及缓存与未缓存提示 token，大部分按租户划分。

关键要点

• Kinference 是面向 Kubernetes 上 vLLM 的 Apache 2.0 控制平面，来自 Linkerd 的开发者 Buoyant。
• 声明式 InferencePolicy 规则处理模型选择、提供商突发、PII 路由和批处理准入。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）