Buoyant, a empresa que desenvolve o Linkerd, publicou Kinference, um projeto open source destinado a construir plataformas de inferência no Kubernetes. Colocado à frente de um conjunto de servidores vLLM, decide, para cada pedido, para qual servidor este é enviado. O projeto é distribuído sob licença Apache 2.0 no GitHub, na sua versão v0.1.0-alpha.7.
- A Buoyant lançou o Kinference, um plano de controlo open source para inferência em Kubernetes e vLLM.
- O Kinference decide para qual servidor vLLM cada pedido segue, aplicando políticas e balanceamento que tem em conta a cache KV.
- Segundo a Buoyant, com prefixo partilhado, a latência até ao primeiro token desce cerca de 95% e o débito útil sobe cerca de 7,4 vezes.
- Estes resultados são auto-declarados, o projeto ainda está em fase alfa e a limitação de débito não foi entregue.
Uma camada de controlo sobre o vLLM
O Kinference combina Kubernetes, a plataforma de orquestração de contentores, e vLLM, o motor que executa os modelos de linguagem. De acordo com o FAQ da Buoyant, o vLLM constitui o plano de dados, enquanto o Kinference desempenha o papel de plano de controlo. Numa mesma camada, aplica políticas de encaminhamento, limites de débito em tokens, um balanceamento de carga que tem em conta a cache KV, ou seja, a memória que conserva os cálculos já efetuados, bem como métricas por inquilino.
O sistema inclui dois elementos: uma gateway de tráfego e um gestor de inferência. Este último expõe uma interface gRPC, recebe um pedido e devolve o ponto de terminação escolhido, bem como o corpo do pedido eventualmente modificado. Funciona com um proxy, como a Buoyant Gateway. O Kinference monitoriza os eventos da cache KV e as métricas do motor, e baseia-se no crate dynamo-kv-router da NVIDIA para processar esses eventos. A sua configuração assenta em cinco recursos Kubernetes: GatewayBackend, InferencePolicy, InferencePool, InferenceProvider e InferenceWorkerSet.
As políticas de inferência são regras declarativas que especificam como cada pedido é encaminhado ou rejeitado. Podem basear-se no inquilino, no modelo solicitado, no estado dos pools de GPU ou em etiquetas semânticas. O site do projeto apresenta vários exemplos, como o envio de pedidos simples para um modelo mais pequeno, ou o recurso a um fornecedor cloud como o Bedrock quando um servidor tem mais de 2 pedidos em espera. As políticas são armazenadas em git e podem ser validadas offline com a ferramenta de linha de comandos kinfctl.
Resultados medidos pela Buoyant
A Buoyant comparou o Kinference ao simples balanceamento de carga do Kubernetes. Cada configuração usava três pods vLLM 0.31.0, cada um numa GPU L40S, com o modelo Qwen3.8-27B-FP8. Num tráfego que partilha um mesmo prefixo, a latência mediana antes do primeiro token (TTFT) passa, segundo a Buoyant, de 6,88 s para 0,31 s, ou seja, uma redução de cerca de 95%. Sem prefixo partilhado, os números são de 6,92 s contra 6,83 s, sem diferença significativa de acordo com o editor.
Num teste de capacidade, o débito útil, medido em pedidos por minuto que respeitam um objetivo de TTFT, atinge 103,0 contra 14,0 ped/min no tráfego com prefixo partilhado, ou seja, cerca de 7,4 vezes mais. Estes números são auto-declarados. A referência é um encaminhamento aleatório, e não outro router que tenha em conta a cache, como o llm-d ou o Dynamo. A Buoyant esclarece ainda que os seus limiares de 8 s e 4 s são mais adequados para agentes offline do que para chatbots. O quadro comparativo publicado com o artigo apresenta o ângulo distintivo do Kinference como sendo a governação, nomeadamente as políticas, os alias de modelos, os fallbacks para fornecedores e a contabilização por inquilino, enquanto o llm-d e o Dynamo são descritos como mais performantes no serviço bruto.
O projeto permanece em fase alfa. A limitação de débito, os classificadores e o suporte à API da Anthropic ainda não foram entregues.
