Execute modelos MoE de 35B em uma RTX 4060 com o FreeToken

Execute modelos MoE de 35B em uma RTX 4060 com o FreeToken

Pesquisadores da UC Berkeley e do MIT acabaram de tornar open-source o FreeToken, um motor de inferência que roda modelos frontieros Mixture-of-Experts (MoE) em hardware de consumo. Em um laptop com RTX 4060 de 8GB, ele serve o Qwen3.6-35B a cerca de 39 tokens/segundo; em uma RTX 5090, ele roda o DeepSeek-V4-Flash (284B). A ideia: tratar seu PC como um pool heterogêneo de computação agendável de forma elástica, em vez de um nó de data-center com recursos escassos. Se você quer cortar gastos com APIs na nuvem e hospedar modelos grandes localmente, vale a pena dedicar um fim de semana a isso.

A ideia central: nunca deixar a GPU ociosa

O MoE esparso calcula apenas uma fração dos parâmetros por token, mas a decodificação ainda precisa rotear através de centenas de bilhões de pesos inativos. No data center, o NVLink esconde a sobrecarga de transferência de pesos. Em hardware de consumo, a largura de banda do PCIe (tipicamente 16–64 GB/s) e a latência da memória do host tornam-se o gargalo.

Os runtimes legados para borda (Ollama, offloading de camadas do llama.cpp) dependem do static expert offloading: os pesos inativos ficam na RAM do sistema e são transferidos sincronamente quando ativados — em um cache miss, a execução para completamente. O FreeToken substitui isso por um esquema de co-agendamento dinâmico chamado política q*. Em um cache miss, a GPU continua computando; o trabalho dos tokens é dividido entre os núcleos da CPU e os tensor cores da GPU com base na taxa de transferência ao vivo da interconexão.

Três coisas que fazem funcionar

1. Execução adaptativa à largura de banda (agendamento q*)

Em vez de regras fixas de offload (como no KTransformers), o FreeToken calcula em tempo real uma alocação ótima em forma fechada por camada, dividindo o trabalho dinamicamente entre CPU e GPU.

2. Formato de pesos rápido FTW + double buffering de camadas inteiras

As transferências de pesos pelo PCIe se sobrepõem completamente à execução das camadas de computação ativas, escondendo o custo da transferência.

3. Checkpoints de âncora semântica (feitos para agentes)

Assistentes de código e agentes autônomos modificam prompts constantemente, anexam resultados de ferramentas e geram blocos de raciocínio — então o prefixo muda com frequência. Motores convencionais descartam o cache KV linear e pagam o preço de um reprocessamento completo. O FreeToken armazena estados intermediários de atenção e ativações recorrentes em fronteiras lógicas de tarefas, de modo que, quando um agente edita um argumento de ferramenta ou injeta um resultado externo, as subsequências já computadas são reaproveitadas em vez de invalidar todo o cache do prompt.

Início rápido

# Clone FreeToken (Linux / Windows, NVIDIA RTX séries 30/40/50)
git clone https://github.com/FlashML-org/FreeToken
cd FreeToken

# CLI: aponte para um modelo e pronto — o agendamento é automático
# Exemplo: rodar um modelo MoE de 35B em 8GB de VRAM
freetoken run --model Qwen3.6-35B

# Ou use o cliente desktop da FlashML.ai para ver tudo em ação.
# As alocações de resident-expert e KV-cache podem ser redimensionadas
# em tempo de execução sem recarregar o modelo.

Como ele se compara

  • Ollama / llama.cpp: otimizados para quantização GGUF e offloading por camada, mas não conseguem dividir dinamicamente a carga esparsa de especialistas entre host e dispositivo. No mesmo modelo MoE, o FreeToken decodifica 3–4x mais rápido e faz o pre-fill 6–30x mais rápido.
  • vLLM / SGLang: otimizados para throughput de data-center via PagedAttention e continuous batching; assumem interconexões de alta largura de banda, não uma hierarquia de memória heterogênea.
  • KTransformers: regras estáticas de offload CPU/GPU; o FreeToken calcula a divisão ótima por camada em tempo de execução.

Dicas práticas

A comunidade está combinando placas RTX 3090/4080 usadas com RAM DDR4/DDR5 convencional para hospedar inferência agêntica localmente, reduzindo os custos recorrentes de API a praticamente zero e mantendo o código privado. Ressalva: a solução em forma fechada do q* é sensível à latência real de agendamento da CPU e à contenção de memória, então faça benchmarks com seu próprio modelo e carga de trabalho de agentes antes de substituir uma configuração do llama.cpp já ajustada à mão.

Recursos

Notícias Relacionadas