Kimi K3 (2,8T) a 1 token/s em um MacBook Pro, transmitido de quatro SSDs
Um desenvolvedor conseguiu executar o Kimi K3, um modelo Mixture-of-Experts de 2,8 trilhões de parâmetros, em um MacBook Pro transmitindo cerca de 1,45 TB de pesos de especialistas a partir de quatro SSDs, alcançando aproximadamente 1 token por segundo, mas com um atraso de 6 minutos antes do primeiro token em um prompt de 512 tokens. O projeto aprofunda como a largura de banda do disco, o escalonamento de leituras e as restrições do Thunderbolt moldam o desempenho, documentando quais otimizações ajudaram e quais prejudicaram (por exemplo, striping RAID-0 e cache em RAM). Os comentaristas debatem o valor prático de uma configuração tão lenta e limitada por armazenamento versus seu significado como prova de conceito para executar modelos em escala de fronteira localmente e totalmente offline.
Modelo & Desempenho
- MoE de 2,78T parâmetros (Kimi K3) com ~1,45 TB de pesos de especialistas, executado em um MacBook Pro M5 Max (128 GB) com 4 SSDs.
- Os especialistas são transmitidos do disco; o “tronco” de atenção (~50 GB) permanece residente na memória unificada em precisão int8.
- Decodificação relatada: ~1 token/s em 512 tokens, ~1,13 tok/s em 128 tokens, com comportamento consistente entre testes.
- O tempo até o primeiro token em um prompt de 512 tokens é de ~6,3 minutos devido ao pesado I/O de prefill.
Arquitetura de I/O & Escalabilidade
- Um arquivo de 17,5 MB por (camada, especialista); cada camada lê 16 especialistas por token e precisa esperar a leitura mais lenta.
- Quatro SSDs via gabinetes Thunderbolt 5; SSD interno בלבד fornece cerca de metade da taxa de decodificação de 4 unidades.
- “Escada” empírica de unidades: 1/2/3/4 unidades ≈ 52% / 73–78% / 90–92% / 100% da velocidade com 4 unidades; os retornos diminuem com mais unidades.
- RAID0/striping e algumas estratégias de cache foram medidos e mostraram piorar o desempenho, principalmente porque as barreiras são definidas pelo dispositivo mais lento.
Prefill, Contexto e Adequação da Carga de Trabalho
- O prefill é o principal gargalo: o escalonamento atual relê os especialistas várias vezes, causando ~9 TB de leituras para um modelo de 1,4 TB.
- Isso faz com que cargas de trabalho de “classificador de token único” (prompt longo, 1 token de saída) sejam atualmente o pior caso, e não o melhor.
- O KV cache cresce ~2,8 MiB por token; com 128 GB de RAM e outras reservas, o contexto fica limitado a cerca de 4,4k tokens nessa configuração.
- Um prefill proposto “expert-major” (ler cada especialista uma vez por camada, processar todas as linhas roteadas) poderia reduzir a amplificação de 6,2x para perto de ~1x.
Casos de Uso & Debate “Por que se preocupar?”
- Céticos argumentam que 1 tok/s com prefill de vários minutos é impraticável e caro para uso interativo.
- Defensores veem valor em:
- Trabalhos locais agendados e sem supervisão (relatórios, reconciliações) em que a latência não importa.
- Prova de conceito de que modelos do nível de fronteira podem rodar localmente de forma alguma.
- Experimentação hacker de “porque é difícil” e um passo rumo a designs mais eficientes.
Ferramentas, Metodologia e Documentação
- Instrumentação customizada (monitor de leitura por dispositivo, rastreamento de barreiras, asserts de configuração) revelou gargalos não óbvios; vários ganhos de >8–14% vieram de corrigir isso.
- Um grande catálogo de resultados negativos (cache, striping, streaming do trunk, várias APIs) é fornecido como dado de cautela.
- Alguns comentaristas acham o README denso e “LLM-like”, preferindo o TL;DR curto; é notada a irritação com documentação longa escrita por LLMs.
Futuros do Hardware & Ideias de Design de Modelos
- A discussão aborda limites de largura de banda de SSDs (Thunderbolt/PCIe), possíveis configurações desktop ou baseadas em GPU e chips de inferência estilo ASIC.
- Há debate sobre se modelos futuros deveriam ser mais modulares ou mais “grudentos” em seu roteamento de especialistas, de modo que apenas um pequeno subconjunto de pesos precise ficar residente na memória; as abordagens MoE atuais são vistas principalmente como economia de computação, não de memória.