Qwen 3.5 no MacBook Pro: Comparação de oito servidores locais para trabalho em equipe

A execução local de grandes modelos no Mac deixou de ser brinquedo para entusiastas há muito tempo, mas a história com Qwen 3.5 35B mostra que existe uma grande distância entre "funciona" e "serve como API para equipe." O autor pegou um MacBook Pro M2 Max com 64 GB de RAM e testou não o modelo em si, mas a infraestrutura ao seu redor: qual servidor MLX aguenta carga de trabalho real, não apenas apresenta números bonitos nos logs e não desaba assim que dois usuários chegam simultaneamente.

Para o teste, construíram um harness Python separado e rodaram oito servidores locais posicionados como forma rápida de subir uma API em modelos MLX no macOS. A validação não se baseou em uma pergunta conveniente única, mas em um conjunto de oito prompts de tipos e comprimentos diferentes, incluindo tarefas de nível AIME e entradas longas de até 52 mil tokens. Cada cenário executou cinco vezes para eliminar picos aleatórios e obter um quadro mais honesto de latência, velocidade de geração e comportamento geral sob carga.

Ênfase especial foi colocada em avaliar não a velocidade pico de laboratório, mas o comportamento do sistema em condições próximas ao trabalho real: com respostas em streaming, overhead de rede e condições de medição repetíveis.

Em modo single-user, havia pouca intriga: os três primeiros mostraram resultados similares, e em sessões curtas a diferença entre eles parecia mais cosmética. É exatamente por isso que as promessas de marketing nos READMEs enganam facilmente. Se você olhar apenas para uma solicitação única, parece que quase qualquer servidor MLX moderno já é bom o suficiente para trabalho cotidiano. Mas essa conclusão se desmorona imediatamente assim que o modelo local se transforma de ferramenta pessoal em serviço para equipe, onde solicitações começam a se sobrepor no tempo.

O estágio mais revelador do teste—carga paralela de duas solicitações. Aqui é onde uma lacuna real entre soluções emergiu. Quatro frameworks de seis essencialmente caíram em fila e atenderam solicitações quase sequencialmente, embora ainda parecessem multithreaded na superfície. Outro servidor manteve paralelismo apenas formalmente e despencou para um coeficiente de 0,85x, significando que a segunda solicitação prejudicava em vez de ajudar a utilizar o hardware. Apenas um participante do teste mostrou aceleração honesta de 2,17x, o que já parece comportamento adequado para uma API local de equipe, onde importa não apenas responder um usuário rapidamente, mas lidar com múltiplas solicitações sem degradação dramática.

Pelo caminho, problemas emergiram que importam mais que números secos em uma tabela. Em um lugar, o autor esbarrou em atenção quadrática, que em 2026 ainda pode degradar severamente o comportamento em contextos longos. Em outro—phantom 14.000 tokens/sec que apareceu não por otimização mágica, mas por uma única linha em um parser SSE que distorceu a medição. Separadamente vale mencionar um processo zumbi que deixou por trás cerca de 20 GB de RAM ocupada, embora READMEs prefiram ficar silenciosos sobre tal risco.

Para quem planeja produção local, estas não são miudezas: tais bugs impactam previsibilidade de serviço, monitoramento e custos de suporte muito mais que diferenças de alguns percentuais em velocidade bruta.

O valor prático deste trabalho reside em deslocar foco de promessas bonitas para casos de uso reais. Se um modelo é necessário por um desenvolvedor para solicitações ocasionais, pode-se olhar simplicidade de deployment e velocidade básica. Mas se estamos falando de uma API de equipe com paralelismo, contextos longos e necessidade de recuperar rapidamente de falhas, escolher servidor baseado em README já é perigoso.

Este benchmark mostra uma coisa simples: a stack local para Qwen 3.5 deve ser avaliada como infraestrutura, não como demo. Senão você pode acabar com um sistema que parece "rápido" em testes únicos mas em uso real transforma um MacBook poderoso em uma fila cara de solicitações.