Kinference 怎么装：vLLM 控制面首字延迟 6.88 秒压到 0.31 秒

一句话结论：Kinference 是 Buoyant 开源的 vLLM 推理控制面，把多模型、多租户、多 GPU 的调度问题从 vLLM 数据面里剥出来单独一层管，在共享前缀负载下能把首字延迟中位数从 6.88 秒压到 0.31 秒。

如果你手上的 vLLM 服务只服务一个团队一个模型，这套东西看着多余。但只要开始同时跑多个开放权重模型、并且要让不同团队按不同优先级用，路由策略、限速、租户计费这三件事就会同时压过来，全塞进 vLLM 自己就变成了耦合。Kinference 的思路是把控制面独立出来，让 vLLM 退回到它擅长的那件事上：把一个模型推理得又快又稳。

项目由 Linkerd 背后的 Buoyant 团队在 2026 年 11 月 4 日开源，采用 Apache 2.0 协议，代码用 Rust 写，当前版本是 v0.1.0-alpha.7，仓库在 GitHub 上名为 Kinference-AI/kinference。它不是又一个推理引擎，vLLM、SGLang、TensorRTLLM 都还是它底下的引擎，它自己只做一件事：在这些引擎前面决定请求该发给谁。

控制面和数据面到底差在哪

把整套东西拆开看，Kinference 只有两个部分。流量网关负责接收请求，推理处理器暴露 gRPC 接口，接住请求后返回一个被选中的端点，以及一份可能被改写过的请求体。改写请求体这件事常被忽略，但它是策略能落地的前提，比如把一个昂贵模型请求换成便宜模型时，光换端点没用，还得把请求里的模型字段一起改掉。

它和 vLLM 的关系可以用一句话概括：vLLM 是数据面，Kinference 是控制面。数据面关心的是这一个模型的推理吞吐、批处理效率、显存占用；控制面关心的是这个请求归谁、限多少 token、算完记在哪个租户账上、GPU 打满时要不要溢出到云上。这两类关注点混在一起，就出现了这类系统最常见的毛病：为了加一个租户维度的统计，得改推理引擎的请求处理路径。

Buoyant 自己给出的动机也很实在。他们观察到的现象是，市面上有大量项目在优化单个模型的性能，或者优化一整个 GPU 池，但没有项目在做推理平台这件事。而平台概念在这个行业已经存在了几十年，核心含义是一层仲裁机制，让多个互相竞争的使用者共享一块稀缺的资源，同时保证公平、可用和安全。GPU 就是那块稀缺资源，智能体、编码助手、各种内部应用就是那些使用者。

五个 CRD 撑起全部配置

Kinference 的配置几乎全靠 Kubernetes 自定义资源完成，一共五个。前四个属于 kinference.buoyant.io 这个组，第五个直接复用 Linkerd 的 GatewayBackend。

这几个 CRD 和 Gateway API 的集成方式是刻意设计的。一个 Gateway API 的 HTTPRoute 可以直接指向某个 InferencePool，而这个池子里既有本地目的地也有远端目的地，是否挂 InferencePolicy 决定了请求在这个池子里怎么被处理。不挂策略时也有默认行为：所有匹配所请求模型的本地端点都纳入候选，然后选预期首字延迟最低的那个。

默认策略这条兜底逻辑很重要。它意味着最简配置只需要建一个 InferenceWorkerSet、一个 InferencePool、一条 HTTPRoute，请求就能跑起来，策略是后续的加强项而不是前置条件。

KV cache 感知路由：6.88 秒到 0.31 秒

Kinference 的性能来源是 KV cache 感知。对每个 vLLM worker，它自动跟踪 KV cache 内容、队列长度以及其他运行时状态，然后用这些信号做负载均衡决策。前置条件是 vLLM 侧要通过 ZMQ 发出 KV cache 事件，Kinference 目前用 NVIDIA 的 dynamo-kv-router crate 处理这些事件。

在此基础上，Kinference 会为每个 vLLM 端点、针对具体提示给出一个预期首字延迟的预测值。原理不复杂：哪个 GPU 上已经缓存了这段提示的前缀，就把请求发过去，缓存命中省下的就是整段前缀的重新计算。

这组数字来自 Buoyant 的公开基准，配置是每个池 3 张 L40S，官方自己标注为自测结果。最该记住的是第三行。没有共享前缀的场景，两种做法几乎没有差别，因为缓存感知路由的价值完全来自前缀复用。拿它去做纯冷启动的问答流量，指望不上这 95%。

缓存感知还有一个常被忽略的连带作用。多轮对话或者连续编码场景里，如果中途换到另一张 GPU，前缀缓存就丢了，等于把整段历史重算一遍。缓存感知让策略在挑便宜模型时多了一个约束：只有当切过去反而比留在原地更省工作时才切。放在多租户环境里，这条约束直接决定了租户之间的互相干扰有多大。

五种策略模式，覆盖平台层面最常见的诉求

Kinference 的策略可以按租户、请求的模型、GPU 池状态、提示的语义标签等维度匹配。官方给出的典型模式有五种，基本对应了平台负责人最常问的几个问题。

这五条里最值得琢磨的是第二条。多数人做推理平台时把外部供应商当成兜底，越少用越好；这里反过来了，把外部供应商写进常态策略，用实时队列长度当作切换开关。判断依据不是成本也不是延迟预估，而是队列里已经堆了多少请求，多等一会儿的成本是否已经超过外溢的溢价。

策略是声明式的，可以提交到 git，可以被人或者智能体评审，可以单独应用也可以单独回滚。这一点对多团队环境比看上去更重要：路由规则一旦开始影响别人业务，它就必须能像代码一样被审阅和追溯。

五分钟装起来，以及给智能体准备的那套反馈

安装路径是五步：装 Gateway API 的 CRD（官方给的版本是 1.5.1），装网关，装 Kinference，再装 kinfctl CLI。第五步最容易被跳过，也最不该跳过。

官方对文档的策略很有意思，值得单独说。他们明确表示 Kinference 的配置大多预计由大模型来写，因为 LLM 写 YAML 本来就拿手，但同时承认一个现实：截至 2026 年 11 月，LLM 写技术文档的本事还很差。于是他们的做法是给人写文档，给智能体写护栏和反馈系统。文档手写，LLM 辅助；参考文档写全，保证原始数据可查。

具体落到工具上，kinfctl 这个 CLI 目前只有一个子命令 check。它接受一个或多个 InferencePolicy 清单，做校验和 lint；如果同时给了 InferencePool、InferenceWorkerSet、InferenceProvider 的清单，它还会去核对策略里引用的名字是否真实存在。这一条的价值在于可以在把配置推到集群之前就发现问题。

他们还做了自我测试：开一个全新的编码助手上下文，指向 kinference.ai 的文档，装好 kinfctl，然后让助手去写策略；哪里写错了就回去改文档或者补工具反馈，直到不再出错。每个 CRD 都配了完整的状态信息、kubectl 的打印列，以及各种能给智能体反馈当前状态的手段。

指标与租户账本

Kinference 默认在 9001 端口的 /metrics 路径暴露 Prometheus 格式的指标，覆盖进出 token 速率、输入输出 token 长度直方图、首字延迟 ITL 和端到端延迟直方图、缓存命中与未命中的 prompt token 数、模型使用情况、GPU 饱和度等。几乎每个指标都能按租户维度拆开。

按租户拆分的指标默认是关掉的，官方给的理由很实在：大约每个 模型加 QoS 加租户 的组合会产生 91 条时间序列，5 个模型配 3 种 QoS 就是每个租户约 1365 条。开全体验租户标签会无界增长，所以配置里有 none、all 和白名单三种选项，白名单之外的租户一律归到 default。

用指标做计费的人需要留意 bllmp_cached_tokens_absent_total 这个字段。缓存命中的 token 是白拿的，精细的计费系统可能只想对未命中的 prompt token 收费，而缓存信息并不总是由 worker 上报，absent 计数器就是用来追踪有多少提示没拿到这份数据的。

当前还缺什么

README 里写得很清楚，这是 alpha 软件，没经过持续生产环境的检验，请自行承担风险。当前版本相对完整规划还缺几块：

一是不支持 Anthropic 风格的 /v1/messages 接口，OpenAI 兼容格式的流量可以走。二是还没有速率限制功能，虽然文档里把 token 限速列为平台必备能力。三是语义分类器还没落地，也就是说按提示内容做敏感信息识别的那类策略暂时无法真正生效。四是还不支持多副本部署，这一条对控制面自身的高可用影响最大。五是 Kubernetes 侧的完整安装流程仍偏繁琐，官方自己也在调整。

把这几条列出来不是为了贬低这个项目，而是为了给出使用建议：想立刻用它托管一个对外的生产推理集群还早，但拿它搭一个内部的实验平台，把策略机制、租户维度、KV cache 感知路由这几件事先跑起来，正合适。

常见问题

Kinference 和 vLLM 是什么关系？ Kinference 跑在 vLLM 之上，是控制面而非新的推理引擎。vLLM 负责把模型推理快，Kinference 负责决定请求发给哪个 vLLM 实例、限多少速、记在谁账上。两者可以配合使用，Kinference 本身不要求 Linkerd，但能一起工作。

这个 95% 的延迟降幅可以照搬吗？ 不能直接照搬。它来自共享前缀负载下的自测，配置为每池 3 张 L40S。换成无共享前缀的普通问答流量，官方自己的数据是 6.92 秒对 6.83 秒，几乎没有差别。业务流量里有多长的公共前缀，决定了这个优化对你有多大意义。

策略写错了会不会把集群搞坏？ 用 kinfctl check 可以在推送前做校验和 lint，它还能核对策略里引用的池子、worker set 和 provider 名字是否存在。策略本身是声明式的，提交到 git 后可以评审、单独应用、单独回滚，出问题时回退成本很低。