Como Executar uma Rede Neural de 744 Bilhões de Parâmetros em um Computador Comum
Quando você abre a página de um modelo como GLM-5.2 com 744 bilhões de parâmetros ou Kimi K3 com 2,8 trilhões, o primeiro pensamento é bem direto: você precisa de um rack de servidores com uma dúzia de GPUs H100. Se você não tem esses recursos à mão, a única opção restante é pagar por chamadas de API.
Recentemente me deparei com o projeto JustVugg/colibri. O autor escreveu um motor de inferência leve em C puro sem dependências de terceiros. O motor consegue executar modelos MoE massivos em um desktop ou laptop comum com 24 GB de RAM, carregando os pesos diretamente de um SSD rápido.
Qual é o truque
A arquitetura Mixture-of-Experts (MoE) é projetada para que o modelo inteiro não seja necessário para gerar um único token. Por exemplo, no GLM-5.2, dos 744 bilhões de parâmetros, apenas cerca de 40 bilhões estão ativos. Além disso, de token para token, apenas cerca de 11 GB de pesos mudam, correspondendo aos experts selecionados pelo roteador.
Em vez de tentar enfiar 370 GB de modelo na memória de vídeo, o motor distribui dados através de uma hierarquia de armazenamento:
- A parte densa do modelo (embeddings, atenção, camadas compartilhadas) pesa cerca de 9,9 GB em quantização int4 e permanece permanentemente na RAM.
- Quase 20.000 experts residem em um SSD NVMe rápido e são carregados sob demanda via E/S assíncrona.
- Experts frequentemente usados se instalam no cache LRU da RAM ou VRAM.
Essencialmente, isso funciona como um compilador JIT, só que para pesos de redes neurais. O motor rastreia estatísticas de acesso, lembra branches quentes e faz cache exatamente dos experts necessários para o contexto atual.
Como o motor funciona
O codebase é conciso. O núcleo é escrito em C (cada família de modelos é separada em seu próprio arquivo, por exemplo c/colibri.c para GLM) e compila com gcc ou clang com suporte a OpenMP. Sem frameworks gigantescos ou runtimes monstruosos. Python é usado apenas para conversão única de pesos e o wrapper da interface web.
Ao gerar cada token, o motor executa várias etapas:
- Calcula o roteamento uma camada à frente através de uma thread de prefetch separada. O roteador prevê o expert necessário com cerca de 71% de precisão, então leituras de disco acontecem em paralelo com os cálculos.
- Mescla requisições para experts idênticos em um batch para eliminar leituras duplicadas.
- Lê as três matrizes de cada expert em uma única chamada de sistema
pread. - Salva estatísticas de acertos em um arquivo de histórico para que em execuções subsequentes, camadas quentes sejam pré-fixadas na memória.
O suporte para dois dispositivos de armazenamento é implementado de forma interessante. Se você distribuir cópias de pesos entre dois SSDs diferentes, o motor distribui requisições de experts proporcionalmente à velocidade de leitura de cada disco. Um par de drives com velocidades de 9 GB/s e 3 GB/s acelera a leitura em cerca de um terço.
Para aceleração de computação, são suportados CUDA, Metal em chips Apple Silicon e Vulkan. A variante Vulkan funciona até com GPUs mais antigas como a AMD RX 580 via driver RADV, para o qual o fornecedor fechou o suporte para o ROCm mais recente há muito tempo.
O pacote inclui um dashboard web com visualização de atividade de experts. Na página Atlas, você pode girar um mapa 3D de milhares de experts e observar como diferentes grupos lidam com código, tópicos jurídicos ou idiomas estrangeiros.
Números reais de velocidade
Não há milagres, então a velocidade é limitada pela taxa de transferência do disco e memória disponível.
Os benchmarks do projeto registraram os seguintes resultados no modelo GLM-5.2:
- Um laptop com 25 GB de RAM e cache frio produz modestos 0,05-0,1 tokens por segundo. É lento, mas o modelo responde sem distorção lógica.
- Uma workstation com 128 GB de RAM sem GPU dedicada entrega cerca de 1,8 tokens por segundo com cache aquecido.
- Um laptop com uma RTX 5070 Ti mobile acelera para 1,07 tokens por segundo graças ao pipeline de GPU.
- Um servidor com seis placas RTX 5090 mantém experts inteiramente na memória de vídeo e mostra 5,8-6,8 tokens por segundo.
Modelos suportados
Além do GLM-5.2 base, o autor adicionou suporte para mais quatro arquiteturas:
- Inkling (975B) — executar a parte densa em int4 requer cerca de 25 GB de RAM e 469 GB de espaço em disco.
- Kimi K3 (2.8T) — um gigante pesando 1,6 TB, lê pesos nativos MXFP4 diretamente de shards originais sem pré-conversão.
- DeepSeek V4 Flash (284B) — funciona com 167 GB de pesos em formato fp4/fp8 e requer 16 a 22 GB de RAM.
- OLMoE (7B) — uma variante compacta com 4 GB de pesos para experimentos rápidos em 8 GB de RAM.
Como executar
O motor é distribuído como binários pré-compilados para Linux, macOS e Windows, ou pode ser compilado a partir do código fonte em um minuto:
git clone https://github.com/JustVugg/colibri && cd colibri/c
./setup.sh
Após compilar, baixe os pesos quantizados para o modelo desejado do Hugging Face (por exemplo, GLM-5.2 int4 ocupa cerca de 372 GB) e inicie o chat via terminal:
COLI_MODEL=/path/to/glm52_i4 ./coli chat
Se você quiser um servidor local compatível com a API OpenAI junto com o painel web, execute:
./coli web --model /path/to/glm52_i4
Antes de iniciar, vale a pena verificar a distribuição de memória com ./coli plan e executar um teste rápido de hardware com ./coli tune.
Quem achará este projeto útil
O Colibrì provavelmente não serve para produção de alta carga devido à latência de leitura de disco em hardware comum. No entanto, é uma ótima descoberta para pesquisadores, entusiastas e desenvolvedores que precisam testar raciocínio de modelos open-source de ponta localmente sem comprar GPUs de servidor por milhões de rublos. O código central é compacto e transparente, tornando o motor conveniente para usar como playground para seus próprios experimentos com E/S e quantização.
Projetos relacionados