先看证据
把机制串起来
Kinference 部署在 Kubernetes 上，用于管理 vLLM 推理服务。它充当 vLLM 工作节点集群的前端，接收推理请求并决定将请求发送到哪个 vLLM 实例。核心能力在于理解 LLM 推理的特性，如 KV 缓存共享，以优化请求路由和负载均衡。
Kinference 通过监控 vLLM 的 KV 缓存事件和引擎指标，实现 KV 缓存感知的路由。它会估算每个 vLLM 实例处理请求的预期首 token 延迟 (TTFT)，考虑缓存命中率和队列长度。基于用户定义的策略（通过 CRDs 配置），Kinference 将请求路由到预测 TTFT 最低的实例，以最小化延迟。
['适用于内部模型服务，特别是多租户场景。', '在 GPU 资源有限、模型间有缓存共享时效果显著。', '不适用于请求无显著前缀重叠的通用负载均衡。', '部署依赖于 Kubernetes 和 vLLM 环境。']
LLM 推理面临的 Kubernetes 挑战
随着大型语言模型（LLM）在各种应用中普及，如何在 Kubernetes 集群中高效地部署和管理这些模型成为了一个关键问题。传统的 Kubernetes Service 负载均衡机制，通常是基于简单的轮询或随机策略，无法理解 LLM 推理请求的内在特性，特别是对 KV 缓存（Key-Value Cache）的有效利用。这种机制的低效直接导致了响应延迟的增加，尤其是在处理具有相似请求前缀的对话或多轮交互时，模型无法充分利用已有的缓存信息，从而造成不必要的计算和时间浪费。
Buoyant 推出的 Kinference 正是为了解决这一痛点而生。它并非替代 vLLM 这样的推理引擎，而是构建在其之上，作为一层“控制平面”，负责将流量智能地导向最合适的 vLLM 工作节点。Kinference 的出现，标志着 LLM 推理服务在 Kubernetes 生态中的管理正从“尽力而为”转向“策略驱动”，以更精细的粒度来优化性能。
Kinference 核心机制：KV 缓存感知路由
Kinference 的核心竞争力在于其对 vLLM KV 缓存的深度理解和利用。当请求到达 Kinference 时，它不会简单地将其分配给任何一个可用的 vLLM 实例。相反，它会评估多个候选 vLLM 工作节点的预期首 Token 时间（TTFT）和整体端到端延迟。这一评估过程综合了多项关键信号：首先是租户信息、模型请求、提示词长度以及可能的语义标签，这些构成了请求的基本属性；其次，也是最重要的，是 Kinference 对每个 vLLM 工作节点 KV 缓存状态的实时监控。通过与 vLLM 引擎交互，Kinference 能够感知到不同节点上缓存的共享前缀重合度以及当前的队列长度。
基于这些信息，Kinference 采用一种预测性的路由策略。它利用 NVIDIA 的 dynamo-kv-router crate 来处理 KV 缓存事件，并结合模型分词（tokenization）能力，精确估算将请求发送到特定节点所产生的 TTFT。其目标是将请求路由到预测延迟最低的节点。这种机制尤其在处理具有大量共享前缀的流量时表现出色。例如，在 Buoyant 的基准测试中，通过 Kinference 路由的共享前缀工作负载，其 median TTFT 从 6.88 秒骤降至 0.31 秒，性能提升高达 95%。这直接归因于 Kinference 能够识别并利用那些已经加载了相似上下文的 vLLM 实例，避免了重复计算。
声明式策略与多租户支持
除了 KV 缓存感知路由，Kinference 还引入了强大的声明式策略，允许用户通过 Kubernetes 自定义资源（CRDs）来定义复杂的流量管理规则。这包括了 GatewayBackend、InferencePolicy、InferencePool、InferenceProvider 和 InferenceWorkerSet 等 CRDs，它们共同构成了一个灵活的配置框架。例如，`InferencePolicy` CRD 允许定义如何根据租户 ID、请求的模型名称、提示词长度、GPU 池状态甚至自定义的语义标签（如 PII 标记）来路由或拒绝请求。
这种策略驱动的方式带来了显著的灵活性。用户可以配置“简单到更便宜”的策略，将低复杂度请求路由到更小的模型，除非缓存重叠使得大模型更快。还可以实现“突发到云端”的策略，在本地工作节点过载时，将请求转发到 Bedrock 等云服务提供商。安全性方面，可以设定“PII 留本地”策略，当检测到 PII 标签时，阻止外部路由并执行“关闭失败”（fail closed）的操作。此外，还有“在空闲 GPU 上批量处理”和“模型别名”等策略，为模型服务提供了前所未有的控制力。这些策略可以存储在 Git 中，并通过 `kinfctl` CLI 进行离线验证，极大地简化了部署和管理流程。
基准测试结果与性能提升
Buoyant 发布了一系列基准测试结果，以量化 Kinference 相较于原生 Kubernetes Service 路由的性能提升。在测试中，Kinference 和传统的 Kubernetes Service 都部署了由三个 vLLM 0.31.0 pod 组成的池，每个 pod 运行在一个 L40S GPU 上，并使用 Qwen-3.8-27B-FP8 模型。流量由 GuideLLM 0.8.1 生成，并侧重于不同类型的负载。
最为显著的性能提升出现在处理具有共享前缀的工作负载上。在此场景下，Kinference 的 median TTFT 从 6.88 秒大幅降低至 0.31 秒，降幅高达 95%。端到端的 median 延迟也从 20.5 秒减少到 11.3 秒，降低了约 45%。对于多轮对话场景，median TTFT 从 1.70 秒下降到 0.59 秒（约 65% 的降幅），端到端延迟也从 13.4 秒降至 9.1 秒（约 32% 的降幅）。在容量测试方面，Kinference 在共享前缀工作负载上实现了约对照组 7.4 倍的峰值吞吐量，多轮对话场景下也实现了约 3.5 倍的提升。
然而，基准测试也揭示了 Kinference 的适用边界。在没有共享前缀的对照组测试中，Kinference 的 median TTFT（6.83 秒）与 Kubernetes Service（6.92 秒）相比，并无显著差异。这表明 Kinference 的性能优势高度依赖于请求的共享前缀特性，而非普遍性的低延迟保证。
部署与配置：Kubernetes CRD 的力量
Kinference 的部署和配置深度集成于 Kubernetes 生态，其核心是通过一套自定义资源定义（CRDs）来实现。用户需要根据自己的服务需求，创建和管理这些 CRDs，包括 `GatewayBackend`（定义后端服务）、`InferencePolicy`（定义路由和处理逻辑）、`InferencePool`（定义一组 vLLM 工作节点）以及 `InferenceProvider` 和 `InferenceWorkerSet`（用于更细粒度的节点管理）。这种声明式配置方式，使得 Kinference 的行为完全可以通过 YAML 文件来定义和版本控制，极大地提升了部署的可重复性和可管理性。
例如，一个典型的部署流程可能涉及定义一个 `InferencePool`，其中包含指向 vLLM 工作节点的标签选择器，以及设置一个 `InferencePolicy` 来指定如何根据租户 ID 或模型名称来路由请求。Kinference 控制器会持续监听这些 CRDs 的变化，并动态调整流量网关（通常是 Buoyant Gateway）的行为。这种方法使得 Kinference 能够无缝地融入现有的 Kubernetes CI/CD 流程。官方文档提供了 `kinfctl` 命令行工具，用于本地验证 CRD 配置，并在部署前捕获潜在错误，这对于确保生产环境的稳定性至关重要。
潜在代价与适用边界
尽管 Kinference 带来了显著的性能优势，但它也引入了额外的复杂性和潜在的代价。首先，Kinference 本身作为一个控制平面，需要独立部署和维护，这增加了整体系统的运维负担。其次，其配置依赖于一套新的 Kubernetes CRDs，团队需要投入时间去学习和掌握这些资源类型及其相互作用。虽然 `kinfctl` 提供了辅助验证，但对于不熟悉 Kubernetes 扩展机制的团队来说，配置的调试可能仍具挑战性。
性能方面，Kinference 的关键优势在于其 KV 缓存感知路由，这意味着它在处理非共享前缀或无缓存依赖的请求时，性能提升可能不明显，甚至与标准 Kubernetes Service 相当。Buoyant 的基准测试结果也证实了这一点：在无共享前缀的场景下，TTFT 几乎没有变化。因此，Kinference 的价值最大化体现在需要服务大量共享上下文的 LLM 应用，如长对话助手、代码生成或需要检索增强生成（RAG）的场景。对于那些请求高度独立的模型服务，Kinference 的投资回报率可能需要仔细评估。