Resumo Técnico: STREAM – Middleware de Inferência de LLM Multi-Nível com Streaming de Tokens de HPC de Canal Duplo

Declaração do Problema

Pesquisadores e profissionais enfrentam um cenário fragmentado ao implantar Grandes Modelos de Linguagem (LLMs), sendo forçados a escolher entre três opções imperfeitas:

1. Inferência Local: Gratuita e privada, mas limitada pelas restrições de hardware do usuário (modelos menores, janelas de contexto limitadas).
2. HPC Institucional: Oferece recursos poderosos de GPU sem custo marginal e mantém os dados dentro dos limites institucionais, mas opera atrás de firewalls que bloqueiam abordagens de streaming padrão e depende de modelos de execução em lote (batch) que carecem de mecanismos para entrega incremental de saída.
3. APIs de Nuvem Comercial: Fornecem qualidade de modelos de fronteira sob demanda, mas impõem custos significativos por token e políticas de retenção de dados inadequadas para pesquisas sensíveis.

Nenhum sistema existente unifica esses três níveis, levando a gastos desnecessários com nuvem, subutilização de recursos de GPU institucionais e fluxos de trabalho fragmentados. Além disso, as arquiteturas de streaming padrão falham em ambientes HPC porque os nós de computação estão situados atrás de firewalls institucionais que bloqueiam todas as conexões de entrada, e as máquinas clientes frequentemente estão atrás de NAT, tornando-as inalcançáveis sem VPNs ou alterações nas regras de firewall.

Metodologia e Arquitetura do Sistema

O STREAM (Smart Tiered Routing Engine for AI Models) atua como uma camada de middleware que unifica a inferência local, HPC e em nuvem em um único serviço em camadas. O sistema processa cada consulta através de um pipeline padronizado:

1. Arquitetura de Roteamento de Três Níveis

As consultas são classificadas por um Juiz de Complexidade (um LLM local, especificamente o Llama 3.2 3B) em três níveis:

• BAIXO (LOW): Encaminhado para modelos locais (ex: Llama 3.2 3B, Gemma 3 4B-VL) executados em dispositivos do usuário ou servidores co-localizados via Ollama.
• MÉDIO (MEDIUM): Encaminhado para recursos de HPC institucional (ex: Qwen 2.5-VL-72B-AWQ em GPUs H100 NVL).
• ALTO (HIGH): Encaminhado para APIs de nuvem comercial (ex: via OpenRouter).
  O sistema inclui um mecanismo de fallback onde as consultas escalam ou descem de nível com base na disponibilidade e estados de erro, garantindo a continuidade.

2. Streaming de Tokens de HPC de Canal Duplo

Para resolver o problema de streaming em HPC, o STREAM introduz uma arquitetura inovadora que separa o Plano de Controle do Plano de Dados:

• Plano de Controle (Globus Compute): Lida com a autenticação federada e o despacho de tarefas. Ele submete uma tarefa contendo a consulta e metadmetadados, mas não carrega payloads de tokens.
• Plano de Dados (Relay de WebSocket): Um servidor de relay baseado em nuvem atua como um ponto de encontro (rendezvous).
  • Produtor: O worker de HPC (executando dentro de uma tarefa Globus Compute) conecta-se outbound ao relay, lê o fluxo SSE HTTP do vLLM token por token e os encaminha.
  • Consumidor: O cliente (ou proxy) conecta-se outbound ao mesmo canal de UUID único no relay para receber os tokens.
• Travessia de Firewall: Como ambos os endpoints iniciam conexões de saída (wss:// na porta 443), a arquitetura atravessa firewalls institucionais e NAT sem exigir portas de entrada, VPNs ou alterações nas regras de firewall.
• Segurança: O sistema emprega criptografia AES-256-GCM de ponta a ponta. As chaves de criptografia e os segredos do canal são pré-carregados no ambiente do worker e nunca são transmitidos como argumentos da tarefa, garantindo que o operador do relay não possa ler os payloads de tokens.

3. Sumarização de Contexto Consciente de Nível

Para evitar que históricos de conversas longos forcem consultas simples para níveis caros devido aos limites de janela de contexto, o STREAM implementa compressão diferencial. Quando uma conversa se aproxima de 80% do limite de contexto de um nível, as mensagens antigas são comprimidas em um resumo (usando o modelo local gratuito) enquanto as turnos recentes são mantidos na íntegra. Isso permite que consultas simples permaneçam no nível local mesmo após 40+ turnos.

4. Modo Proxy HPC-como-API

O STREAM expõe o nível HPC como um endpoint compatível com OpenAI (/v1/chat/completions). Isso permite que aplicações externas acessem a inferência de HPC institucional sem exigir que os usuários gerenciem credenciais Globus ou implementem o protocolo de relay diretamente. Este modo é prático apenas porque o streaming de canal duplo reduz a latência para níveis sub-segundo.

Principais Resultados

O sistema foi avaliado em um benchmark de 1.200 consultas abrangendo dez domínios (HPC, matemática, física, etc.) e medido através dos níveis local, HPC e nuvem.

• Precisão de Roteamento: O juiz de complexidade Llama 3.2 3B alcançou 49,0% de precisão geral (1,5× acima do acaso) e 85,1% de retenção no nível gratuito, mantendo com sucesso 85% das consultas nos níveis gratuitos local ou HPC. A principal limitação foi a baixa revocação para consultas de complexidade "BAIXA", que foram frequentemente roteadas para o nível "MÉDIO" (um erro conservador, pois ambos são gratuitos).
• Latência (TTFT):
  • Local: 0,26 s de mediana de Tempo para o Primeiro Token (TTFT).
  • HPC (Streaming): 0,54 s de mediana de TTFT. Isso representa uma melhoria de 21,1× sobre o modo de fallback em lote (11,40 s), onde o TTFT é igual ao tempo total de geração.
  • Nuvem: 1,68 s de mediana de TTFT.
• Throughput: Tanto o modo de streaming de HPC quanto o modo em lote alcançaram throughput de geração idênticos (26,9 tok/s), confirmando que o relay não adiciona overhead por token.
• Sumarização de Contexto: Em testes sintéticos, a sumarização impediu a atualização forçada de nível para consultas simples ("Quanto é 2+2?") mesmo quando o contexto bruto excedeu 41K tokens (turno 40), mantendo a consulta no nível local.

Significância e Alegações

O artigo afirma que o STREAM é o primeiro sistema a unificar a inferência de LLM local, institucional (HPC) e em nuvem com roteamento automático baseado em complexidade. Sua principal significância reside na resolução do problema de streaming em HPC, permitindo a entrega de tokens em tempo real de trás de firewalls institucionais sem a necessidade de VPNs ou modificações de firewall.

Ao reduzir o TTFT de HPC de 11,40s para 0,54s, o STREAM torna o padrão de implantação "HPC-como-API" prático para aplicações interativas, um caso de uso anteriormente impossível devido à latência de processamento em lote. O sistema demonstra que os recursos de GPU institucionais podem ser tornados tão acessíveis quanto as APIs de nuvem, mantendo a privacidade dos dados e reduzindo custos. Os autores observam que o STREAM é atualmente um protótipo de pesquisa; o trabalho futuro envolve substituir o juiz baseado em LLM por um classificador de texto ajustado (fine-tuned) e coletar rastros de roteamento de usuários reais. Os componentes principais (relay e proxy) são liberados como bibliotecas PyPI independentes de domínio (streamrelay e hpc-as-api).