路由比模型更重要?Buoyant 开源 Kinference
【摘要】 Buoyant(Linkerd 背后的公司)本周开源 Kinference,一个位于 vLLM worker 前面的推理控制平面。一、定位Apache 2.0,Rust 编写,v0.1.0-alpha.7,通过 5 个 CRD 配置(GatewayBackend、InferencePolicy、InferencePool、InferenceProvider、InferenceWorkerSe...
Buoyant(Linkerd 背后的公司)本周开源 Kinference,一个位于 vLLM worker 前面的推理控制平面。
一、定位
Apache 2.0,Rust 编写,v0.1.0-alpha.7,通过 5 个 CRD 配置(GatewayBackend、InferencePolicy、InferencePool、InferenceProvider、InferenceWorkerSet)。vLLM 是数据面,Kinference 是控制面。
二、核心机制
监听 vLLM KV 缓存事件和引擎指标,按缓存前缀重叠度和队列长度为每个端点预测 TTFT,并选最小者;而 Kubernetes Service 只会随机选 Pod。
三、声明式策略
小任务走小模型、突发溢出到云端、PII 留在本地、闲时跑批、模型别名。策略可存 git,用 kinfctl 离线校验。
四、数据
3×L40S、Qwen3.8-27B-FP8:共享前缀中位 TTFT 6.88s→0.31s(约 -95%),多轮 1.70s→0.59s,无共享前缀基本无差异(6.92s vs 6.83s)。有效吞吐共享前缀约 7.4 倍。
注意:均为厂商自测,基线是随机路由而非 llm-d/Dynamo。
对开发者意味着什么
- 前缀重复越多收益越大
- 性能上 llm-d、Dynamo 更领先,Kinference 强在治理
- 仍是 alpha,限流等未上线
- 建议用真实流量自行复测
结语
95% 证明缓存感知路由优于随机路由,而非优于同类方案,等独立基准再下结论。
【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱:
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论(0)