
Prime Intellect lança plataforma de inferência para modelos open-source
Lançamento e contexto
A Prime Intellect lançou a Prime Inference, plataforma de inferência para modelos open-source de fronteira, disponível em endpoints serverless e capacidade reservada, rodando em infraestrutura própria de GPUs distribuída em múltiplos data centers. A empresa, cuja missão é construir modelos abertos de fronteira e um stack de superinteligência aberta, posiciona o serviço como o fechamento do ciclo de aprendizado contínuo: o modelo treinado serve usuários reais e as traces de produção voltam ao treinamento. A plataforma começou como infraestrutura interna, processando quase um trilhão de tokens por dia em rollouts de RL, geração de dados sintéticos, avaliações e agentes de código, e atende clientes em produção desde janeiro.
O primeiro deployment público foi o GLM-5.3, no OpenRouter, em 22 de setembro. Segundo a empresa, o endpoint figura entre os mais rápidos do OpenRouter para o modelo, com taxa de erro de chamadas de ferramenta praticamente nula e 100% de uptime desde o lançamento.
Recursos e arquitetura
O serviço roda em NVIDIA Blackwell (com Vera Rubin previsto), é compatível com a API da OpenAI, oferece failover automático entre data centers, cobrança unificada e stack open-source que combina NVIDIA Dynamo, vLLM, Mooncake e FlashInfer, em parceria com Inferact e NVIDIA, com melhorias contribuídas de volta ao upstream.
A confiabilidade vem de separar a API pública do fleet de modelos, circuit breakers compartilhados, controle de admissão baseado em leases, monitoramento que alcança NVLink e InfiniBand, equipe de on-call 24/7 e capacidade reserva significativa.
Otimizações de desempenho
Para tráfego agêntico típico (um turno adiciona cerca de 6K tokens a um prompt de 140K), a Prime usa desagregação de prefill/decode em grupos de GPU separados, coordenada pelo Dynamo, o que reduziu a latência inter-token p90 em quase 40% nos testes. Um roteador KV-aware direciona requisições considerando prefixos em cache, e o Mooncake adiciona uma segunda camada de cache na DRAM do host.
Na topologia, a escolha foi DEP8 (oito ranks de atenção data-parallel com expert parallelism), que ofereceu cerca de cinco vezes mais capacidade útil de cache de prefixos que TEP8 no mesmo hardware, ao custo de sincronização entre ranks. Reduzir o orçamento de tokens por etapa de prefill de 8K para 4K por GPU derrubou a espera mediana na fila de 550 ms para 110 ms, reduzindo o tempo até o primeiro token em cerca de 20%.
No decode, a empresa adotou TP4 e compressão KV em NVFP4 (quatro bits por valor com escala FP8), reduzindo cada linha de cache MLA de 576 para 352 bytes e ampliando a capacidade em cerca de 50%, de 1,09 milhão para 1,63 milhão de tokens em cache por decoder. Um kernel nativo sparse-MLA para NVFP4, que dispensa buffers intermediários, levou o tempo do kernel a cerca de 12,0 μs em GB200 a 15 tokens de consulta por lançamento, contra 17,7 μs do caminho escalonado em NVFP4 e 13,7 μs da atenção em FP8 - resultado específico para esse workload, não vantagem em todos os tamanhos de batch. A empresa afirma que bateria de avaliações, com foco em tarefas de contexto longo, indicou que a compressão não degrada a acurácia, e o kernel será contribuído ao FlashInfer como operação experimental.
Na transferência de KV entre prefill e decode via NIXL sobre NVLink, a fragmentação era o gargalo: uma requisição de 200K tokens gerava 32 mil cópias pequenas. Adotar o layout block-major BLHNC, desenvolvido pela comunidade vLLM, reduziu os descritores de transferência de 19.559 para cerca de 1.940 e o tempo médio de transferência de 146 ms para 78 ms (cerca de 47% menos).
Chamadas de ferramenta confiáveis
Servindo GLM-5.3 em escala, a Prime identificou falhas recorrentes: descarte silencioso de chamadas a ferramentas não declaradas e argumentos ausentes ou com tipos incorretos. A empresa contribuiu um construtor de structural-tags ao Dynamo para restringir nomes e argumentos gerados, com o vLLM usando xgrammar para mascarar tokens que violem a gramática durante a decodificação, além de corrigir erros de parsing. Uma suíte própria de testes valida tipos, schemas, streaming, tool-choice e rejeição de requisições malformadas. Com isso, o Dynamo passou a lidar com tool calls com taxa de erro praticamente nula em sessões longas de produção.
No roteiro futuro estão inferência em lote e assíncrona para jobs offline mais baratos e deployments dedicados, incluindo modelos fine-tunados nos treinos da própria Prime.