A Buoyant, criadora do Linkerd, lançou o Kinference, uma plataforma open source que funciona como plano de controle para inferência em ambientes com Kubernetes e vLLM. A solução foi desenvolvida para cenários com múltiplos inquilinos e modelos, oferecendo roteamento inteligente, governança, limites baseados em tokens e métricas segmentadas por usuário ou equipe.
Na arquitetura proposta, o vLLM atua como data plane, responsável pela execução, enquanto o Kinference funciona como control plane. A plataforma se posiciona diante de um conjunto de workers vLLM e decide, requisição a requisição, para qual endpoint cada chamada de inferência deve ser encaminhada.
O projeto está na versão v0.1.0-alpha.7, tem código disponível no GitHub e utiliza a licença Apache 2.0. O público-alvo são equipes que já empregam Kubernetes e vLLM para servir modelos de machine learning em larga escala e precisam administrar simultaneamente vários modelos e clientes internos, mantendo isolamento, governança e desempenho.
Em vez de depender do balanceamento aleatório padrão do Kubernetes, o Kinference utiliza políticas declarativas para roteamento e rejeição de requisições. As decisões consideram o locatário, o modelo solicitado, o estado do pool de GPUs e tags semânticas. O sistema também busca reduzir o tempo até o primeiro token (TTFT), estimando a resposta com base na sobreposição de cache e no tamanho da fila.
A plataforma é formada por duas partes principais: um gateway de tráfego e um handler de inferência com interface gRPC. O handler recebe cada requisição, aplica as regras de política e retorna o endpoint escolhido. Ele também pode ajustar o corpo da chamada antes do encaminhamento por meio de um proxy compatível, como o Buoyant Gateway.
Para tomar as decisões de roteamento, o Kinference monitora eventos do cache KV do vLLM e métricas do motor de inferência. O processamento desses eventos utiliza a biblioteca dynamo-kv-router, da NVIDIA. A configuração é realizada por meio de cinco Custom Resource Definitions (CRDs) no Kubernetes: GatewayBackend, InferencePolicy, InferencePool, InferenceProvider e InferenceWorkerSet.
As InferencePolicy concentram as regras de governança. Nelas, as equipes podem definir quais modelos cada grupo está autorizado a utilizar, quais pools de GPU podem ser acessados, quais aliases correspondem a determinadas versões de modelos e quais condições provocam a rejeição antecipada de uma requisição. As políticas podem ser mantidas em repositórios Git e validadas offline com a CLI kinfctl, permitindo revisão de código e auditoria.
Para demonstrar o impacto da camada de controle, a Buoyant publicou benchmarks comparando o Kinference ao balanceamento padrão de um Service ClusterIP no Kubernetes, cenário em que o kube-proxy seleciona aleatoriamente um pod por conexão.
Nos testes, os dois cenários utilizaram a mesma configuração: três pods executando o vLLM 0.31.0, cada um equipado com uma GPU L40S e responsável por servir o modelo Qwen3.8-27B-FP8. A carga foi gerada com o GuideLLM 0.8.1, em dois padrões de uso: shared-prefix e multiturn.
Segundo os resultados divulgados pela empresa, a latência mediana de ponta a ponta caiu até 45% no padrão shared-prefix e 32% no multiturn quando o Kinference foi utilizado para o roteamento, mesmo com o cluster sob pressão. O percentil 95 do TTFT passou de 21,46 segundos para 12,33 segundos, resultado atribuído ao balanceamento baseado no estado das filas e do cache.
Na métrica de capacidade, medida pelo número de requisições por minuto que atendem a um SLO de TTFT, o Kinference alcançou picos de 103,0 requisições por minuto, contra 14,0 no cenário de referência em shared-prefix, representando um ganho de até 7,4 vezes. No padrão multiturn, foram 82,7 requisições por minuto, ante 23,8 no baseline, aproximadamente 3,5 vezes mais. No cenário de referência, o Service padrão não cumpriu o SLO em nenhuma das taxas de concorrência testadas.
A Buoyant ressalta que os SLOs utilizados são voltados a agentes offline, e não a chats em tempo real. A empresa também informa que a comparação foi feita com roteamento aleatório, sem incluir outros roteadores sensíveis ao cache, como llm-d ou Dynamo.
Além de priorizar o desempenho, o Kinference busca atuar como uma camada de governança para inferência. Entre os recursos estão políticas e aliases de modelos, fallback entre provedores, limites de taxa baseados em tokens e contabilização detalhada por locatário.
Esse modelo atende principalmente organizações que executam vários modelos de código aberto para diferentes equipes internas, como áreas de produto, pesquisa e analytics em empresas de tecnologia, fintechs e organizações de saúde. Com métricas separadas por locatário, as empresas podem atribuir custos de GPU e uso de modelos a cada área, apoiar decisões de planejamento de capacidade e estabelecer prioridades em períodos de alta demanda.
Profissionais de ciência de dados, como Michal Sutter, podem ser beneficiados indiretamente. A equipe de plataforma passa a contar com ferramentas mais precisas para controlar filas e cache, enquanto os times consumidores podem obter acordos de nível de serviço mais claros e reduzir a instabilidade provocada por outros usuários em clusters compartilhados.
A instalação do Kinference é realizada em cinco etapas. Primeiro, a equipe aplica ao cluster Kubernetes os CRDs da Gateway API v1.5.1. Em seguida, instala o Helm chart do Buoyant Gateway e, depois, o chart do próprio Kinference.
O pacote já disponibiliza métricas para Prometheus e painéis prontos para Grafana, com indicadores como TTFT, ITL (intervalo até o último token), latência de ponta a ponta e proporção de tokens de prompt armazenados ou não armazenados em cache, geralmente segmentados por locatário. Essas informações permitem que equipes de DevOps e SRE identifiquem gargalos de GPU, padrões de cache e violações de SLO.
Por ser open source e licenciado sob Apache 2.0, o projeto está aberto a contribuições da comunidade em áreas como novos provedores, políticas, integrações e otimizações. A expectativa é que, à medida que avance além da fase alfa, o Kinference receba suporte a mais modelos, interfaces mais acessíveis e melhorias no motor de decisão.
No médio prazo, caso os ganhos de governança e desempenho relatados sejam confirmados em ambientes reais, o Kinference poderá se consolidar como uma alternativa para o controle de inferência em clusters Kubernetes que utilizam o vLLM como camada de execução.
Fonte: Miraí Broadcast