Project Maya: correr GLM-5.3-Flash (321B) en tus GPUs — memoria, tok/s y trampas
TL;DR
- Verificado (14-oct-2026): Project Maya es un motor open source (MIT) que corre GLM-5.3-Flash —el MoE de zai-org con 321B de parámetros y ~18B activos por token— en tu propio hardware: una GPU NVIDIA o hasta 16, repartiendo sus expertos entre VRAM, RAM y NVMe. Creado el 6-oct; ocho días después suma 838 stars, 99 forks, 24 issues abiertos (más 17 PRs) y push el mismo día de esta consulta.
- Verificado: sus quants propios bajan la huella a 96,5 GB (Maya-S) o 94,7 GB (Maya-S24, para tarjetas de 24 GB), y según sus benchmarks conservan el 97,7-99,2% de la accuracy zero-shot del FP8 original. Pesos en HF: 122.941 descargas del GGUF principal.
- Verificado (reports de usuarios, atribuidos a cada máquina): 118 tok/s de decode en 4x RTX 4090 (issue #89); 61,3 tok/s en 2x CMP 170HX; 53,0 con 2x RTX 3090; ~26-27 con una sola 3090; 22,6 con 4x Tesla T4 de 16 GB. AMD experimental, con Strix Halo entre 18,3 y 29,6 tok/s.
- Claim del proyecto: el contexto llega hasta 1M de tokens —y cabe en una sola RTX 3090 con KV streaming, dicen—; el drafting opcional DFlash2 acelera hasta +44%. El drafter tiene trampa de licencia: CC BY-NC-ND 4.0, no comercial, y se descarga solo si lo eliges.
- No es: una medición independiente. La accuracy de los quants y los tok/s salen de los benchmarks del propio proyecto y de reports de usuarios en issues; no hay todavía un tercero publicando réplicas. Del modelo en la nube ya analizamos qué hay bajo sus números.
Por qué correr un 321B en casa es siquiera una conversación
GLM-5.3-Flash es un MoE: 321B de parámetros totales, ~18B activos por token. En la nube es el clásico “casi frontier a precio de flash”: lo analizamos cuando salió y lo vimos adelantar a Claude en el Cyber Index de AA. Pero su precio en API dobló la misma semana de su debut ($0,075/$0,25 → $0,15/$0,50 por millón de tokens) según documentó nuestro radar del 29-ago, y cada token que le mandas sale de tu máquina hacia fuera.
La tesis de Project Maya es distinta: si el modelo es open weights (MIT) y la inferencia es MoE, no necesitas cargar 321B de parámetros en VRAM — solo los ~18B que se activan por token, más el resto de expertos “cerca”. Su motor mantiene los expertos que tu conversación más usa en GPU, los siguientes en RAM y el resto en el SSD NVMe, y los mueve mientras chateas. Se auto-mide el hardware (GPUs, CPU, RAM, SSD) y se ajusta. Nada sale de tu máquina: ni prompts, ni código, ni contexto. La variable que decides es cuánta memoria total tienes, no qué modelo te puedes permitir.
El resultado: un modelo del tamaño de un datacenter que corre en una torre. La pregunta interesante no es si funciona —838 stars en 8 días y una tabla de reports sugieren que sí—, sino qué parte de las cifras que promete vas a ver tú.
El modelo y sus quants: qué garantiza cada tier
Primero el sustrato. GLM-5.3-Flash (zai-org) es MIT: 321B totales, ~18B activos por token, contexto de hasta 1M. En HF suma 6.511.551 descargas y 2.851 likes (consulta del 14-oct). El proyecto se construye encima de Strata (MIT), ggml/llama.cpp (MIT) y el formato EXL3 de exllamav3. De ese modelo, Project Maya publica sus propios quants “hechos desde el release FP8 de Z.ai, con estadísticas del FP8”, cada uno conservando el bloque MTP (el que redacta tokens por adelantado):
| Tier | Tamaño | Para qué | Frente al FP8, según sus benchmarks |
|---|---|---|---|
| Maya-S (default) | 96,5 GB | PCs con el pool de memoria (RAM+VRAM) justo | 97,9% de la accuracy zero-shot; mismo next token el 83% de las veces |
| Maya-S24 | 94,7 GB | tarjetas de ≤24 GB: atención 4-bit deja ~1,5 GB más de tarjeta para expertos, decode +14% | 97,7%; 83% |
| Maya-M | 116 GB | pool mayor; calibrado a tool calls y código front-end | 97,9%; 86% |
| Maya-M-Derisked | 116 GB | Maya-M con edit de pesos de Blackfrost_AI contra refusals blanket; experimental | no medido |
| Maya-L | 156,3 GB | los pools más grandes | 99,2%; 90% |
Tres cosas que un dev debe leer en esa tabla. Primera: los porcentajes son su metodología, no una medición independiente — publican el detalle en bench/results/MAYA-*.md en el repo (lo comprobamos: ahí está el 97,9% de Maya-S y el 99,2% de Maya-L, con sus tablas task a task frente al FP8). Segunda: la distancia S→L es un 60% más de memoria por +1,3 puntos de accuracy: la curva se aplasta; elige por memoria disponible y tolerancia a degradación, no por el número mayor. Tercera: la fila “mismo next token” es el matiz honesto que casi nadie da — tu MoE local no produce la misma respuesta que el FP8; S/S24 coinciden el 83% de las veces, L el 90%. Para chat y para muchos usos agénticos sobra; para reproducir exactamente un pipeline validado contra el FP8, no.
Dónde está todo: peasantsmith/GLM-5.3-Flash-Maya-GGUF en HF (MIT, 122.941 descargas al 14-oct). Existe también la variante Derisked como repo aparte, y hasta una variante “abliterated” de terceros — señal de que la comunidad ya remezcla.
Las máquinas reales: qué decodifica cada presupuesto de hardware
La tabla de speed reports del README, atribuida a usuario, máquina e issue —reales pero no replicadas por terceros—, reordenada por lo que importa a la hora de comprar o reutilizar hardware:
| Máquina | Tier | Decode | Prefill (8K) | Reporta |
|---|---|---|---|---|
| 4x RTX 4090 24 GB + Xeon w7-3445, 62 GB RAM | Maya-S24 | 118 tok/s | 4.129 tok/s | #89 (cerrado) |
| 2x RTX 5880 Ada 45 GB, 393 GB RAM | Maya-L, 256K ctx | 54,5 tok/s | 1.401 tok/s | #149 |
| 2x RTX 3090 24 GB (225 W), Threadripper, 128 GB RAM | Maya-S24 | 53,0 tok/s | 885 tok/s | #135 (cerrado) |
| 2x CMP 170HX 64 GB (PCIe Gen2 x4) | Maya-M (todo en VRAM) | 61,3 tok/s | 514 tok/s | #22 (cerrado) |
| 2x Tesla V100 32 GB, 30 GB RAM | Maya-S | hasta 40 tok/s | 670 tok/s | mantenedor |
| RTX 3090 + RTX 3060, EPYC, 141 GB RAM | Maya-M, 128K ctx | 33,7 tok/s | 682 tok/s | #157 |
| RTX 5090 32 GB | Maya-M | 30+ tok/s | ~2.000 tok/s | #43 |
| 1x RTX 3090 (225 W) | Maya-S24 | 26,0 tok/s | 913 tok/s | #135 (cerrado) |
| 4x RTX 3080 20 GB | Maya-M, 512K ctx | 26,3 tok/s | - | #104 |
| RTX 5090 32 GB, Windows 11 | Maya-S, 128K ctx | 23,0 tok/s | 2.173 tok/s | #139 |
| 4x Tesla T4 16 GB, Xeon v2 viejo, 220 GB RAM | Maya-S | 22,6 tok/s | 416 tok/s | #36 |
| 1x Tesla V100 32 GB, 64 GB RAM | Maya-S | hasta 19 tok/s | 620 tok/s | mantenedor |
| AMD Strix Halo 8060S (128 GB) | Maya-S | 18,3 tok/s | 320 tok/s | #102 |
| RTX 4090 24 GB sola, Windows 11 | Maya-L, 128K ctx | 16,4 tok/s | 1.371 tok/s | #63 |
| RTX 5090 Laptop | Maya-S24 | 14,5 tok/s | 994 tok/s | #67 |
| AMD Strix Halo 8065S (192 GB LPDDR5X) | Maya-S, 32K ctx | hasta 29,6 tok/s | 278 tok/s | mantenedor |
Trampas de lectura, las que separan el número del titular de lo que verás tú:
- Decode y prefill son dos mundos. El 118 tok/s es decode (velocidad de escritura); el prefill de 8K en esa misma máquina es 4.129 tok/s, es decir, ~2 segundos por prompt de 8K. Para agentes que leen mucho y escriben poco, el prefill importa más; para chat, al revés.
- La RAM es la mitad de la ecuación. Las máquinas rápidas de la tabla tienen 62-393 GB de RAM y canales de memoria anchos (EPYC 8-channel, Threadripper). Una torre de consumo con 32 GB funcionará, pero los expertos que no quepan en VRAM vendrán del NVMe: espera velocidades de streaming, no las de la tabla.
- El ancho de banda PCIe decide en multi-GPU baratas. Las CMP 170HX van por PCIe Gen2 x4 — el cuello de botella está en el bus, no en la tarjeta: 61,3 tok/s a pesar de 128 GB de VRAM total.
- Contexto cuesta decode. El KV cache grande se come la VRAM que antes tenían los expertos, y más expertos acaban en RAM/NVMe. En los reports del README se intuye el patrón, sin A/B controlado — son máquinas y configuraciones distintas: 30+ tok/s con contexto corto en Maya-M sobre una RTX 5090 (Ryzen 9 7950X, 96 GB DDR5, #43) frente a 23,0 con 128K de contexto en Maya-S sobre otra RTX 5090 (Core i9-13900K, 64 GB, Windows 11, #139).
- AMD existe y es experimental. 18,3-29,6 tok/s en Strix Halo, texto solo, Windows 11. Nada de producción.
Lectura útil de la tabla completa del README (que trae más filas, con 2x RTX 4090 a 40,5 tok/s (#122) y 4x Tesla V100 a 48,3 tras calibrar (#130), entre otras): más VRAM y más RAM = más expertos cerca = más tok/s, hasta que el bus o el silicio manda. El patrón es consistente: las configuraciones que se quedan en un dígito alto de tok/s sirven para chatear y para agentes de una sesión, no para throughput.
El matiz de ventana temporal: estos números vienen de issues y del README, actualizado a diario. El repo tiene 8 días de vida y el rendimiento cambia con cada release (las filas nuevas llevan versión: v1.0.31, v1.1.4…). La adopción la medimos nosotros: 838 stars, 99 forks y 24 issues abiertos al 14-oct; en el triage de research del 6-oct eran 762 — 76 stars más en ocho días.
DFlash2, contexto 1M y paralelo: lo opcional con trampa
Drafting con DFlash2 (opcional): un drafter pequeño que redacta hasta 7 tokens por ronda y da las mismas respuestas: +44% en Maya-L con 9 GPUs, +12% con 2, +19% en una sola RTX 3090 — siempre contra el bloque MTP, y el README avisa: en una GPU que lee mucho de RAM puede ser más lento; por eso hay una calibración de velocidad que lo mantiene solo donde gana. La trampa: el drafter es CC BY-NC-ND 4.0 (no comercial), distinta de la MIT del motor y del modelo base, y se descarga solo si lo eliges. Si tu uso es comercial, no lo actives sin revisar la licencia.
Contexto largo y KV streaming: por defecto, cada capa guarda su KV cache en RAM con una ventana en VRAM: a 512K de contexto en una RTX 3090, prompts 4-9x más rápidos y decode +5%; 1M de contexto cabe en una 3090 — claim del proyecto, no replicado.
Paralelo (--parallel, hasta 8): sumando el throughput de todas las peticiones: x1,41 con 2 y x1,35 con 4 en una V100 que streamea expertos de RAM; x1,67/x2,02 en Strix Halo con todo en VRAM. El README explica el porqué (los pesos densos se leen una vez para todas las peticiones) — interesante para agentes con sesiones múltiples o varios usuarios en un PC.
Requisitos y trampas de instalación
- GPU: NVIDIA cc ≥7.0 (V100 / RTX 20+), de 1 a 16 que compartan el modelo. AMD experimental (RX 7900 XT/XTX, Strix/Gorgon Halo), texto solo, ROCm 7.
- RAM: 32 GB como mínimo (“32 GB runs it. More RAM keeps more experts close and is faster”).
- Disco: NVMe, no mecánico: ~100 GB para Maya-S, ~160 GB para Maya-L (+1,1 GB del encoder de imagen).
- Sistema: Linux x86-64 (AVX2 recomendado), CUDA 12.x (la 13 solo en RTX 20+; la V100 se queda en 12.x), g++, Python 3.10+. Windows 10/11 experimental. No WSL2.
- Instalación:
git clone && ./setup.sh: 20-40 min de build + descarga, y arranca el modelo solo, con chat y monitor enhttp://127.0.0.1:8080, API OpenAI-compatible en/v1y API Anthropic-compatible en/v1/messages(Claude Code:ANTHROPIC_BASE_URL=http://127.0.0.1:8080). Tool calls en streaming. - Trampa de RAM: el motor fija casi toda la RAM libre (todo menos ~6 GB) para su tier de expertos mientras corre. En un desktop de uso diario, Maya y tus otros programas van a pelearse.
- Trampa de seguridad: el acceso remoto existe (
--host 0.0.0.0 --api-key); úsalo siempre con key. Un modelo local con API abierta en LAN sin key es un agujero.
Para el método general —cuándo compensa self-hostear y con qué motor— tenemos una guía de self-hosting con llama.cpp y vLLM; Maya añade a ese mapa una pieza que no existía: la capa de gestión de expertos MoE entre VRAM/RAM/NVMe para un modelo concreto.
Cuándo gana y cuándo no
Gana si: tu carga es sensible a privacidad (código de cliente, datos de salud o legal), ya tienes las GPUs (rigs de juego con varias 3090/4090, workstations V100), o quieres una API Anthropic-compatible local para coding agents sin enviar código a la nube.
No gana si: tu hardware es una sola GPU de consumo con 32 GB de RAM — funcionará, pero a velocidades de chat personal, no de agente; necesitas throughput alto (batch, producción): el paralelo x2 máximo no compite con un endpoint dedicado; o quieres el modelo exacto de la nube: los quants no son bit-exactos con el FP8 (83-90% de mismo next token), y las métricas de accuracy son del propio proyecto.
El riesgo de plataforma: es un proyecto de 8 días con un solo mantenedor visible, un engine a medida para un único modelo, 24 issues abiertos y actividad a diario. El ritmo de cambio es alto — lo que hoy es cierto del setup puede cambiar en la v1.2. Sigue el repo antes de montar nada en producción.
Qué haría yo
- Si ya tienes las GPUs: Maya-S24 en 2x 3090 (53 tok/s reportados) o Maya-M en el pool que tengas. Pruébalo con tu carga real:
./maya.sh --benchexiste precisamente para eso, y compartir el resultado en un issue ayuda a todos. - Si compras hardware: el punto dulce de la tabla es el par de 3090 de segunda mano + 128 GB de RAM + NVMe rápido. El 118 tok/s de 4x4090 es demostración de ingeniería, no el punto de entrada.
- Si evaluáis self-hosting en el trabajo: piloto de dos semanas con la API Anthropic-compatible y vuestros prompts de coding agent reales. Métrica única: calidad aceptada frente al equivalente en cloud, y coste total (luz + amortización) frente a factura API. La guía de self-hosting cubre el método general.
- Lo que no haría: producción seria sobre un repo de 8 días sin replicación independiente de sus cifras. Pilotar sí; arquitecturar encima, todavía no.
Esto encaja en la línea que seguimos en el hub de modelos: el interés ya no está solo en el tamaño del modelo, está en qué hardware pone cada pieza al alcance de cada bolsillo.
Fuentes
- GitHub: mw00/project-maya — README (tabla de quants, speed reports, requisitos), 838 stars / 99 forks / push 2026-10-14 (API consultada el 14-oct-2026).
- Issues #89, #22, #135 — speed reports verbatim de 4x4090, 2xCMP 170HX y 1x/2x RTX 3090.
- Hugging Face: zai-org/GLM-5.3-Flash — modelo base, MIT, 6.511.551 descargas (14-oct-2026).
- Hugging Face: peasantsmith/GLM-5.3-Flash-Maya-GGUF — quants Maya, MIT, 122.941 descargas (14-oct-2026).
bench/results/MAYA-S.mdyMAYA-L.mden el repo — metodología de accuracy de los quants.