云原生服务网格 Linkerd 背后的公司 Buoyant 在 2026 年 11 月 4 日正式发布了开源项目 Kinference（当前版本 v0.1.0-alpha.7）。这是一个用 Rust 编写、采用 Apache 2.0 协议的 Kubernetes 与 vLLM 推理控制平面。在搭载 3 张 L40S GPU、运行 vLLM 0.31.0 与 Qwen3.8-27B-FP8 模型的测试中，Kinference 将共享前缀负载下的中位首字延迟（TTFT）从 6.88 秒压到了 0.31 秒，降幅达 95%，满足服务等级目标（SLO）的峰值有效吞吐量从 14.0 req/min 跃升至 103.0 req/min（约 7.4 倍）。大模型推理的战场正在从单机引擎调优转向集群流量调度，但撕开这组跑分标签，Kinference 现阶段更像一份向 AI 基础设施探路的架构原型，离企业核心生产环境还有不小距离。
95% 延迟暴降背后：只救预填充，不救生成
传统微服务是无状态的，Kubernetes 原生的 kube-proxy（ClusterIP）把请求随机或轮询分发给后端节点即可。但大模型推理天生带有厚重的状态。当多轮对话或智能体（Agent）携带长系统提示词进入集群时，GPU 显存里的 KV 缓存如果能被复用，就能省去极其耗时的预填充（Prefill）计算；一旦被原生 Kubernetes 随机打散到不同节点，缓存就会失效，引发高昂的重复计算。
Buoyant 提出的解法是让 vLLM 退居数据面，由 Kinference 接管控制面。在 GuideLLM 0.8.1 驱动的基准测试中（延迟测试含 18 次运行，每次 60 秒预热、240 秒测量、45 秒冷却；容量测试在 4、8、16、24、32 并发下运行 60 次），研发团队设计了三组对照负载：控制组输入 16,256 个唯一 token；共享前缀组从 24 个 16,000-token 的长前缀中任选其一，再拼接 256 个唯一 token；多轮对话组从 8,000-token 起步，每轮叠加 400 个新 token 并持续 8 轮。
测试结果揭示了 KV 缓存路由的真实边界。在共享前缀组中，中位端到端（E2E）延迟从 20.5 秒降至 11.3 秒（下降 45%），p95 TTFT 从 18.32 秒降至 9.24 秒；多轮对话组的中位 TTFT 也从 1.70 秒降至 0.59 秒，有效吞吐从 23.8 req/min 涨至 82.7 req/min。但在毫无重合前缀的控制组里，Kinference 的中位 TTFT 为 6.83 秒，与原生路由的 6.92 秒基本持平，仅靠队列感知均衡把 p95 TTFT 从 21.46 秒拉低到 12.33 秒。更关键的是，进入逐字吐出的解码（Decode）阶段后，共享前缀组的中位词间延迟（ITL）仅从 44 毫秒微降至 42 毫秒。
缓存路由只能省下算过的题，救不了逐字生成的慢。
此外，这组高达 7.4 倍的吞吐增幅立在一个宽松的前提之上。Buoyant 将测试的 TTFT 达标线（SLO）设定为 8 秒与 4 秒，并坦言这一标准只适合后台离线运行的 Agent，无法满足人类用户对实时聊天首字响应的严苛预期；且其对比靶子是最原始的 kube-proxy 随机路由，而非市面上的同类缓存感知路由器。
借力 NVIDIA 底层，把路由策略写成 GitOps 代码
既然 CNCF 沙箱项目 llm-d（由 Red Hat、Google Cloud、IBM、CoreWeave 与 NVIDIA 支持，2026 年 5 月已迭代至 v0.7）和 NVIDIA 自家的 Dynamo（已演进至 1.5.1 容器版本）都已支持 KV 缓存感知路由，甚至具备预填充与解码分离（Disaggregated prefill/decode）以及跨 SGLang、TensorRT-LLM 的多引擎调度能力，半路杀出的 Buoyant 凭什么争抢入口？
查阅 Kinference 的 GitHub 代码库可以发现，它由 kinference-policy、kinference-fleet、kinference-router、kinference-controller、kinference 和 kinfctl 六个核心 Rust crate 组成。有趣的是，其最核心的 vLLM KV 缓存事件追踪与处理模块，并没有从头造轮子，而是直接集成了竞争对手 NVIDIA 开源的 dynamo-kv-router crate。
Buoyant 真正的差异化落点在于上层流量治理。团队将当年在 Linkerd 上打磨成熟的云原生配置哲学搬了过来，把复杂的推理路由拆解为 GatewayBackend、InferencePolicy、InferencePool、InferenceProvider 和 InferenceWorkerSet 五个 Kubernetes 自定义资源（CRD）。平台工程师可以用声明式代码定义五类典型策略（均以 minimize: PredictedTTFT 收尾，结合缓存重叠度与队列长度预测耗时），并通过 kinfctl 命令行工具在 Git 仓库里做离线校验：
- 按复杂度降级.将低复杂度提示词路由给小模型，除非大模型的缓存命中反而能让响应更快。
- 云端算力溢出.当本地节点排队请求超过 2 个时自动跳过，将溢出流量回退至 Amazon Bedrock 等外部托管商。
- 隐私数据留存.触发个人敏感信息（PII）标签时剔除外部供应商，通过
onEmpty: Reject强制本地闭环处理。 - 闲置算力批处理.仅向 KV 缓存占用率低于 70% 的工作节点派发批处理任务。
- 模型别名映射.对外暴露
standard-model等统一名称，在后台无缝切换多个开源权重模型。
这套蓝图对运维多个开源模型、服务内部多团队的平台部门极具吸引力。但交叉核对官方宣传与 GitHub 仓库文档，能看到明显的交付时差。官方介绍与架构图将 Token 速率限制、按语义标签路由作为核心卖点，但 v0.1.0-alpha.7 的代码库说明里明确标注：Token 速率限制、驱动低复杂度与 PII 识别的语义分类器、控制面多副本高可用（multiple replicas），以及 Anthropic /v1/messages 接口支持，在当前版本中均未实现。
| 方案名称 | 核心主导方 | 底层引擎覆盖 | 突出优势与当前短板 |
|---|---|---|---|
| Kinference | Buoyant | 仅 vLLM | 拥有 5 个声明式策略 CRD 与云端溢出设计；处于 v0.1.0-alpha.7，缺多副本与限流 |
| llm-d | CNCF 沙箱 | vLLM, SGLang | 具备多租户流控与分离式推理，在 4x MI300X 上吞吐提升 3 倍；无声明式策略 CRD |
| NVIDIA Dynamo | NVIDIA | vLLM, SGLang, TRT-LLM | 1.x 版本成熟度高，支持分离式推理与 GAIE 网关限流；架构较重 |
生产落地的隐秘暗礁：分词失步与静默退化
对于正在选型的企业基础设施团队而言，即便等来了 Kinference 补齐多副本高可用与限流模块，想要在生产环境吃下 KV 缓存感知路由的红利，还得跨过整个赛道共同面临的工程暗礁。
KV 缓存路由之所以能准确预测哪张显卡上有现成的缓存块，前提是位于前端的路由器与后端的 vLLM 引擎对同一段文本做出分毫不差的分词（Tokenization）和提示词模板渲染。在真实的开源社区反馈中，这一被称作信号保真度（Signal Fidelity）的链条非常脆弱。
以先一步落地的同类项目为例，llm-d 社区就曾暴露出因为 /render 端点的分词逻辑变更，导致路由器算出的 Token 序列与 vLLM 实际接收的序列不一致，直接引发缓存命中率暴跌；NVIDIA Dynamo 在分离式推理场景下也出现过 KV 块状态未能正确填充的缺陷，导致智能路由在毫无报错告警的情况下，静默退化成了普通的按负载路由。
- 风险.当前 v0.1.0-alpha.7 缺少控制面多副本与限流保护，且 KV 感知路由高度依赖两端分词一致，盲目上生产极易遭遇单点故障或缓存静默失效。
传统微服务网格卖的是连接与可观测性，而在 Kubernetes 增长放缓的今天，Buoyant 试图用 Gateway API v1.5.1 加上 5 个私有 CRD，在 AI 推理网关混战中抢下一席之地。对于平台工程师来说，现在可以在测试集群里用 Helm 装上它的 Prometheus 与 Grafana 面板，观察多租户下的缓存命中Token比例；但要把真金白银的生产流量交出去，至少得等到它把单点控制面改成高可用，并证明自己不会在分词同步上掉链子。