Zen: arquitectura MoE de 1T+ parámetros

Zen es la familia de modelos de lenguaje insignia de Hanzo. El modelo mayor, zen4-ultra, es una arquitectura Mixture of Experts (MoE) de 1.04T parámetros que activa 140B parámetros en cada pasada hacia delante. Es la culminación de tres años de desarrollo de modelos, desde zen-nano (600M) hasta la familia zen4 actual.

Este artículo describe la arquitectura, la metodología de entrenamiento y el sistema de verificación en cadena que hace auditables los modelos Zen.

Arquitectura

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

Parámetros totales: 1.04T
Parámetros activos por token: ~140B (razón de activación del 13.5%)
Expertos: 128 expertos por capa MoE, encaminamiento 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 encaminamiento MoE usa una red de compuerta aprendida con una pérdida auxiliar de equilibrio de carga para evitar el colapso de expertos. Cada experto es una FFN estándar (red de alimentación hacia delante) con activación SwiGLU. El router elige 8 de 128 expertos por token: diversidad bastante para captar patrones de razonamiento complejos y cómputo que sigue siendo tratable.

Por qué MoE

Los modelos densos escalan de forma lineal: 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, pero el mismo coste de inferencia por token. Los parámetros de más dan capacidad — el modelo guarda más conocimiento y atiende tareas más diversas — sin un aumento proporcional del cómputo.

La contrapartida es la memoria. Hay que cargar los 1.04T parámetros, aunque solo 140B estén activos. Eso exige inferencia distribuida entre varios nodos, y ahí la red ACI se vuelve imprescindible.

La familia Zen4

Modelo	Parámetros totales	Parámetros 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)

Todos los modelos de la familia comparten el mismo tokenizador, la misma implementación de atención y el mismo canal de datos de entrenamiento. Los modelos densos (de mini a pro) se destilan de ultra, no se entrenan por separado. Así se asegura un comportamiento coherente en toda la familia.

Fusión de modelos

Los modelos Zen no se entrenan desde cero con una inicialización aleatoria. Se funden a partir de modelos de pesos abiertos de alto rendimiento, con una metodología que llamamos transferencia de conocimiento estructurada.

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:

Alineación de arquitectura: se proyectan las arquitecturas de los modelos fuente sobre 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 (descrita en nuestro texto Drop-Upcycling: modelos MoE de calidad 13B a 1/4 del coste).
Destilación de conocimiento: se entrena el modelo Zen con una mezcla de (a) datos crudos de preentrenamiento y (b) salidas de profesores tomadas de los modelos fuente. El conjunto de profesores incluye checkpoints de Qwen3, DeepSeek y Mistral elegidos por su resultado en las capacidades objetivo.
Especialización de expertos: tras la fusión inicial, cada experto se afina con datos de un dominio — matemáticas, código, razonamiento científico, texto multilingüe — para empujar la especialización. El router aprende a enviar los tokens de un dominio a los expertos de ese dominio.
Alineación de comportamiento: las entradas de experiencia DSO (optimización semántica descentralizada) del libro mayor de la Zoo Foundation sirven para el ajuste final de comportamiento. Esta es la capa de gobernanza de la comunidad: los comportamientos que muestra Zen los deciden las entradas que la comunidad ha votado en el 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, unidos por InfiniBand. La infraestructura de entrenamiento:

Marco: PyTorch con FSDP (datos totalmente particionados en paralelo) para las capas densas, y un particionado propio en paralelo de expertos para las capas MoE
Nodos: 512 nodos (4096 GPU H100) para la tanda 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 lenguas)
Checkpoints: cada 1000 pasos, subidos a Hanzo Storage con hash por contenido

La estrategia de paralelismo de expertos coloca cada experto en una sola GPU y usa comunicación all-to-all para encaminar los tokens. Comunica más que el paralelismo de datos, pero evita el coste de memoria de replicar todos los expertos en cada GPU.

Atestación del modelo en cadena

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

Hash del modelo: SHA-256 del tensor de pesos completo, calculado de forma determinista a partir de la serialización canónica safetensors
Hash de la configuración de entrenamiento: SHA-256 de la configuración completa (hiperparámetros, mezcla de datos, reparto de cómputo)
Resultados de benchmark: puntuaciones normalizadas (MMLU, HumanEval, MATH, etc.) calculadas 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 declarado y con el código declarado

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

Esto no impide todas las formas de manipulación — la contaminación de benchmarks en los datos de entrenamiento sigue siendo difícil de detectar —, pero da una cadena verificable desde el hardware de entrenamiento hasta los pesos publicados y el rendimiento declarado. Si el hash no coincide, los pesos se han modificado. Si la atestación TEE no es válida, el entorno de entrenamiento no era el que se declaró.

Inferencia en ACI

Zen4-ultra necesita unos 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 borrador, con una mejora de caudal de 3.2x en la generación de forma larga

Latencia de extremo a extremo para una generación de 256 tokens: 1.8 segundos hasta el primer token, 45 tokens/segundo después. Competitiva con los modelos densos del mismo número de parámetros activos, pese al sobrecoste de la distribución.

Pesos abiertos

Todos los modelos Zen se publican bajo Apache 2.0 en HuggingFace y en el repositorio hanzoai/zen. Van incluidos los pesos, el tokenizador, las configuraciones 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 los estatutos de la organización, no es una política discrecional.

Enlaces

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

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