Buoyant 推出 Kinference：面向 vLLM 的开源推理控制平面

目录 我们很高兴地宣布 Kinference [读作 kay-inference]，这是一个新的开源项目，用于基于 vLLM 构建可扩展的推理平台。 我们在 Buoyant 创建 Kinference，是因为看到客户在其环境中运行开放权重模型时面临诸多困难。我们将 Kinference 设计为你需要构建的平台的控制平面层。它使用 vLLM 执行底层推理，并提供在实践中构建推理平台所需的一系列功能。这包括 token 速率限制、租户用量与成本跟踪、智能负载均衡以及推理策略。 Kinference 可以与现有技术栈配合使用。使用 Kinference 只需将推理客户端指向其 HTTP 端点，并将兼容 OpenAI 或 Anthropic 的推理流量发送到那里。 Kinference 为运行在异构且不断变化的 GPU 池上的异构且不断变化的模型集合提供服务，面向异构且不断变化的客户端集合。 除了策略和路由层之外，Kinference 还提供推理专用的负载均衡，会考虑 GPU 队列大小、历史性能以及 GPU 上 KV 缓存内容等信号。尤其是这种 KV 缓存感知能力，使 Kinference 能够将请求发送到为该特定请求做工作量最少的 vLLM worker。 对 GPU 的 KV 缓存内容进行建模，可以为分布式推理带来显著的性能提升。例如，在我们的公开 Kinference 基准测试中，我们展示出，与标准 Kubernetes 负载均衡（下图中标记为“service”）相比，Kinference（标记为“kinference”）在一种工作负载类型上能够将首 token 时间（TTFT）的中位数降低 95%，并将请求的端到端延迟中位数降低 45%。 通过将缓存感知纳入策略，平台所有者可以创建策略，将简单请求发送到更便宜的模型——但前提是这样做比一开始就发送到昂贵模型所需的工作量更少。 在上面的无负载延迟基准测试中，我们试图单独衡量 Kinference 的 KV 缓存感知负载均衡的效果。在下面的容量基准测试中，我们衡量了每个端点在延迟 SLO 内每分钟可以服务的请求数。 在容量基准测试中，Kinference 在共享前缀上的有效吞吐量（goodput）达到 7.4 倍，在多轮对话上约为 3.5 倍。在共享前缀工作负载上，它能够在并发 32（所测最高值）时达到我们选定的 SLO；在多轮对话工作负载上，能够在并发 8 时达到 SLO，而 kube-proxy 方法在任何并发级别都无法达到该 SLO。 Kinference 的核心是推理策略这一理念。 推理策略允许平台所有者在使用量、性能和优先级之间进行权衡。我们观察到客户在处理如下问题： 我们没有构建一组一次性功能，而是在 Kinference 中构建了一个策略层，可以表达所有这些需求——以及许多其他需求。 例如，下面展示如何为 Kinference 定义一个 YAML 策略，按复杂度对提示词进行语义分类，并将较简单的提示词路由到更便宜的模型——除非考虑到缓存使用情况后，将其发送到昂贵模型会更快。 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 已饱和时，使用 Kinference 将多余请求突发到云提供商的端点（如 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 对其进行语义分类，并在 GPU 池饱和时将请求突发到第三方提供商。 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 借助推理策略，平台所有者可以基于租户、请求的模型、底层 GPU 池的状态、提示词的语义分类以及许多其他因素，为推理请求应如何路由（或拒绝）创建明确的规则。这些策略可以经过人工或智能体审查；可以提交到 git；可以进行 lint 和审核；并且可以独立应用或回滚。 我们认为这个策略引擎对于提供真正的推理平台至关重要。更多信息请参阅我们的 Kinference 策略文档。 最后，还有一套全面的推理相关指标，供平台所有者进行监控、告警和构建 SLO。Kinference 报告系统上正在发生的事情，不仅包括自身健康状况，还包括： 几乎每个指标也都可按租户查看，因此你可以跟踪租户用量、围绕特定租户的性能构建特定 SLO，以及确保你所构建的平台满足其需求可能需要的其他一切。 注意：本指南将 Kinference 安装到 default 命名空间。要安装到其他命名空间，请覆盖以下 helm 命令中的命名空间。

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