Fable5 se vuelve más caro y las GPU locales no alcanzan: DRIFT divide un LLM entre Mac y CUDA
(github.com/TaewoooPark)Los LLM se están alejando de las personas, y DRIFT responde dividiendo un solo LLM entre varios dispositivos personales.
DRIFT es un proyecto open source que ejecuta un único LLM repartido por capas entre varios dispositivos personales.
Hoy, cuando un desarrollador individual quiere experimentar directamente con IA, ninguna de las dos opciones es sencilla. El acceso a modelos de primer nivel como Fable5 está cada vez más limitado, y los modelos locales, pese a que se diga que “pueden correr en mi computadora”, en la práctica exigen bastante memoria de GPU y configuración. Aunque el modelo esté abierto, la capacidad de ejecutarlo a una escala suficientemente grande sigue concentrada en cierto hardware y ciertas plataformas. Al final, esto crea un entorno centralizado para la IA y limita mucho el nivel de acceso de las personas a la tecnología más reciente.
La pregunta que plantea DRIFT es simple.
Si una sola máquina no puede encargarse de todo el modelo, ¿no podrían varios dispositivos personales ejecutar juntos un único modelo?
DRIFT ejecuta un solo modelo usando en conjunto la GPU de Apple en Mac (MPS) y GPU NVIDIA (CUDA) en PC con Windows/Linux. Divide el modelo por capas decoder y, entre nodos, envía solo el hidden state, no el modelo completo ni la KV cache. La comunicación no se maneja con objetos de PyTorch ni handles de CUDA, sino con un protocolo neutral de bytes basado en TCP + msgpack.
Sus funciones principales son las siguientes.
- División automática de un LLM por capas decoder
- Ejecución mixta con Mac MPS y NVIDIA CUDA
- Uso de TCP + msgpack para la comunicación entre nodos
- Modo de cadena P2P para aliviar el cuello de botella de ancho de banda del nodo head
- Canal cifrado basado en X25519 y ChaCha20-Poly1305
- Verificación del trabajo de cada nodo con recibos firmados Ed25519
- Failover basado en re-split + replay cuando un nodo se cae a mitad de proceso
- API HTTP compatible con OpenAI
- En teoría, puede dividirse hasta la cantidad de capas decoder. Con Qwen por defecto, un modelo puede dividirse hasta en 28 máquinas; con Gemma, hasta en 35. Actualmente, el punto óptimo realista está en torno a 2 a 4 máquinas.
Entre los proyectos que resuelven problemas similares están Exo y llama.cpp RPC. Exo permite agrupar dispositivos Apple Silicon y usarlos como un clúster local, pero la comunicación entre nodos está ligada a MLX, por lo que es difícil salir del ecosistema de Apple. llama.cpp RPC puede aprovechar varios backends, pero es un enfoque RPC acoplado al runtime ggml/llama.cpp. El diferencial de DRIFT es que eleva el límite entre nodos a un protocolo neutral de bytes, en lugar de dejarlo atado a un runtime de ML específico. Por eso se enfoca en incorporar dentro de la ejecución de un solo modelo combinaciones que originalmente son difíciles de poner en un mismo runtime distribuido, como Apple MPS y NVIDIA CUDA.
La implementación de DRIFT está hecha sobre Python y PyTorch, pero el contrato entre nodos está definido de una forma que no depende de PyTorch. Para cargar y ejecutar modelos utiliza Hugging Face Transformers, safetensors y PyTorch MPS/CUDA, y hacia afuera ofrece una API compatible con OpenAI basada en Starlette/Uvicorn. La comunicación interna está envuelta en framing msgpack y una capa de cifrado, con un diseño que intenta separar “qué modelo corre en qué dispositivo” de “qué bytes intercambian los nodos”.
Personalmente, lo interesante de este proyecto es que no empieza la “descentralización de la IA” directamente desde una economía de tokens o una gran red. Lo primero que se necesita es una capa de ejecución en la que los dispositivos personales puedan participar realmente en la ejecución de un único modelo. Para construir encima una red más grande, hace falta una estructura que permita verificar quién calculó qué capa, recuperarse aunque un nodo se desconecte y no quedar atada a un proveedor o datacenter específico.
DRIFT no es un proyecto que priorice la velocidad. Su prioridad, más bien, es la exactitud. Pone el foco en verificar si, al ejecutarlo de forma distribuida, se obtiene la misma respuesta que al correrlo en una sola máquina. Según el README, Qwen2.5-1.5B-Instruct pasó varias pruebas de paridad, e incluye experimentos mezclando Mac MPS y NVIDIA CUDA.
En un contexto donde los modelos de IA de primer nivel se cierran cada vez más y la IA local sigue exigiendo hardware caro, DRIFT plantea una pregunta bastante realista.
Cuando los modelos frontier se alejan de los clientes individuales, ¿podemos unir los recursos personales para aumentar esa capacidad?
1 comentarios
DRIFT es un proyecto que, más que competir por velocidad, primero busca ver si es posible dividir y ejecutar con precisión un solo LLM entre dispositivos personales heterogéneos.
En particular, me gustaría pedir las opiniones y comentarios de muchos de ustedes sobre si sus diferencias frente a Exo / llama.cpp RPC / Petals son lo suficientemente convincentes, y sobre los puntos adicionales que se requieren en entornos profesionales al ejecutar de forma mixta MPS↔CUDA.