Union Alpha 真身揭曉：多模型合成與我們的 m-a-s 閒談

一句話總結 OpenRouter 上神秘隱身模型 Union Alpha 的真身是 Unbiased 公司的 Pareto——一個「複合混合路由矩陣」：後台並行觸發多顆頂尖 LLM，再在終端做結果合成。看到這個架構描述的第一反應：這不就是我們 multi-agent-synthesizer（m-a-s）在應用層做的事嗎？ 這篇文章聊聊這件事、兩者的差距，以及 m-a-s 這次因此長出的新能力。

Union Alpha 事件：從隱身到揭曉只用了兩天

事情是這樣的：OpenRouter 上出現一顆冠上「Union Alpha」的神秘 stealth 模型，社群猜它是 GPT-6 變體、DeepSeek 新模型……結果真身是 AI 新創 Unbiased 推出的 Pareto（unbiased/pareto）。

它的規格與官方跑分

• 複合模型架構：不是單體模型，而是「混合路由矩陣」——一個請求並行觸發多顆開源＋閉源頂尖 LLM，最終端做結果合成與優化。
• 超大上下文與輸出：262,144 tokens context、單次最大輸出 131,072 tokens（市場上極為罕見）。
• 原生多模態：支援圖像輸入，可直接對 UI 設計稿截圖做程式碼逆向生成。
• 官方定價：$2.5 / $7.5（每百萬 token，input/output）。
• 官方跑分（pareto-evals 框架）：DeepSWE 74、MMMU-Pro 78、Terminal-Bench 4.0 51、ArXivMath 88、HLE 49——DeepSWE 的真實 GitHub bug 修復分是它在 Cursor 社群爆紅的主因。
• 第三方現況：Artificial Analysis 尚未收錄；因為後台基礎模型可能隨時調整，延遲/吞吐量還需要大量重複測試才能定性。

首日燒掉超過 20 億 token、免費公測只放兩天就揭曉轉收費——社群普遍解讀為一場成功的病毒式行銷：隱身名字＋免費額度吸引最挑剔的 Cursor/Cline 重度開發者幫忙壓力測試，熱度起來立刻把話題轉成付費客戶。而「不公佈參數量」也很好解釋：它根本沒有傳統意義上的單一參數量——路由與合成配方就是核心商業資產，說破等於讓別人照著重現。

⚠️ 以上資訊整理自社群討論記錄（36kr、Sina Tech、aiposthub、OrcaRouter、benchlm 等），揭曉細節以官方為準；獨立第三方評測尚未出爐，跑分先當參考。

「多源並行 → 差異盲審 → 帕累托最優合成」——怎麼這麼眼熟？

Pareto 的核心機制被描述為：多模型並行推理 → 終端交叉比對與文本合成，逼近 Pareto Frontier。看到這裡我愣了一下：這不就是我们 m-a-s 的 synthesize 模式嗎？兩顆模型並行作答、第三節點融合優點——連「Pareto 最優」這個詞都用上了。

💡 概念同源，但工程層次不同

比較維度	m-a-s（我們）	Unbiased Pareto
所在層次	應用層 workflow 框架：你明確指定誰當 Synthesizer、誰當 Critic，prompt 流程與中間狀態完全透明	模型/SaaS 層黑盒：多模型調度＋合成打包成單一 API 節點，後台路由矩陣自動決定
運作機制	結構化管線：agent 之間有明確的對話、審查、修正邊界（Critic 給 Refine 意見）	大規模並行＋權重融合：token 級別或文本區塊上的動態交叉比對與合成
成本與控制	自己管理各 API 的 token 消耗，或用本地硬體（128GB unified memory 設備跑開源模型）	平台做批次聚合與快取支撐 131K 輸出；使用者只看到單一計價
透明度	每個階段的產出都存檔可查、可復用	完全黑盒，基礎模型組合可能隨時調整

簡單說：Pareto 把我們這種「多模組協作逼近最佳解」的觀念封裝下沉到模型端，換來的是使用者零設定；代價是失去對每個階段的控制與可見性。我們的優勢恰恰在反面——本地、可審計、中間產物全部留痕。

溯源：m-a-s 從哪裡來 m-a-s 的起點是我 mora.tw 上的那篇開發筆記 兩顆本地 LLM 協同作業實測：Muse-Glimmer × Qwen3.8（2026-08-16）：meta 和 alibaba 各出一顆適合 local deployment 的模型，與其二選一不如讓它們分工。當時在 GB10（121GB unified memory）上用 llama.cpp 同時常駐 Muse-Glimmer-30B（:8080）與 Qwen3.8-27B（:8084），實作出三種協作模式——synthesize（並行生成＋融合大腦）、critique（互審，可 --reverse）、pipeline（JSON 規格→實作）——跑了四輪真實任務逐一評估程式碼品質（8.5 / 8.5 / 7 / 9），得出三個發現：分工是真的、審查方向很重要、工程細節決定成敗（第一輪 synthesize 就是敗在 max_tokens=4096 截斷，調到 16384 加截斷偵測後才完整）。那篇筆記的「待做」清單裡寫著：pipeline 加第三階段融合總檢、輸出自動過編譯檢查——而這次 Union Alpha 事件催生的 pareto 模式，正好是沿著同一條路往前走了一步。

本次實作成果：m-a-s 長出第四種模式 pareto

受 Pareto 機制啟發（社群討論裡還給了一套「評審與合成」prompt 模板設計），這次把 m-a-s 從「雙模型管線」升級為多候選＋結構化盲審＋帕累托融合，並順手補了幾個工程缺口：

                 ┌──> 候選 1（著重正確性/邊界） ──┐
任務 prompt ─────┤                                ├──> Critic 盲審（嚴格 JSON 報告）
                 └──> 候選 2（著重簡潔/可讀）  ──┘            │
                                                               v
                   最終成果 <── 融合節點依報告做帕累托最優合成

1. 並行生成：N 個候選（[pareto].candidates，預設 2）以不同著重方向（[pareto].emphases 可自訂）並行作答，候選在 [qwen]/[muse] 端點間交替——本地、雲端、混搭都行。
2. 盲審：Critic 不給標準答案，只輸出結構化 JSON 報告（各候選 pros / cons / 邊界處理、核心差異、建議融合策略），存 *-critic-report.md；解析失敗自動糾正重試一次，再不行才降級用原始文字。
3. 帕累托合成：融合節點依報告截長補短、消除所有 cons、禁止拼湊感。
4. 容錯（soft deadline）：每個候選獨立逾時（candidate_timeout，預設 900s），失敗/逾時只跳過該候選，其餘照常走完；全部失敗才中斷。所有 LLM 呼叫帶指數退避重試（5s/15s），最終失敗丟明確的 LLMCallError——不再像以前把錯誤字串當內容混進下游。
5. 其他：--config / MAS_CONFIG 支援多設定檔、設定檔驗證給出明確錯誤訊息；server 模式新增 mas/pareto model（流水線失敗回 502）。

本機實測：thinking 吃掉 budget 的教訓

在 DGX Spark 上用 Qwen3.8-27B-NVFP4-MTP（llama.cpp :8080，單模型三角色）跑內建 Flutter demo 任務，第一輪就踩到一個有意思的坑：

階段	Run 1（thinking 開）	Run 2（enable_thinking=false）
候選並行生成	候選 1 空輸出（1067s，reasoning 吃光 16K max_tokens）；候選 2 OK	兩候選皆產出：14969 / 2180 chars（137s / 65s）
Critic 盲審	合格 JSON ✓（連空候選都正確標註「未附實作，無法驗證，不建議直接採用」）	合格 JSON ✓，融合策略具體到逐項修正
帕累托合成	空輸出 ✗	完整 14K Flutter + Riverpod 實作 ✓
總耗時	2117s（35 min）	283s（4.7 min）

⚠️ 踩坑：thinking 模型在長任務上會把 max_tokens 全燒在 reasoning，content 回傳空字串 我們 config.toml 早給 SGLang :8888 端點加過 chat_template_kwargs = { enable_thinking = false }（註解寫得很清楚），但 llama.cpp :8080 端同樣有此行為——Run 1 的候選 1 與合成節點都中招。補上 kwarg 後 Run 2 全綠，總耗時還從 35 分鐘掉到 4.7 分鐘。已把 enable_thinking=false 補進本機 config 的 :8080 兩個區段。用 Qwen3.x 系列當 m-a-s 節點的人，記得檢查你的端點是否也需要這一行。

Run 2 的合成結果值得誇一下：最終程式碼的「整合說明」逐條引用了 Critic 報告——「架構採用候選 1（Notifier + 結構化 LogEntry）」「消除候選 1 的靜態單例風險」「避免候選 2 中 UI 層直接操作 Logger 的耦合」——這正是設計目標：融合不是複製貼上，而是依審查報告做取捨。

m-a-s 的可能進展

Pareto 的存在證明「多模型合成」這條路有商業價值；對開源框架來說，接下來可以走的方向：

• 審查閉環：review → repair → re-review 的多輪迴路（目前 pareto 是單輪盲審），讓 Critic 對融合結果再驗一次。
• 編譯/分析閘門：把上篇筆記的待辦補上——輸出自動過 flutter analyze / py_compile，pareto 模式天然多一個「候選誰能編譯」的客觀評選維度。
• 更細粒度的融合：目前是整段文本級融合；往 token/區塊級 diff 合併走，才能真正逼近 Pareto 那種「交叉比對後組裝」。
• 成本與快取：候選預算管理、相同子任務結果快取——Pareto 靠平台端聚合快取撐 131K 輸出，本地版可以用自己的 cache 層做到小範圍版本。
• 自己的 evals：Unbiased 用 pareto-evals 公開跑分；m-a-s 也可以建一個小的固定任務集（四輪實測的任務就是現成素材），追蹤「換模型 / 換 prompt」對融合品質的影響，讓調參有依據而不是憑感覺。
• N>2 與動態路由：候選數、著重方向依任務複雜度動態決定——這一步走遠了，就變成我們自己的小型「路由矩陣」了。
• 多模態輸入：UI 截圖 → 程式碼（Pareto 主打的能力之一），對 m-a-s 來說就是把候選的輸入從純文字擴到 image input。

想試試？

整套框架已開源並推送最新一版（commit 1c25030）：

github.com/alanpaul1969/multi-agent-synthesizer

pip install -r requirements.txt
cp config.example.toml config.toml   # 填入你的端點（本地 llama.cpp/Ollama/LM Studio/vLLM，或雲端 OpenAI/Groq/OpenRouter/DeepSeek，任意混搭）
python3 synthesizer.py --mode pareto "你的任務"

四種模式：synthesize（並行＋融合）、critique（互審，可 --reverse）、pipeline（JSON 規格→實作）、pareto（多候選＋盲審＋帕累托融合）。也可以整條流水線包成 OpenAI 相容 endpoint 給任何 agent 直接掛：

base_url = http://localhost:8090/v1
model    = mas/synthesize | mas/critique | mas/critique-reverse | mas/pipeline | mas/pareto

Pareto 把這個觀念做成了黑盒 SaaS；m-a-s 把它留在你手上——每個階段的產出都留痕、可審計、可復用。本地模型火力雖不如雲端旗艦，但「分工＋互審」確實補掉了單模型的盲點（上篇四輪實測的結論至今成立），而且審查與修正可以免費無限跑、資料不出機器。

💡 兩顆模型同時常駐約需 34–36GB unified memory/VRAM；不足時把 [qwen] 與 [muse] 指向同一顆模型、只用不同 system prompt 分角色（本次實測就是這樣跑的），模式依然有效。

參考

• m-a-s 原始開發筆記：兩顆本地 LLM 協同作業實測：Muse-Glimmer × Qwen3.8（2026-08-16）
• m-a-s repo：github.com/alanpaul1969/multi-agent-synthesizer
• Union Alpha / Unbiased Pareto 社群資料：OpenRouter stealth/union-alpha、36kr 報導、Sina Tech、aiposthub 深入分析、OrcaRouter 發布追蹤、benchlm 模型卡

---

📺 本文參考來源

社群討論記錄（OpenRouter stealth/union-alpha 揭曉事件）；m-a-s repo commit 1c25030；本機實測（DGX Spark，Qwen3.8-27B-NVFP4-MTP @ :8080）