Zen: la arquitectura MoE que pasa de 1T parámetros

Zen es la familia de modelos de lenguaje bandera de Hanzo. El modelo más grande, zen4-ultra, es una arquitectura Mixture of Experts (MoE) de 1.04T parámetros que activa 140B parámetros en cada forward pass. Es el cierre de tres años de desarrollo, desde zen-nano (600M) hasta la familia zen4 de ahora.

Este post describe la arquitectura, cómo se entrena y el sistema de verificación on-chain que vuelve auditables los modelos Zen.

Arquitectura

Zen4-ultra usa una arquitectura Mixture of Experts dispersa. El diseño de base:

• Parámetros totales: 1.04T
• Parámetros activos por token: ~140B (tasa de activación del 13.5%)
• Expertos: 128 expertos por capa MoE, ruteo top-8
• Capas: 96 capas transformer; una de cada dos es MoE (48 capas MoE, 48 densas)
• Ventana de contexto: 256K tokens (interpolación posicional YaRN)
• Vocabulario: 152K tokens (BPE multilingüe)

El ruteo MoE usa una red de compuerta aprendida, con una pérdida auxiliar de balanceo de carga para que los expertos no colapsen. Cada experto es una FFN estándar (red feed-forward) con activación SwiGLU. El router elige 8 de 128 expertos por token: alcanza para capturar patrones de razonamiento complejos y el cómputo se mantiene tratable.

Por qué MoE

Los modelos densos escalan en línea recta: 2x parámetros = 2x de cómputo por token. MoE rompe esa relación. Zen4-ultra tiene 7.4x los parámetros totales de un modelo denso de 140B, con el mismo costo de inferencia por token. Los parámetros extra dan capacidad — el modelo guarda más conocimiento y aguanta tareas más diversas — sin subir el cómputo en la misma proporción.

El tradeoff es la memoria. Hay que cargar los 1.04T parámetros, aunque solo 140B estén activos. Hace falta inferencia distribuida entre varios nodos, y ahí la red ACI se vuelve esencial.

La familia Zen4

Modelo	Params totales	Params activos	Arquitectura
zen4-mini	4B	4B	Densa
zen4-base	8B	8B	Densa
zen4-pro	14B	14B	Densa
zen4-max	30B	8B	MoE (32 expertos, top-2)
zen4-coder	80B	20B	MoE (64 expertos, top-4)
zen4-ultra	1.04T	140B	MoE (128 expertos, top-8)

Cada modelo de la familia comparte el mismo tokenizer, la misma implementación de atención y el mismo pipeline de datos de entrenamiento. Los modelos densos (de mini a pro) se destilan desde ultra; no se entrenan por su cuenta. Así el comportamiento queda parejo en toda la familia.

Fusión de modelos

Los modelos Zen no se entrenan desde cero con inicialización al azar. Se fusionan a partir de modelos open-weight que rinden arriba, con una metodología que llamamos transferencia estructurada de conocimiento.

La arquitectura base es Qwen3. Cada modelo Zen arranca de un checkpoint de Qwen3 — es una restricción dura de gobernanza bajo la política de la Zoo Foundation (solo Qwen3+). El proceso de fusión:

1. Alineación de arquitectura: se mapean las arquitecturas de los modelos fuente a la arquitectura destino de Zen. En los modelos MoE, esto incluye inicializar los expertos desde capas de un modelo denso con la técnica de upcycling DROP (la contamos en el texto Drop-Upcycling: armar modelos MoE de calidad 13B a 1/4 del costo).

2. Destilación de conocimiento: se entrena el modelo Zen con una mezcla de (a) datos crudos de preentrenamiento y (b) salidas de teachers tomadas de los modelos fuente. El ensemble de teachers incluye checkpoints de Qwen3, DeepSeek y Mistral elegidos por cómo les va en las capacidades objetivo.

3. Especialización de expertos: después de la fusión inicial, cada experto se afina con datos de un dominio — matemática, código, razonamiento científico, texto multilingüe — para empujar la especialización. El router aprende a mandar los tokens de un dominio a los expertos de ese dominio.

4. Alineación de comportamiento: las entradas de experiencia DSO (optimización semántica descentralizada) del libro mayor de la Zoo Foundation se usan para el ajuste final de comportamiento. Esta es la capa de gobernanza de la comunidad: los comportamientos que Zen muestra los fijan las entradas que la comunidad votó dentro del libro mayor.

Entrenamiento distribuido

El entrenamiento de zen4-ultra corre en clústeres de cómputo de Hanzo Network — nodos bare-metal con 8x H100 cada uno, conectados por InfiniBand. La infraestructura de entrenamiento:

• Framework: PyTorch con FSDP (datos totalmente partidos en paralelo) para las capas densas, y un particionado propio de expertos en paralelo para las capas MoE
• Nodos: 512 nodos (4096 GPU H100) para la corrida completa de ultra
• Tiempo de entrenamiento: 14 días para la fase final de fusión y especialización
• Datos: 15T tokens, sin duplicados, filtrados por calidad, multilingües (97 idiomas)
• Checkpoints: cada 1000 pasos, subidos a Hanzo Storage con hash por contenido

La estrategia de paralelismo de expertos pone cada experto en una sola GPU y usa comunicación all-to-all para rutear los tokens. Comunica más que el paralelismo de datos, pero se ahorra el costo de memoria de replicar todos los expertos en cada GPU.

Atestación on-chain del modelo

Cada checkpoint de un modelo Zen tiene una atestación on-chain en Hanzo Network. La atestación incluye:

• Hash del modelo: SHA-256 del tensor de pesos completo, calculado de forma determinista desde la serialización canónica safetensors
• Hash de la config de entrenamiento: SHA-256 de la configuración completa (hiperparámetros, mezcla de datos, asignación de cómputo)
• Resultados de benchmark: scores estándar (MMLU, HumanEval, MATH, etc.) calculados por evaluadores independientes del comité de evaluación de la Zoo Foundation
• Atestación TEE: atestación Intel TDX o AMD SEV de los nodos de entrenamiento, que prueba que el entrenamiento corrió en el hardware que se dijo y con el código que se dijo

El contrato de atestación está desplegado en Hanzo Network en una dirección conocida. Cualquiera puede chequear que un conjunto de pesos matchea el hash atestado y que los resultados de benchmark los produjo el comité de evaluación, no un autorreporte.

Esto no frena todas las formas de hacer trampa — la contaminación de benchmarks en los datos de entrenamiento sigue siendo difícil de ver —, pero deja una cadena verificable desde el hardware de entrenamiento hasta los pesos publicados y el rendimiento que se afirma. Si el hash no matchea, los pesos fueron modificados. Si la atestación TEE es inválida, el entorno de entrenamiento no era el que se declaró.

Inferencia en ACI

Zen4-ultra necesita aproximadamente 2TB de memoria para cargar todos los parámetros en FP16. Ningún nodo tiene tanta memoria de GPU. La inferencia se reparte entre nodos de cómputo ACI con paralelismo de tensores:

• Paralelismo de tensores de 8 vías entre GPU H100 de un solo nodo para las capas densas
• Paralelismo de expertos entre nodos para las capas MoE: cada nodo guarda un subconjunto de expertos
• Decodificación especulativa con zen4-mini como modelo draft, con una mejora de throughput de 3.2x en generación larga

Latencia de punta a punta para una generación de 256 tokens: 1.8 segundos hasta el primer token, 45 tokens/segundo después. Compite con los modelos densos del mismo conteo de parámetros activos, aunque haya overhead distribuido.

Pesos abiertos

Todos los modelos Zen salen bajo Apache 2.0 en HuggingFace y en el repositorio hanzoai/zen. Van los pesos, el tokenizer, las configs de entrenamiento y los scripts de evaluación. El mandato de pesos abiertos es un requisito estructural de la gobernanza de la Zoo Foundation: está escrito en el estatuto de la organización, no es una política que se pueda elegir.

Links

• Modelos: huggingface.co/zenlm
• Fuente: github.com/hanzoai/zen
• Atestaciones: explore.hanzo.network — registros de atestación on-chain del modelo
• Benchmarks: zenlm.org/benchmarks

---

Hanzo AI es Techstars '17. Modelos Zen: zenlm.org. Hanzo: hanzo.ai.