Buoyant 喺 11 月 4 日發布開源項目 Kinference（讀作 kay-inference），定位係「推理控制平面」——即係喺底層推理引擎 vLLM 之上，加一層管理推理流量嘅控制層，俾成個推理平台有秩序咁運行。

做乜用

Kinference 設計俾同現有棧配搭，用户唔使換嘢，只需將推理客户端指向佢嘅 HTTP endpoint，送 OpenAI 或 Anthropic 兼容嘅推理請求就得。

功能包括 token 限速、租户用量同成本追蹤、智能負載平衡，同埋所謂「推理策略」層。最後一項係最核心：俾平台管理員寫規則，決定邊類請求去邊個模型、邊類 GPU，例如將簡單請求導向較平模型、同時避免因 cold start（冷 GPU）造成大延遲。

點解 KV cache 重要

Kinference 嘅負載平衡唔係平均散點，而係睇每張 GPU 嘅隊列長度、歷史表現，以及最關鍵——GPU 上面嘅 KV cache（Transformer 推理時暫存 attention key-value 向量嘅快取，令重複前綴唔使重新計算）嘅內容。

呢個「cache-aware」設計意味同一個請求會喺已經有相關 context 嗰張 GPU 上面做，避免從頭算。

廠商自家測試數據

Buoyant 公佈咗比較數據，對象係標準 Kubernetes 負載平衡（kube-proxy）：

  • 某一類 workload 下，中位 TTFT（time-to-first-token，首個 token 出現時間）削低 95%；中位端到端延遲削低 45%。
  • 容量測試：shared-prefix workload 下 goodput 係標準方案嘅 7.4 倍；多輪對話 workload 下約 3.5 倍。
  • SLO（service level objective）達成：shared-prefix 喺並發 32（測試最高值）仍達標；多輪對話喺並發 8 達標。kube-proxy 喺任何並發水平都未達標。

呢啲數字出自 Buoyant 自家基準測試，非獨立第三方驗證。測試設定、過程及詳細結果佢哋喺連結入面另有交代。

模姐驗嚇貨

數字靚，但嘅都係廠商自家出嘅。KV cache awareness 呢個方向係有實際工程邏輯，唔係純宣傳；但「7.4 倍 goodput」呢個數目喺真實生產環境會幾大、硬件組合同工作負載點樣影響結果，冇獨立數據之前，讀者要自己判斷。

Kinference 作為開源項目，部署代碼可以查，但「開源」同「完全透明」要分清——仲要睇授權條款、數據保留政策同實際部署條件。想揾部署方案嘅，值得跟住睇後續獨立測試。

模姐｜深度調教