TurboFieldfare - engine open source que roda o Gemma 4 26B com 2 GB de RAM em qualquer Mac da série M

 (github.com/drumih)
1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • TurboFieldfare executa o Gemma 4 26B-A4B com cerca de 2 GB de memória sem carregar o modelo completo de 14,3 GB na memória, permitindo inferência local até em Macs Apple Silicon com 8 GB
  • Depois de manter residentes apenas o núcleo compartilhado de 1,35 GB e o cache KV em FP16, ele faz streaming dos pesos dos especialistas MoE necessários para cada token a partir do SSD, limitando a E/S com cache LFU de 16 slots e pread em paralelo
  • O Gemma 4 26B-A4B ativa cerca de 3,88B parâmetros por token, e a velocidade de decodificação medida é de 5,1~6,3 tok/s em um MacBook Air M2 com 8 GB e de 31~35 tok/s em um M5 Pro com 24 GB
  • É um runtime dedicado implementado com Swift 6.2 e Metal 4, oferecendo app nativo para Mac, CLI, ferramenta de instalação e servidor compatível com OpenAI experimental sobre o mesmo diretório de modelo .gturbo
  • No momento, o escopo se limita à inferência somente de texto em Macs Apple Silicon com macOS 26 ou superior e no mínimo 8 GB de RAM; imagem, áudio, vídeo e autenticação remota de servidor ou TLS não são suportados

Estrutura de execução para reduzir memória

  • O TurboFieldfare não carrega o Gemma 4 26B-A4B instruction-tuned inteiro na memória
    • Mantém na memória o núcleo compartilhado de 1,35 GB e o cache KV em FP16
    • Lê do SSD apenas os especialistas roteados necessários para cada token em buffers visíveis ao Metal
    • Embora o modelo instalado somente de texto tenha cerca de 14,3 GB, a memória usada pelos pesos e pelo cache KV de 4K fica em cerca de 2 GB
  • O modelo ativa cerca de 3,88B parâmetros por token entre os 26B parâmetros totais
  • Os pesos usam MLX affine 4-bit com group 64; o router é de 8 bits, e os especialistas compartilhados e roteados são de 4 bits
  • Não é uma configuração que envolve MLX ou llama.cpp, mas sim um runtime dedicado em Swift e Metal feito para o Gemma 4 26B-A4B

Processo de geração de tokens

  • Em cada camada Transformer, o Metal calcula attention e router com pesos residentes
  • A CPU compara os 8 IDs de especialistas principais selecionados pelo router com o cache LFU de 16 slots por camada
    • Cache misses são preenchidos com um número limitado de chamadas pread em paralelo
    • Enquanto a leitura do SSD acontece, o Metal calcula o ramo de shared-expert que já está residente
    • Quando a leitura termina, combina a saída compartilhada com a saída roteada
  • O prefill do prompt usa chunks de até 128 tokens para permitir que um especialista já carregado processe várias linhas
  • Na etapa de geração, o loop de camadas roteadas é repetido token por token
  • O cache KV usa armazenamento circular limitado para 25 camadas sliding-window e armazenamento linear para 5 camadas full-attention
  • A attention de decodificação usa o método exact split-K/V, separando os caminhos normalizados de K e V

Instalação e formato do modelo

  • Na primeira execução, ao selecionar Download, são baixados cerca de 15 GB por range requests a partir de uma revisão fixa no Hugging Face
  • O instalador não cria o checkpoint original completo em arquivo temporário nem na memória
    • Recebe os intervalos de bytes necessários e os reempacota diretamente no layout .gturbo
    • Como não prepara shards ou tensores completos separadamente, o uso temporário de memória fica limitado
    • A instalação final só pode ser usada se passar na validação de manifest e hash dos arquivos
  • Após a instalação, o modelo ocupa cerca de 14,3 GB de armazenamento, e o processo de instalação em si não carrega o modelo na memória
  • O runtime aceita apenas diretórios .gturbo completos com o manifest.json final
  • Há suporte para retomar downloads interrompidos, apagar estado de download parcial e validar a instalação sem carregar o modelo

Ambiente de execução e desempenho

  • Os requisitos são Mac Apple Silicon, macOS 26, Metal 4, Xcode 26 e Swift 6.2 ou superior
  • O pacote é somente arm64 e não oferece suporte a versões anteriores de macOS e Metal
  • O alvo de validação é o MacBook Air M2 com 8 GB, sendo necessário espaço livre em disco para instalar o modelo e conexão com a internet para o primeiro download
  • O desempenho de decodificação medido é o seguinte
    • MacBook Air M2 com 8 GB: 5,1~6,3 tok/s
    • M5 Pro com 24 GB: 31~35 tok/s
  • O throughput varia conforme o tamanho do prompt, o comprimento da geração, o estado do page cache e o hardware, então esses números são referência, não limite máximo de desempenho
  • Antes de executar o modelo, é preciso fechar apps que consumam muita memória e verificar a memória livre com memory_pressure -Q
  • App, serviço de decode, CLI, servidor, testes ou outro processo local de modelo devem ser executados um de cada vez

Produtos oferecidos e forma de uso

  • O pacote Swift oferece seis produtos
    • TurboFieldfare: biblioteca Swift com o runtime e os kernels Metal
    • TurboFieldfareMac: app nativo para Mac para instalação e geração
    • TurboFieldfareDecodeService: processo local efêmero dono do modelo e do Metal usado pelo app para Mac
    • TurboFieldfareCLI: chat instruction por linha de comando e raw completion
    • TurboFieldfareServer: servidor loopback compatível com OpenAI para Chat Completions
    • TurboFieldfareRepack: ferramenta de instalação por streaming e validação da instalação
  • No app para Mac, depois de baixar o modelo, selecione Load Model e insira o prompt para gerar
    • Na barra de status, é possível acompanhar o progresso, a velocidade de decodificação e o uso de memória
    • É possível ajustar sampling, context length, slots de cache de especialistas e opções do runtime
  • O chat instruction da CLI recebe um array JSON de mensagens e o converte para o mesmo formato do app para Mac
    • O valor padrão de --max-new, limite de resposta, é 1.024 tokens
    • O app para Mac pode gerar até a janela de contexto selecionada ficar cheia
  • --prompt é usado para raw completion sem aplicar o formato de chat e para comparações reproduzíveis
  • O texto gerado vai para a saída padrão, e as estatísticas de tempo vão para o erro padrão; a saída de estatísticas pode ser desativada com --quiet

Prompt e escopo de suporte

  • O app para Mac trata a entrada como instruction e aplica automaticamente o formato de chat do Gemma
  • As configurações padrão de sampling são temperature 0.2, Top-K 64 e Top-P 0.95
    • Se a temperature for definida como 0, usa saída greedy determinística
    • O modelo pode repetir ou responder incorretamente, então resultados importantes devem ser verificados
  • O app e a CLI suportam mensagens de usuário, modelo e orientação opcional de sistema, mas não expõem nem executam ferramentas
  • No momento, a entrada e saída do modelo são somente texto; imagem, áudio e vídeo não são suportados
  • A CLI oferece --max-context, --temperature, --top-k, --top-p, --repetition-penalty, --seed e strings --stop repetíveis

Servidor local compatível com OpenAI

  • O servidor experimental roda em 127.0.0.1:8080/v1 e suporta Chat Completions, streaming, declaração de ferramentas de função e reutilização de um único prompt de prefixo
  • O servidor retorna tool calls geradas pelo modelo, mas a aprovação e execução de todas as chamadas de ferramenta ficam a cargo do cliente
  • Como não há autenticação remota nem TLS, o servidor deve ser mantido apenas em loopback
  • O app para Mac, a CLI e o servidor usam o mesmo diretório .gturbo, mas apenas um produto que detenha o modelo pode rodar ao mesmo tempo

Escopo de implementação e registro experimental

  • Os kernels Metal customizados tratam de GEMV quantizado, attention, MoE, normalization, RoPE, sampling e fusões de produção
  • O runtime implementa streaming via SSD para especialistas roteados, cache limitado de especialistas, prefill de prompt único em chunks e geração token a token
  • 103 resultados medidos são mantidos como registro experimental abrangendo kernels, cache, E/S, prefill e decode
  • A documentação experimental inclui otimizações de grande efeito, ideias que falharam e resultados iniciais revertidos após validação mais forte
  • O trabalho futuro inclui desenvolvimento de apps para iPhone e iPad, medição de velocidade e memória de inferência móvel, e benchmarks em um Mac mini M4 com 16 GB e outros Macs Apple Silicon com 8 GB

Licença e condições do modelo

  • O código-fonte e a documentação são distribuídos sob a Apache License 2.0
  • Os pesos do modelo não estão incluídos no repositório; o instalador os baixa separadamente a partir de um checkpoint fixo no Hugging Face
  • As condições originais de distribuição continuam valendo para os pesos
  • O TurboFieldfare é um projeto de pesquisa independente, sem afiliação, patrocínio ou aprovação do Google

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Opiniões do Hacker News

  • Sempre me perguntei por que, toda vez, é necessário enfiar o modelo inteiro na memória, até incluindo quem é o rei Charles. A tecnologia para dividir arquivos grandes em partes menores e lê-los com eficiência usando pouca memória já me parece bem estabelecida.
    Na indústria de IA de ponta, parece haver uma tendência de serem ótimos em criar modelos, mas deixarem escalabilidade e praticidade para o pessoal de infraestrutura. Se o conhecimento realmente usado for menos de 10%, talvez só com ajuste fino e otimização já dê para reduzir bastante os custos.

    • Manter o modelo inteiro na memória é muito mais rápido do que ficar trocando com o disco.
    • Na prática, você acabou de descrever uma arquitetura de mistura de especialistas (MoE). Se as camadas de especialistas forem pequenas o suficiente e o SSD for rápido, dá para carregá-las só quando necessário.
      LLMs densos em geral têm desempenho melhor, mas, se você mandar camadas para armazenamento externo, eles ficam muito mais lentos que MoE.

  • Hoje em dia, ao baixar projetos de origem desconhecida, é preciso rodar por conta própria uma revisão de segurança como essa. Pedi para ignorar as instruções de agentes e arquivos Markdown do repositório e inspecionar o código Swift/Metal, scripts de build, configurações de CI e dependências; o resultado não encontrou código malicioso, backdoors, roubo de credenciais nem endpoints de rede ocultos, mas riscos de compilação, cadeia de suprimentos e runtime ainda permanecem.
    Se alguém tiver um prompt melhor, pode compartilhar; o custo para rodar isso no Composer 2.5 do Cursor foi de menos de US$ 0,20.

  • Se você usa macOS 15 em um M1 MacBook Air, ele compila se remover estas duas linhas ou envolvê-las em if #available(macOS 26.0, *): opts.languageVersion = .version4_0
    Segundo os comentários, você perde o efeito de tornar a atenção 11,24 vezes mais rápida e acelerar o prefill em 2,4 vezes, mas em um M1 Air com GPU de 8 núcleos ainda sai 5 a 6 tokens por segundo.

    • Informação útil. Talvez eu reduza a versão mínima suportada mais tarde.
      A melhoria de 2,4 vezes no prefill funciona apenas na família de GPUs apple10; se não me falha a memória, o M1 é apple7.

  • Fico curioso para saber como este projeto se compara ao mmap comum. O llama.cpp também consegue rodar um modelo 26B com 2 GB de RAM, se você ativar mmap e desativar o repacking, caso queira.
    A principal diferença parece ser que ele sincroniza as leituras do SSD com o trabalho de inferência para minimizar a latência, algo que o sistema operacional não considera nesse contexto de execução.

    • A primeira versão usava mmap. Em um M2 de 8 GB, ler um especialista de 3,36 MB a frio levava 10 ms com mmap, enquanto pread levava 2,8 ms, e a simulação completa dava, respectivamente, 0,50 token/s e 4 tokens/s.
      Com mmap, como o sistema operacional lê de forma reativa quando o modelo toca nas páginas, ele não sabe qual especialista foi escolhido nem quando pode sobrepor a leitura ao trabalho da GPU. Os pesos comuns ainda usam mmap por simplicidade, e o llama.cpp também deve conseguir rodar abaixo de 2 GB, mas imagino que seja mais lento.
    • Para confirmar a velocidade real, eu gostaria de comparar diretamente com o offloading para SSD do llama.cpp.

  • A frase “os resultados medidos são um ponto de referência, não um teto de desempenho” parece uma formulação típica do Claude.

    • Esse tipo de expressão se espalhou tanto que fico até preocupado de eu acabar adquirindo o mesmo vício depois de ler tanto texto no estilo do Claude.
    • “Experimentei mais de 100 vezes e a maioria falhou, mas algumas me trouxeram até aqui” também parece carregar o mesmo traço.
    • Originalmente, talvez fosse mais provável ser uma formulação ao estilo do ChatGPT, mas nem por isso vou acusar alguém de ter destilado uma empresa ocidental. Blogs de receitas pós-2022 também podem ter entrado nos dados de treinamento por volta das versões 4.6–4.8.
    • Acho que já passou da hora de parar com esse tipo de detecção. Não é muito diferente de uma nova forma de polícia gramatical e não acrescenta grande valor.
      Se o autor só usou um LLM para polir as frases e não adicionou conteúdo inútil, tudo bem. Se o texto em si for uma geração sem utilidade, basta dar uma pontuação baixa.

  • É impressionante ver 12 tokens por segundo e respostas quase imediatas em um Mac Studio M1 Max com SSD mais rápido. Isso mostra a possibilidade de executar modelos grandes diretamente do SSD, não da memória.

    • Infelizmente, aqui a velocidade de leitura do SSD é o maior gargalo.

  • Hoje há muitos motores de streaming a partir de SSD, mas poucos tentam recursos difíceis. Como o modelo principal tem cabeças MTP para decodificação especulativa, isso poderia ser aproveitado para pré-ler os pesos dos especialistas no SSD.
    Se os pesos estiverem prontos antes de a GPU precisar deles, o custo de cache miss da VRAM pode cair bastante; se a eficácia for comprovada, modelos futuros poderiam ter cabeças dedicadas para pré-carregar especialistas e já levar isso em conta desde a etapa de treinamento.

    • Em streaming de SSD, quase sempre a GPU fica esperando o SSD buscar o especialista correto, então, do lado do SSD, praticamente não há folga para leitura antecipada. Ler um especialista previsto incorretamente é até prejudicial, e por isso o MTP existente também não ajuda muito em ambientes comuns sem lotes grandes.
    • Na prática, é mais difícil do que parece. Cada camada tem um conjunto diferente de especialistas, e um roteador pequeno decide quais especialistas usar olhando o estado de saída dos especialistas da camada abaixo.
      Com os tokens de rascunho gerados pelo MTP, dá para prever até os especialistas da primeira camada, mas, para saber a 10ª camada, é preciso executar as camadas 1 a 9 e ler primeiro esses especialistas. Portanto, em vez de um gerador do próximo token, é necessário um dispositivo treinado para prever de uma vez a ativação dos especialistas de todas as camadas.

  • Um projeto para executar o DiffusionGemma também está quase pronto, e combinar os dois projetos pode funcionar bem. Em um M3 de 36 GB, dá cerca de 20 tokens por segundo, e há grande chance de um aproveitar kernels mais rápidos do outro.
    O código atual está em https://github.com/mmastrac/diffgemma, mas ainda não está em estado publicável.

    • Dei uma olhada recentemente, mas concluí que há pouco benefício em executar modelos de difusão localmente: https://eamag.me/2026/why-parallel-diffusion-llms-are-slow-o...
      Gostaria de saber sua opinião sobre isso.
    • O Diffusion Gemma saiu no meio do projeto e considerei seriamente mudar de direção, mas decidi concluir no rumo original. Os dois projetos parecem combinar muito bem, e você pode usar livremente o código necessário ou entrar em contato pelo LinkedIn no fim do README.

  • Fico curioso por que há uma diferença tão grande entre 5–6 tokens por segundo no MacBook Air M2 de 8 GB e 31–35 tokens no MacBook Pro M5. Não parece que a diferença de desempenho do SSD seja tão grande, mas eu esperava que, nesse método, o SSD fosse o gargalo dominante

    • A melhoria de desempenho do SSD do M5 é considerável mesmo em comparação com a geração anterior. No Blackmagic Disk Speed Test, o MacBook Pro M5 chegou a 6.323 MB/s, enquanto o MacBook Pro M4 registrou 2.031 MB/s, uma diferença de mais de 3 vezes
      https://www.tomshardware.com/laptops/macbooks/m5-macbook-pro...
    • É bem provável que seja porque o M5 tem mais memória e o sistema operacional já cacheou a maior parte dos arquivos. No M2, a pressão de memória é maior, então ele deve cachear menos os resultados de leitura do SSD
      Se só puder usar 2 GB no total, incluindo o cache do sistema operacional, a velocidade de inferência pode cair ainda mais
    • Depende bastante do cache do sistema e de pread. Mesmo que o processo fique abaixo de 2 GB, o Mac M5 consegue cachear uma parte, e o próprio hardware também é muito mais rápido
      A leitura por token foi de 83 ms no M2 e 12 ms no M5 Pro, e o tempo total foi de 163 ms e 30 ms, respectivamente. É resultado de melhorias tanto na leitura quanto no processamento pela GPU
    • Como há uma diferença de gerações, mesmo comparando modelos Pro o SSD é muito mais lento; e, dentro da mesma geração, é provável que o SSD e a largura de banda de memória do Air sejam menores que os do Pro
    • O MacBook Pro M5 tem 24 GB de RAM, então também pode manter mais contexto na memória

  • Espero que, no futuro, sistemas com 30–60 GB de memória e SSDs muito rápidos consigam executar modelos gigantes usando técnicas como essa