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 相同，金鑰相同，計費也與平台上其他每個模型相同。