Zen: arquitetura MoE com 1T+ parâmetros

Zen é a família de modelos de linguagem principal de Hanzo. O maior modelo, zen4-ultra, é uma arquitetura Mixture of Experts (MoE) de 1.04 trilhões de parâmetros que ativa 140B parâmetros em cada passagem para a frente. É o ponto de chegada de três anos de desenvolvimento de modelos, do zen-nano (600M) até a família zen4 atual.

Este post descreve a arquitetura, o método de treino e o sistema de verificação on-chain que torna os modelos Zen auditáveis.

Arquitetura

O zen4-ultra usa uma arquitetura Mixture of Experts esparsa. O desenho central:

• Parâmetros totais: 1.04T
• Parâmetros ativos por token: ~140B (taxa de ativação de 13.5%)
• Especialistas: 128 especialistas por camada MoE, roteamento top-8
• Camadas: 96 camadas transformer; uma a cada duas é MoE (48 camadas MoE, 48 densas)
• Janela de contexto: 256K tokens (interpolação posicional YaRN)
• Vocabulário: 152K tokens (BPE multilíngue)

O roteamento MoE usa uma rede de porta aprendida, com uma perda auxiliar de balanceamento de carga para evitar o colapso dos especialistas. Cada especialista é uma FFN padrão (rede feed-forward) com ativação SwiGLU. O roteador escolhe 8 de 128 especialistas por token — diversidade suficiente para captar padrões de raciocínio complexos, com o compute ainda tratável.

Por que MoE

Modelos densos escalam em linha reta: 2x parâmetros = 2x de compute por token. O MoE quebra essa relação. O zen4-ultra tem 7.4x os parâmetros totais de um modelo denso de 140B, com o mesmo custo de inferência por token. Os parâmetros a mais dão capacidade — o modelo guarda mais conhecimento e segura tarefas mais diversas — sem aumento proporcional de compute.

O tradeoff é a memória. Todos os 1.04T parâmetros precisam ser carregados, mesmo que só 140B estejam ativos. Isso exige inferência distribuída em vários nós, e é aí que a rede ACI vira essencial.

A família Zen4

Modelo	Params totais	Params ativos	Arquitetura
zen4-mini	4B	4B	Densa
zen4-base	8B	8B	Densa
zen4-pro	14B	14B	Densa
zen4-max	30B	8B	MoE (32 especialistas, top-2)
zen4-coder	80B	20B	MoE (64 especialistas, top-4)
zen4-ultra	1.04T	140B	MoE (128 especialistas, top-8)

Cada modelo da família compartilha o mesmo tokenizer, a mesma implementação de atenção e o mesmo pipeline de dados de treino. Os modelos densos (de mini a pro) são destilados do ultra, não treinados à parte. Isso segura a consistência de comportamento na família inteira.

Fusão de modelos

Os modelos Zen não são treinados do zero numa inicialização aleatória. Eles são fundidos a partir de modelos de pesos abertos que rendem no topo, com um método que a gente chama de transferência estruturada de conhecimento.

A arquitetura base é Qwen3. Cada modelo Zen começa de um checkpoint Qwen3 — isso é uma restrição dura de governança sob a política da Zoo Foundation (só Qwen3+). O processo de fusão:

1. Alinhamento de arquitetura: mapeia as arquiteturas dos modelos de origem para a arquitetura alvo do Zen. Nos modelos MoE, isso inclui inicializar os especialistas a partir de camadas de um modelo denso com a técnica de upcycling DROP (descrita no nosso texto Drop-Upcycling: construir modelos MoE com qualidade de 13B a 1/4 do custo).

2. Destilação de conhecimento: treina o modelo Zen numa mistura de (a) dados crus de pré-treino e (b) saídas de professores tiradas dos modelos de origem. O conjunto de professores inclui checkpoints de Qwen3, DeepSeek e Mistral escolhidos pelo desempenho de benchmark nas capacidades alvo.

3. Especialização de especialistas: depois da fusão inicial, cada especialista é afinado em dados de um domínio — matemática, código, raciocínio científico, texto multilíngue — para empurrar a especialização. O roteador aprende a mandar tokens de um domínio para os especialistas daquele domínio.

4. Alinhamento de comportamento: as entradas de experiência DSO (otimização semântica descentralizada) do livro-razão da Zoo Foundation servem para o ajuste final de comportamento. Esta é a camada de governança da comunidade — os comportamentos que o Zen mostra são definidos pelas entradas que a comunidade votou no livro-razão.

Treino distribuído

O treino do zen4-ultra roda nos clusters de compute da Hanzo Network — nós bare-metal com 8x H100 cada, ligados por InfiniBand. A infraestrutura de treino:

• Framework: PyTorch com FSDP (dados totalmente fatiados em paralelo) para as camadas densas, e um fatiamento próprio de especialistas em paralelo para as camadas MoE
• Nós: 512 nós (4096 GPUs H100) para a corrida completa do ultra
• Tempo de treino: 14 dias para a fase final de fusão e especialização
• Dados: 15T tokens, sem duplicatas, filtrados por qualidade, multilíngues (97 idiomas)
• Checkpoints: a cada 1000 passos, enviados ao Hanzo Storage com hash endereçado pelo conteúdo

A estratégia de paralelismo de especialistas coloca cada especialista numa única GPU e usa comunicação all-to-all para rotear os tokens. Comunica mais do que o paralelismo de dados, mas evita o custo de memória de replicar todos os especialistas em cada GPU.

Atestação on-chain do modelo

Cada checkpoint de um modelo Zen tem uma atestação on-chain na Hanzo Network. A atestação inclui:

• Hash do modelo: SHA-256 do tensor de pesos completo, calculado de forma determinística a partir da serialização canônica safetensors
• Hash da configuração de treino: SHA-256 da configuração completa (hiperparâmetros, mistura de dados, alocação de compute)
• Resultados de benchmark: pontuações padronizadas (MMLU, HumanEval, MATH, etc.) calculadas por avaliadores independentes do comitê de avaliação da Zoo Foundation
• Atestação TEE: atestação Intel TDX ou AMD SEV dos nós de treino, provando que o treino rodou no hardware declarado e com o código declarado

O contrato de atestação está implantado na Hanzo Network num endereço conhecido. Qualquer pessoa pode conferir que um conjunto de pesos bate com o hash atestado e que os resultados de benchmark vieram do comitê de avaliação, e não de um autorrelato.

Isso não impede toda forma de jogo — a contaminação de benchmarks nos dados de treino continua difícil de detectar —, mas deixa uma cadeia verificável do hardware de treino até os pesos publicados e o desempenho alegado. Se o hash não bater, os pesos foram modificados. Se a atestação TEE for inválida, o ambiente de treino era outro que não o declarado.

Inferência na ACI

O zen4-ultra precisa de aproximadamente 2TB de memória para carregar todos os parâmetros em FP16. Nenhum nó sozinho tem tanta memória de GPU. A inferência se distribui pelos nós de compute da ACI com paralelismo de tensores:

• Paralelismo de tensores em 8 vias entre GPUs H100 de um único nó para as camadas densas
• Paralelismo de especialistas entre nós para as camadas MoE — cada nó guarda um subconjunto de especialistas
• Decodificação especulativa com o zen4-mini como modelo rascunho, com ganho de vazão de 3.2x na geração longa

Latência de ponta a ponta para uma geração de 256 tokens: 1.8 segundos até o primeiro token, depois 45 tokens/segundo. Competitiva com modelos densos no mesmo número de parâmetros ativos, mesmo com o overhead distribuído.

Pesos abertos

Todos os modelos Zen saem sob Apache 2.0 no HuggingFace e no repositório hanzoai/zen. Pesos, tokenizer, configurações de treino e scripts de avaliação estão incluídos. O mandato de pesos abertos é uma exigência estrutural da governança da Zoo Foundation — está escrito no estatuto da organização, não é uma política discricionária.

Links

• Modelos: huggingface.co/zenlm
• Fonte: github.com/hanzoai/zen
• Atestações: explore.hanzo.network — registros de atestação on-chain do modelo
• Benchmarks: zenlm.org/benchmarks

---

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