Fable5 está ficando mais caro, e GPUs locais são escassas: DRIFT distribui um LLM entre Mac & CUDA
(github.com/TaewoooPark)Os LLMs estão se afastando das pessoas, e o DRIFT responde a isso distribuindo um único LLM por vários dispositivos pessoais.
DRIFT é um projeto open source que executa um único LLM dividido por camadas entre vários dispositivos pessoais.
Hoje, para um desenvolvedor individual que quer lidar diretamente com IA, nenhum dos dois lados é simples. Modelos de ponta como o Fable5 estão cada vez mais restritos, e os modelos locais, apesar do discurso de que “dá para rodar no meu computador”, na prática exigem uma quantidade considerável de memória de GPU e configuração. Mesmo quando o modelo é aberto, a capacidade de executá-lo em escala suficientemente grande continua concentrada em alguns hardwares e plataformas. No fim, isso cria um ambiente centralizado para a IA e impõe grandes limites ao quanto indivíduos conseguem acessar tecnologia de ponta.
A pergunta que o DRIFT faz é simples.
Se uma única máquina não consegue suportar o modelo inteiro, será que vários dispositivos pessoais não poderiam executá-lo juntos?
O DRIFT executa um único modelo usando ao mesmo tempo a Apple GPU (MPS) de um Mac e a GPU NVIDIA (CUDA) de PCs com Windows/Linux. Ele divide o modelo por camadas de decoder e, entre os nós, envia apenas o hidden state, não o modelo inteiro nem o cache KV. A comunicação é feita com um protocolo de bytes neutro baseado em TCP + msgpack, e não com objetos do PyTorch ou handles CUDA.
Os principais recursos são estes.
- divisão automática de um único LLM por camadas de decoder
- execução híbrida entre Mac MPS e NVIDIA CUDA
- uso de TCP + msgpack para comunicação entre nós
- modo de cadeia P2P para aliviar o gargalo de banda do nó head
- wire criptografado baseado em X25519 e ChaCha20-Poly1305
- verificação do trabalho de cada nó com recibos assinados em Ed25519
- failover baseado em re-split + replay quando um nó cai no meio da execução
- API HTTP compatível com OpenAI
- em teoria, pode ser dividido em tantas partes quanto o número de camadas de decoder. No Qwen padrão, isso permite distribuir um modelo por até 28 máquinas; no Gemma, até 35. Hoje, o ponto ideal mais realista está na faixa de 2 a 4 máquinas
Projetos que atacam um problema parecido incluem Exo e llama.cpp RPC. O Exo permite agrupar máquinas Apple Silicon e usá-las como um cluster local, mas a comunicação entre nós fica amarrada ao lado do MLX, o que dificulta sair do ecossistema Apple. O llama.cpp RPC pode aproveitar vários backends, mas é uma abordagem de RPC acoplada ao runtime do ggml/llama.cpp. O diferencial do DRIFT é elevar a fronteira entre os nós para um protocolo de bytes neutro, e não para um runtime específico de ML. Por isso, o foco está em colocar dentro da execução de um único modelo combinações que originalmente são difíceis de encaixar no mesmo runtime distribuído, como Apple MPS e NVIDIA CUDA.
A implementação do DRIFT é feita sobre Python e PyTorch, mas o contrato entre os nós foi definido de forma a não depender do PyTorch. O carregamento e a execução do modelo usam Hugging Face Transformers, safetensors e PyTorch MPS/CUDA, enquanto externamente ele oferece uma API compatível com OpenAI baseada em Starlette/Uvicorn. A comunicação interna é encapsulada por framing em msgpack e uma camada de criptografia, numa arquitetura que busca separar “qual modelo roda em qual dispositivo” de “quais bytes os nós trocam entre si”.
Pessoalmente, o que torna esse projeto interessante é que ele não começa a discussão sobre “descentralização da IA” falando logo de economia de tokens ou de redes gigantes. O que vem antes é uma camada de execução real em que dispositivos pessoais possam de fato participar da execução de um único modelo. É preciso haver uma estrutura em que seja possível verificar quem calculou qual camada, recuperar a execução quando um nó sai, e evitar dependência de um fornecedor específico ou de um datacenter, para então construir uma rede maior sobre isso.
O DRIFT não é um projeto que prioriza velocidade. Pelo contrário: a prioridade é a precisão. O foco está em verificar se a execução distribuída produz a mesma resposta que a execução em uma única máquina. Segundo o README, ele já passou por vários parity gates com o Qwen2.5-1.5B-Instruct, e inclui experimentos misturando Mac MPS e NVIDIA CUDA.
Em um cenário em que os modelos de IA mais avançados estão cada vez mais fechados, e a IA local ainda exige hardware caro, o DRIFT levanta uma pergunta bastante realista.
Quando os modelos de fronteira se afastam dos usuários individuais, será que dá para unir recursos pessoais e ampliar essa capacidade?
1 comentários
O DRIFT é um projeto que, antes de competir por velocidade, busca verificar se é possível dividir e executar corretamente um único LLM em dispositivos pessoais heterogêneos!
Em especial, gostaria de ouvir as opiniões e o feedback de muitas pessoas sobre se os diferenciais em relação ao Exo / llama.cpp RPC / Petals são suficientemente convincentes, e sobre os pontos adicionais exigidos no trabalho profissional ao executar de forma mista MPS↔CUDA.