SMG: Desagregando CPU de GPU
Tempos atrás, começamos a executar modelos de servidores de produção. Quando iniciamos a construção do Shepherd Model Gateway, o objetivo era modesto: descobrir se o balanceamento de carga com consciência de cache poderia melhorar a rotação entre réplicas de inferência. E funcionou. À medida que avançamos, encontramos um problema muito maior. Em ambos os motores SGLang e vLLM, a tokenização e a des tokenização se tornaram gargalos. Não em teoria, mas na produção, sob tráfego real. A causa raiz era arquitetônica: embora ambos os motores usem bibliotecas de tokenização em Rust ou C++ por baixo, as chamadas passam pelo Python. Isso significa a GIL (Global Interpreter Lock). Isso significa um teto de thread único para trabalhos limitados pela CPU que se encontram diretamente no caminho de servir.
Em pequena escala, isso não importa. Em servidores de pré-preenchimento e decodificação desagregados em grande escala, e em paralelismo de especialistas em grande escala em clusters de GPU, isso importa enormemente. Essas configurações tornam as GPUs extremamente rápidas — rápidas o suficiente para que o lado CPU da pipeline se torne a restrição. Cada microsegundo de tokenização limitada pela GIL é um microsegundo em que GPUs que valem centenas de milhares de reais ficam ociosas, esperando por entrada. É aí que a jornada realmente começou. Não com uma visão de gateway — com um problema de produção. Será que poderíamos desagregar toda a carga de trabalho da CPU do caminho da GPU e executá-la em Rust? Não Python chamando Rust. Puro Rust. Sem GIL. Sem teto de thread único. Sem limites de processo do Python.
A resposta foi sim, e o projeto que provou isso se tornou o Shepherd Model Gateway. A arquitetura do SMG é construída em um princípio: as GPUs devem fazer matemática de tensor. Tudo o mais pertence a uma camada de servir dedicada. Analisamos a pilha de servidores de modelos e identificamos cada carga de trabalho limitada pela CPU entrelaçada com a inferência da GPU: tokenização, des tokenização, parsing de saída de raciocínio, extração de chamadas de função, orquestração de ferramentas MCP, pré-processamento multimodal, gerenciamento de histórico de chat, validação de saída estruturada, detecção de sequência de parada. Cada uma delas é uma tarefa de CPU que, quando co-localizada com o processo da GPU por trás da GIL do Python, cria pressão de retorno no hardware mais caro na prateleira.
O SMG move todos esses para uma camada de gateway em Rust que se comunica com motores de inferência sobre gRPC. O protocolo é minimal e focado em GPU: envie tokens pré-processados para dentro, transmita tokens gerados para fora. Tudo o mais é responsabilidade do gateway. Essa não é a abordagem que a maioria dos projetos no espaço de inferência distribuída tomou. Excelente trabalho está acontecendo com projetos como NVIDIA Dynamo e llm-d, que se concentram em otimizar a camada do motor de inferência e a orquestração ao seu redor. Vemos esse trabalho como complementar. Mas a aposta do SMG é diferente: em vez de tornar o motor mais inteligente, tornar o gateway mais inteligente. Desvincule tudo o que não requer uma GPU em uma camada de Rust personalizada que escala de forma independente, evolui de forma independente e executa com zero contenda da GIL.
O pipeline gRPC: processamento do lado do gateway antes da transferência para o motor. O maior investimento técnico na história do SMG foi reconstruir toda a pipeline de servir ao redor de um plano de dados gRPC nativo em Rust. Isso foi a prova arquitetônica da tese da desagregação. A tokenização e a des tokenização se movem para o gateway. O SMG executa tokenizadores nativamente em Rust com um cache de dois níveis — L0 de correspondência exata para prompts repetidos, L1 de prefixo consciente em fronteiras de tokens especiais. O motor de inferência recebe entrada pré-tokenizada e nunca toca um tokenizador. Sem Python. Sem GIL.
O processamento de raciocínio e parsing de chamadas de ferramentas executa na pipeline de streaming do gateway. À medida que os tokens chegam sobre gRPC, os parsing do SMG — incluindo Cohere Command, DeepSeek, Llama, Nemotron, Kimi-K2, GLM-4 e Qwen Coder — extraem blocos de raciocínio, chamadas de função e saída estruturada em tempo real. Sem etapa de pós-processamento no lado do motor. O processamento multimodal foi a parte mais ambiciosa. Reescrevemos componentes principais do processador de imagem de transformadores da Hugging Face de Python para Rust — reimplantando pipelines de pré-processamento de visão, operações de tensor e transformações específicas de modelo em uma linguagem e tempo de execução completamente diferentes. O resultado: o SMG se comunica com tensores pré-processados diretamente para os motores via gRPC com zero overhead de Python. Suporte para Llama 4 Vision, Qwen VL e todos os principais modelos de visão-linguagem, com otimizações específicas de backend para SGLang, vLLM e TensorRT-LLM. Isso é, ao nosso conhecimento, uma primeira vez na indústria.
A orquestração de ferramentas MCP executa inteiramente no gateway com pooling de conexão com conscientização de autenticação, execução de lote concorrente, fluxos de trabalho de aprovação, reconexão automática e encaminhamento de cabeçalho HTTP. O motor de inferência não tem conhecimento de MCP. Também construímos uma infraestrutura de roteamento de ferramentas completa — transformando qualquer servidor MCP em capacidades nativas (FileSearch, WebSearch, CodeInterpreter) para qualquer modelo. Implantar Llama ou Qwen com as mesmas ferramentas embutidas que o GPT-4. Gerenciamento de histórico
