O que eu medi

O benchmark do lemon-model roda cinco casos nos dois modelos, com semente fixa e cinco medições por caso em cada uma de duas fases: fria e aquecida. Isso dá 50 medições por candidato. Na fase aquecida, há uma rodada de aquecimento antes das medições.

Ambiente registrado no relatório: Apple M3 Pro, 18 GiB de memória unificada, macOS 26.5.2, Python 3.12.12, MLX 0.32.2, mlx-lm 0.31.3.

Medianas da fase aquecida:

Caso	L1 primeiro token	L1 tokens/s	L2 primeiro token	L2 tokens/s
chat curto	104 ms	109,6	236 ms	26,9
contexto 2K	4,2 s	89,7	18,0 s	24,7
contexto 8K	23,7 s	62,6	88,2 s	20,0
fill-in-the-middle	148 ms	94,8	348 ms	27,1
loop de agente	121 ms	104,7	248 ms	26,3

Pico do alocador do MLX: de 916 MiB a 2.159 MiB no L1, de 4.207 MiB a 5.757 MiB no L2. Esse número é do alocador, não é o consumo total do processo.

A rodada final do L1 levou 604 segundos. A do L2, 2.156. Duas tentativas anteriores do L2 falharam com limites de tempo menores, e as duas falhas ficaram registradas como relatórios imutáveis.

O que os números mostram

• Velocidade de geração: o L1 é de três a quatro vezes mais rápido em tokens por segundo.
• Contexto longo dói: o tempo até o primeiro token cresce muito com o contexto. No L2, de 236 ms no chat curto para 88 s com 8K tokens.
• Os dois cabem: os dois completaram a suíte no Mac de 18 GB, o que é evidência de que cabem para essa carga de inferência.

Por que escolhi o L2 mesmo assim

Para treinar adaptações com LoRA (assunto do próximo post), capacidade importa mais que latência. O L2 tem 7B de parâmetros e evidência pública da mesma família de modelos. O L1 continua como reserva de baixa latência.

O próprio relatório deixa claro o limite dessa escolha: ela se baseia em desempenho de inferência. Não prova que o treino cabe na memória, que o LoRA vai funcionar, que a qualidade de código é boa ou que algum modelo está pronto para produção. Nenhum desses dois é um modelo treinado pelo lemon-model.

Duas regras que salvaram o Mac

• Tudo no volume externo. No macOS, o comando que baixa e mede modelos recusa caminhos de projeto, Python, modelos e cache fora de um volume externo em /Volumes. Modelos de 7B enchem o SSD interno rápido.
• Relatórios imutáveis. Cada execução grava as 50 medições brutas, o hardware, a semente, a identidade do modelo e o hash da suíte de prompts. Dá para auditar qualquer número desta tabela.

Como isso conversa com o lemon-code

No roteador do lemon-code (post 4), o provider mlx só entra na disputa se a máquina for Apple Silicon, o servidor local responder, o modelo do perfil ativo aparecer em /v1/models e a checagem de recursos não bloquear. É a regra de readiness antes do score, aplicada ao modelo local.

Checklist: antes de escolher um modelo local

• Meça tempo até o primeiro token com o contexto que você realmente usa.
• Meça tokens por segundo em execução aquecida, com várias repetições.
• Registre hardware, versões e semente junto com o resultado.
• Guarde as tentativas que falharam.
• Separe desempenho de qualidade: são avaliações diferentes.
• Mantenha um modelo pequeno como reserva rápida.

Conclusão

Um modelo de código local no Mac já é viável, com números que dá para medir e auditar. O pequeno responde rápido; o grande aguenta mais. O que o benchmark não responde é se algum deles escreve código bom o suficiente. Essa pergunta tem nome: avaliação, e ganha um post só para ela.

Na quarta, o próximo passo: LoRA e QLoRA com MLX, e o que aconteceu quando tentei treinar o 7B num Mac de 18 GB.

Se o seu time está avaliando modelos locais para código ou dados que não podem sair da empresa, desenhar esse benchmark é um trabalho que faço na LEMON.DEV.

Referências

• MLX, repositório oficial
• mlx-lm, repositório oficial
• Qwen2.5-Coder, relatório técnico

Leituras relacionadas

• Self-hosting de pesos abertos e VRAM
• Roteamento entre modelos com pontuação explicável