Kinference：面向 vLLM 和 Kubernetes 的开源推理控制平面

Buoyant 发布了 Kinference（发音为 "kay-inference"），这是一个用于在 Kubernetes 上运行 vLLM 推理平台的开源控制平面。Kinference 位于 vLLM 工作节点之前，并添加了普通 Kubernetes 所缺乏的平台级功能：KV 缓存感知的负载均衡、用于路由和成本控制的 YAML 策略引擎，以及按租户的推理指标。在 Buoyant 的公开基准测试中，与标准 Kubernetes 负载均衡相比，KV 缓存感知路由将中位首令牌延迟降低了 95%，中位端到端延迟降低了 45%（针对一种工作负载类型）。

Kinference 在 Apache v2 许可下完全开源，可在 GitHub 上的 Kinference-AI/kinference 获取。它被设计为您自行构建平台的控制平面层，由 vLLM 执行底层推理。

Kinference 是什么及其适用位置

Kinference 是一个控制平面，而非推理引擎。它使用 vLLM 进行实际模型服务，并提供在实际操作开放权重模型所需的周边平台功能：令牌速率限制、租户使用量和成本跟踪、智能负载均衡以及推理策略。

采用 Kinference 无需更改推理客户端，只需将客户端指向 Kinference 的 HTTP 端点即可。Kinference 接受 OpenAI 或 Anthropic 兼容的推理流量，因此现有客户端库和应用程序可以无需修改即可重定向到它。

该项目是在 Buoyant 观察到客户在自身环境中运行开放权重模型遇到困难后创建的。Buoyant 将核心问题描述为：服务于“一组异构、不断演进的模型，运行在一组异构、不断演进的 GPU 上，面向一组异构、不断演进的客户端”。

Kinference 以两个独立发布的组件形式提供：流量网关 和 推理处理器。每个组件都将其 CRD 作为单独的 Helm chart 发布，必须在安装组件本身之前安装这些 CRD。

KV 缓存感知的负载均衡

Kinference 的负载均衡器基于推理特定信号而非通用连接级信号进行路由。它考虑了 GPU 队列大小、历史性能以及每个 GPU 上 KV 缓存的内容。

KV 缓存感知是关键差异化因素：通过对给定 GPU 上已缓存内容的建模，Kinference 可以将请求发送到对该特定请求执行最少额外工作的 vLLM 工作节点。这对于具有共享前缀和多轮对话的工作负载最为重要，因为在这些场景中，提示词的很大一部分可能已经驻留在工作节点的缓存中。

基准测试结果

Buoyant 发布了与标准 Kubernetes 负载均衡（图表中标记为“service”，对比“kinference”）的两项基准测试对比。

无负载延迟基准测试 — 旨在隔离 KV 缓存感知负载均衡的效果：

  • 中位首令牌延迟（TTFT）降低 95%
  • 中位端到端延迟降低 45%

这些数据适用于该基准测试中的一种工作负载类型。

容量基准测试 — 测量每个端点在延迟 SLO 内可以服务的每分钟请求数：

  • 共享前缀工作负载的有效吞吐量提高 7.4 倍
  • 多轮工作负载的有效吞吐量提高约 3.5 倍
  • Kinference 在共享前缀工作负载的并发度 32（最高测量值）和多轮工作负载的并发度 8 时达到了所选 SLO
  • kube-proxy 方法在任何并发级别均未达到 SLO

关于基准测试设置、过程和结果的完整详细信息已发布在 Buoyant 的单独基准测试报告中。

推理策略：策略驱动的路由层

Kinference 的核心抽象是推理策略。Buoyant 没有提供一组一次性功能，而是构建了一个策略层，旨在通过单一机制表达许多路由、成本和优先级需求。

策略允许平台所有者平衡使用量、性能和优先级之间的权衡。Buoyant 引用了两个反复出现的客户问题，这些问题推动了设计：

  • 用户如何请求更广泛的模型类别——例如“任何 Qwen 3.8 模型”或“任何适合编码的模型”——而不是特定的检查点，如“Qwen 3.8，27B 参数，FP8 量化”？
  • 如何将“简单”请求重定向到更便宜的模型，即使原始请求指定了昂贵的模型，同时避免将整个提示历史发送到冷 GPU 并导致较大的延迟损失？

策略声明为 Kubernetes 自定义资源（kind: InferencePolicy，apiVersion: kinference.buoyant.io/v1alpha1），可以根据租户、请求的模型、底层 GPU 池的状态、提示的语义分类以及其他因素来路由或拒绝请求。由于它们是声明式 YAML，策略可以经过人工或代理审查，提交到 git，进行 lint 和审查，并独立应用或回滚。

示例：语义路由到更便宜的模型

以下策略根据复杂度对提示进行语义分类，并将较简单的提示路由到更便宜的模型——除非考虑到缓存使用情况，将请求发送到昂贵模型更快：

apiVersion: kinference.buoyant.io/v1alpha1
kind: InferencePolicy
metadata:
  name: smart-semantic-routing
  namespace: inference
spec:
  rules:
  - name: low-complexity-consider-qwen
    matches:
    - model: glm-5.3
      tag: complexity-low
    route:
      consider:
      - models: { names: [ qwen-3.6-27b, glm-5.3 ] }
      select: [ { minimize: PredictedTTFT } ]

示例：突发到云提供商

当队列深度或缓存压力表明 GPU 已饱和时，此策略将多余请求突发到第三方提供商端点（Buoyant 以 OpenAI、Anthropic 和 Databricks 为例）：

apiVersion: kinference.buoyant.io/v1alpha1
kind: InferencePolicy
metadata:
  name: burst-policy
  namespace: inference
spec:
  rules:
  - name: burst-to-cloud
    route:
      exclude:
      - name: drop-overloaded-workers
        drop:
          backend:       { type: Local }
          queuedPrompts: { greaterThan: 2 }
 
      select:
      - { type: Local,
          minimize: PredictedTTFT }
      - { type: Provider,
          order: [bedrock, databricks] }

示例：将 PII 保留在集群内

此策略根据提示是否包含 PII 对其进行分类，并防止此类请求离开集群，如果没有可用的本地后端，则默认拒绝：

apiVersion: kinference.buoyant.io/v1alpha1
kind: InferencePolicy
metadata:
  name: pii-stays-local
  namespace: inference
spec:
  rules:
  - name: serve
    route:
      exclude:
      - name: pii-never-leaves-cluster
        if:   { tag: pii-detected }
        drop: { backend: { type: Provider } }
      select:
      - { type: Provider,
          order: [ databricks ] }
      - { type: Local,
          minimize: PredictedTTFT }
      onEmpty: Reject   # fail closed

推理指标和 SLO

Kinference 提供了一套推理特定指标，用于监控、告警和 SLO 构建。报告的指标包括：

  • 输入和输出令牌速率，以及输入和输出令牌大小的直方图
  • TTFT、ITL（令牌间延迟）和端到端延迟直方图
  • 未缓存与缓存的提示令牌，用于成本估算
  • 模型使用率和 GPU 饱和度

几乎所有指标也按租户提供，这允许操作员跟踪租户使用情况，构建租户特定的性能 SLO，并验证平台是否满足每个消费者的要求。

安装 Kinference

发布的快速入门将 Kinference 安装到 default 命名空间中；其他命名空间需要在 Helm 命令中覆盖命名空间。以下步骤反映了公告中给出的版本和 chart 位置，Buoyant 指出，随着步骤的演变，官方文档 kinference.ai/docs 应被视为当前的事实来源。

1. 安装 Gateway API CRD

GWAPI_VERSION=1.5.1
kubectl apply --server-side --force-conflicts -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v$GWAPI_VERSION/standard-install.yaml

2. 安装 Kinference 网关

helm upgrade -i gateway-crds \
  oci://ghcr.io/buoyantio/charts/gateway-crds \
  --devel
 
helm upgrade -i gateway \
  oci://ghcr.io/buoyantio/charts/gateway \
  --devel --wait

3. 安装 Kinference

helm upgrade -i kinference-crds \
  oci://cr.kinference.ai/kinference-ai/charts/kinference-crds \
  --devel
 
helm upgrade -i kinference \
  oci://cr.kinference.ai/kinference-ai/charts/kinference \
  --set extension.enabled=true \
  --devel --wait

4. 验证安装

运行 kubectl get pods 并确认两个进程都在运行：

NAME                           READY   STATUS    RESTARTS   AGE
gateway-cp-566cddc46d-jsqlq    1/1     Running   0          8s
kinference-7bb854cfc5-pp4t7    1/1     Running   0          8s

为什么重要

Kinference 解决了开放权重模型从单个 vLLM 部署迁移到共享、多租户平台时出现的差距。Kubernetes 的默认负载均衡是面向连接的，并且对推理状态不敏感，容量基准测试直接证明了这一点：kube-proxy 方法在任何测试的并发级别下都未能满足延迟 SLO，而 Kinference 在共享前缀工作负载的最高测量并发度下满足了 SLO。

通过将路由决策变为声明式 YAML 而非硬编码功能，Kinference 还使推理平台行为可以通过标准 Git 和 Kubernetes 工作流进行审查和回滚——包括安全相关规则，例如将 PII 保留在集群内并默认拒绝。

Buoyant 明确邀请通过项目的 GitHub 仓库提供反馈、问题和来自其他部署的基准测试报告。

Sources