Zen4 Coder：480B 参数里，真正动用的少了 92%，面向代码的专家混合模型

稠密模型在每个 token 上浪费 90% 的参数。对代码来说——知识在语法、语义、类型系统和自然语言之间高度结构化——这种浪费尤其严重。

今天我们发布 Zen4 Coder，一个 480B 参数的 Mixture of Experts 模型，每次前向只激活 35B 参数。它知道的和 480B 模型一样多。它花费的和 35B 模型一样多。

三个模型，覆盖每一种代码工作流

Zen4 Coder — 通用代码模型。

• 总计 480B / 活跃 35B（MoE）
• 163K 上下文窗口
• 所有主要编程语言
• 智能体工具使用与多步推理

Zen4 Coder Pro — 最高精度。

• 480B 参数，完整 BF16 精度（稠密）
• 131K 上下文窗口
• 用于复杂的多文件重构和大型代码库导航
• 当你要的是最好的答案，而不是最快的

Zen4 Coder Flash — 实时代码辅助。

• 总计 30B / 活跃 3B（MoE）
• 262K 上下文窗口
• 行内补全、Tab 补全，以及代码对话
• 交互式工作流的延迟 Sub-100ms

为什么 MoE 架构对代码重要

Mixture of Distilled Experts（MoDE）架构把每个 token 路由到专门的专家子网络。在 Zen4 Coder 中，这为下列事项建立了专用通路：

• 语法专家 — 特定语言的语法与结构
• 语义专家 — 含义、意图与程序逻辑
• 类型推断专家 — 类型系统、泛型与约束
• 文档专家 — 注释、docstring 和说明中的自然语言

生成 Python 时，Python 语法专家与语义推理专家一起激活。Java 类型系统专家保持休眠。这种选择性激活，让 480B 模型跑起来像 35B 模型。

为真实代码库而设的上下文窗口

Zen4 Coder 的 163K 上下文窗口装得下：

• 一个典型的微服务代码库（50-100 个文件）
• 整个 Go 模块或 Rust crate
• 带组件、hook 和状态管理的完整 React 应用

Coder Flash 的 262K 窗口能处理更大的代码搜索与导航负载。

Coder Pro 的 131K 窗口为深度分析而优化——用上下文长度换取复杂推理任务上的最高精度。

现已可用

三个 Zen4 Coder 模型都可通过 Hanzo AI 网关在 hanzo.ai 使用。请用标准的 OpenAI 兼容 API：

curl https://llm.hanzo.ai/v1/chat/completions \
  -H "Authorization: Bearer $HANZO_API_KEY" \
  -d '{
    "model": "zen4-coder",
    "messages": [{"role": "user", "content": "Refactor this function to use async/await..."}]
  }'

API 相同，密钥相同，计费也与平台上其他每个模型相同。