Inference local em Go sem CGO: o que Yzma e Kronk propõem

A agenda oficial da GopherCon 2026 traz um workshop de dia inteiro chamado "Full-Day Workshop: Ultimate Private AI", conduzido por William Kennedy, da Ardan Labs. O tema interessa a quem constrói software em Go e vem esbarrando na dependência quase automática de APIs de inference em nuvem. A proposta é direta: rodar modelos open-source localmente, seja embutindo a inference na própria aplicação, seja montando um model server sob medida.

O problema que a palestra ataca

Segundo a descrição publicada na agenda, o argumento central é que "model servers são críticos para qualquer solução de IA hoje, mas muitas aplicações não precisam do poder, ou do custo, da inference em nuvem". É uma provocação útil. Boa parte dos projetos que integram LLMs hoje faz uma chamada HTTP para um provedor externo, paga por token e aceita a latência de rede como algo dado. Para casos com requisitos de privacidade, custo previsível ou funcionamento offline, essa arquitetura nem sempre se justifica.

A alternativa apresentada tem dois níveis. O primeiro é o model server privado, ajustado ao problema específico, que segundo a descrição pode funcionar "tão bem quanto, senão melhor" que a nuvem, com custo menor de operar e implantar. O segundo, mais radical, é dispensar o servidor: construir uma aplicação que fala com o modelo diretamente, sem nenhuma camada de servidor no meio.

Yzma e Kronk

Os dois projetos citados como viabilizadores são Yzma e Kronk. Pela descrição da agenda, o Yzma expõe as bibliotecas do llama.cpp diretamente para aplicações Go, e o detalhe técnico que merece atenção é o "no CGO required". Quem já tentou linkar bibliotecas C em projetos Go conhece o atrito: CGO complica cross-compilation, atrapalha builds reproduzíveis e costuma virar dor de cabeça em pipelines de CI. Uma ponte para o llama.cpp sem passar por CGO, se entregar o que promete, elimina uma fonte recorrente de fricção.

O Kronk aparece como o SDK de nível mais alto. A descrição fala em usar o "Kronk SDK para inference local acelerada por hardware com llama.cpp integrado" e em construir aplicações que interagem com modelos open-source vindos do Hugging Face. Ou seja, a divisão de responsabilidades sugerida é: Yzma como camada de acesso ao runtime de inference, Kronk como abstração para trabalhar com modelos e montar a lógica de aplicação por cima.

O que o workshop se propõe a ensinar

A agenda lista três entregas concretas:

• Usar as bibliotecas do llama.cpp direto em Go via Yzma;
• Construir aplicações Go robustas que consomem modelos open-source do Hugging Face via Kronk;
• Montar um model server com uma API de chat completions compatível com OpenAI.

Esse último ponto é o mais pragmático. Uma API compatível com o formato da OpenAI significa que o servidor local pode entrar no lugar do provedor externo com mudança mínima no código cliente: quem já usa SDKs que falam esse protocolo troca o endpoint e segue. É o tipo de compatibilidade que reduz o custo de migração e torna a decisão "local versus nuvem" reversível.

O custo escondido: hardware

O trade-off aparece nos requisitos de hardware, e vale registrar sem romantismo. A recomendação é um Mac da linha M1 com pelo menos 16 GB de RAM (de preferência 32 GB ou mais), ou um laptop Linux/Windows com GPU dedicada de no mínimo 8 GB de VRAM (idealmente 16 GB), ou ainda uma instância em nuvem com GPU dedicada. A observação de que precisa ser VRAM, "não system ram", é o ponto que costuma pegar quem subestima a demanda.

Aqui mora a honestidade do debate: inference local troca custo recorrente de API por custo de capital em hardware e por responsabilidade operacional. Para times brasileiros lidando com câmbio em serviços de nuvem cobrados em dólar, e com dados que não podem sair da máquina, essa troca pode compensar. Mas ela não é gratuita, e a exigência de GPU dedicada com VRAM suficiente é o filtro que define se o modelo cabe ou não.

Por que importa para quem constrói

O recado do workshop é que Go não precisa ficar de fora da camada de inference. A stack de IA aplicada costuma gravitar em torno de Python, e a possibilidade de embutir llama.cpp numa aplicação Go sem CGO, com uma API compatível com OpenAI na saída, abre espaço para arquiteturas mais enxutas em quem já tem seu backend em Go. Vale acompanhar os projetos Yzma e Kronk, medir a latência e o consumo de memória no seu hardware real, e comparar com o custo da nuvem antes de decidir. Como sempre em IA: teste antes de recomendar.

Fonte: Agenda oficial — Meeting Room 431, Level 4, SCC | Summit