27B开源模型组击败1.6万亿参数旗舰：成本降至1/60

01 | 每个工程团队都熟悉的场景

晚上 11 点，发版前夜。一个有着八年历史的代码仓库。一个悬而未决三个月的问题。你把它交给手上最贵的云端模型，看着它开始工作——读代码、改代码、跑测试、报错、再改、再报错。到第 9 轮，它把代码回滚到了第 3 轮的样子。到第 14 轮，它又回到那里了。模型陷入了死循环。计费表却在继续跑。Token 不断燃烧，上下文不断膨胀，问题还在原地踏步。

这个场景在 AI 编程从演示走向生产的过程中反复上演。看我们自己统计的数据，Agent 任务中很大一部分失败，并不是模型"不知道怎么解决"——而是模型陷入死循环，身边却没有人来推它一把：在原地打转，重复同样的操作，越过上下文限制，最终超时。

自六月以来，整个行业从多个方向同时趋向于同一个答案：OpenRouter 推出了 Fusion，让多个模型独立作答后再合并成最优解；Hermes 将 Mixture of Agents 变成了官方功能；Cursor 用一千多个 Agent 重写了整个 SQLite。一条单个模型走不完的路，一组模型往往能走完。

但这引出了一个显而易见的问题：组建一组模型，是否意味着要组建一个 GPU 集群、消耗大量 Token？

在过去六个月里，我们对这个问题给出了自己的答案，它有点反直觉：Fusion-MOA。在一台 GPU 服务器上运行，以一个 27B 开源模型为主、几个同伴模型按需"咨询"，它在真实终端工程任务上达到了 50% 的通过率——超过了 2950 亿参数的云端旗舰模型，更比 1.6 万亿参数巨无霸高出 15 个百分点，而且消耗的 Token 仅为两者的零头。以下是完整的数据解析。

02 | "选最强的模型"从来不是真正的策略

哈佛商学院和 BCG 联合开展了一项研究，产生了一个著名的概念：Jagged Frontier（参差不齐的前沿）。核心观点是：AI 模型的能力不是一条平滑的曲线——而是一条充满峰谷的锯齿状悬崖。同一个模型能在一个问题上表现出色，在下一个问题上却可能还不如一个实习生。

在工程工作中，这一点体现得尤为尖锐：

• 某些模型擅长从遗留代码中捕捉"潜台词"；
• 某些模型擅长从堆积如山的错误日志中嗅出根本原因；
• 某些模型擅长推理某个改动是否会在下游引发其他问题。

Fixing a real issue usually requires all three skills at once. Expecting one model to be the best at every step of that is like expecting one engineer to simultaneously be the company's best architect, best debugger, and best tester — not because they aren't good, but because the ask itself doesn't make sense.

So Fusion-MOA's starting premise comes down to one line: Stop competing on whose model is strongest. Compete on who organizes their models most intelligently.

03 | Fusion-MOA 实际做了什么：给 AI 团队定义角色，而不是简单堆人头

Multi-model systems tend to fall into a trap: treating "number of models" as a stand-in for collaborative capability. Pioneer R1 takes a different definition — a model only counts as a real unit in the system once it has a clearly defined role, service endpoint, execution policy, version, and traceable log.

The i-th model unit is written as:

Cellᵢ = (modelᵢ, roleᵢ, endpointᵢ, policyᵢ, versionᵢ, traceᵢ)

The full set of standing units forms fleet F. Rather than searching for arbitrary models on the fly, each business Profile p binds to a fixed participant set Cₚ, a communication policy Mₚ, a finalization policy Vₚ, and a permission policy Aₚ:

Cₚ⊆F, Profileₚ = (Cₚ, Mₚ, Vₚ, Aₚ)

The current general-purpose Profile consists of one Executor E and three read-only Analysts A₁, A₂, A₃:

C_g = {E, A₁, A₂, A₃}

These roles map to different system-level permissions — not to different tones of voice. The Client or Agent owns the external task state and is responsible for sending messages and invoking tools. The Gateway validates interface contracts, generates call-tracing IDs, and computes a deterministic "stall" signal — but it never executes tools itself. The Executor E owns the main thread and is the only party allowed to author text, invoke tools, or set the action plan. The three Analysts each read the same immutable evidence snapshot, work independently of one another, and can only return structured Packets. A verification-and-selection module checks format, citations, deadlines, and duplication, and surfaces at most two Packets. An operations control plane handles isolation, qualification checks, promotion, and rollback for candidate units — but sits entirely outside the action-permission chain for live requests.

The relationships between these roles boil down to three boundaries: a participation boundary — who can enter this Profile; an information boundary — what each participant can see and return; and a permission boundary — who can modify state, call tools, or submit the final result. Multi-model collaboration only becomes auditable once all three boundaries are clearly defined.

This also explains why adding more models doesn't automatically add more capability. If every model can read and write the same state, overwrite each other's workspace, or execute tools directly, the system just accumulates conflicts and recovery costs. Pioneer R1's approach: ordinary requests take the shortest path, a bounded consultation only kicks in once the system detects a deterministic stall, and there is always exactly one author of the final action.

Fusion-MoA Pioneer R1 three-plane architecture

For your application, nothing about how you call it changes — swap GPT for Fusion-MOA the same way you'd call any model, by changing one base_url. Not a single line of application code needs to be rewritten. All the complexity of multi-model coordination stays behind the interface, invisible and out of your way.

04 | 谁在背后支撑

Building on years of accumulated depth in intelligent operating systems, Thundersoft（中科创达）has folded its chip- and AI-algorithm capabilities directly into its AI data center and model-serving platform. Its NovaStack team has now shipped a new-generation AI agent and token substrate: FusionMOA.

FusionMOA isn't just a model framework — it's an intelligent hub that turns the strengths of heterogeneous models into deliverable, executable outcomes. It moves past the ceiling of any single model by deeply combining reinforcement learning with a multi-agent coordination mechanism. "Fusion" here isn't a simple weighted vote — it's a deep logical merge across multiple models' capabilities, candidate paths, and verifiable evidence, so every decision stays traceable. "MoA" (Mixture of Agents) gives the system dynamic orchestration: it assembles the most fitting combination of agents in real time based on task structure, instead of running every model in full, redundantly, every time.

Built on FusionMOA, the goal is to turn a shifting, complex landscape of model capabilities into precise, verifiable, deliverable business value — a solid foundation for putting AI applications into production.

05 | 数据表现：27B 阵容实际上对标谁

Test setup, stated up front: every system runs the same problem set, the same agent framework, and the same official grader. The only variable is whether the model works alone or as a team.

Round one: Terminal-Bench 2.1 (real terminal engineering tasks, 3-hour limit per problem)

Three numbers worth sitting with:

• 50% vs. 40%: the exact same 27B model solved 25% more problems purely from a change in how it's organized
• 50% vs. 35%: a local combination with a fraction of its parameter count outscored the 1.6-trillion-parameter giant by 15 points
• Fusion-MOA also uniquely cracked two problems — kv-store-grpc and password-recovery — that neither cloud flagship solved. Not through brute force, but because someone else stepped in the moment it got stuck.

Round two: HMMT math competition problems (graded by sympy's official equivalence checker)

A merged group of 20B–30B open-source models matched a 744B-class flagship, and beat the best solo score (6/10) by a full two problems. The process itself was telling: on one hard problem, all three models got it wrong in round one; after one round of anonymous cross-discussion, all three self-corrected to the right answer. Collaboration producing an actual chemistry effect isn't just a nice phrase — it happened.

Round three: SWE-bench Verified (real GitHub issue fixes, in progress)

Among the problems graded so far, Fusion-MOA's pass rate is 11/14 — including two that the 295-billion-parameter flagship HY3 couldn't fix.

On the cost side, it's a different story entirely. Across the same 20 terminal engineering tasks, input token consumption:

• LongCat-2.0: 266 million tokens
• HY3: 65.27 million tokens
• Fusion-MOA: 14.27 million tokens — 1/18 of the first figure

And it all runs on our own hardware — no metered billing, no rate limits, no surprise invoices. Thinking is expensive. Re-running the same dead end shouldn't be. That's the whole point of on-demand collaboration: let one model handle 98% of the road, and bring in a group only for the last 2% that's actually hard.

06 | 很多系统能刷出好 benchmark。真正能跑在生产环境的少之又少。

Beyond the scores, the engineering work behind Fusion-MOA is arguably where the real commercial value sits:

• Fast. MTP speculative decoding lifts the core model's decoding speed from 16 tokens/s to 62 tokens/s — nearly 4x. Prefix-cache hit rate holds steady at 90–98%, so long-running tasks get smoother, not slower.
• Long. The whole system supports 128K context — enough room for the giant files, sprawling logs, and hundred-round tool-call histories that live in old repositories.
• Stable. A 3,600-second continuous stress test ran 906 calls with zero restarts. Dropped connections cancel automatically, timeouts fail safe automatically, and any non-compliant advisor output automatically falls back to a single-model path. At every point, the system is only allowed to degrade gracefully — never to fail in an interesting way.
• Ready for domestic hardware. The production system runs on MetaX (沐曦) GPUs made in China, and has also passed full validation on AMD's W7900D platform. No dependence on export-controlled hardware, no NVLink required — one GPU per model, with only text passed between cards. Domestic, consumer-grade, or data-center-grade — all three deployment paths work.

07 | 这东西实际上给谁用

Back to the opening scene. We think Fusion-MOA fits best where a single model genuinely can't get the job done, in three categories:

① The night-shift doctor for legacy systems

Old issues that have sat in the backlog for months, ancestral code nobody dares touch — this is exactly where a single model is most likely to spin into a dead loop, and exactly where on-demand consultation pays off most. Submit a batch of issues at night, get back a batch of patches by morning.

② The review board for hard technical calls

Tech selection, architecture review, migration plans — these tasks inherently need multiple angles: performance, cost, risk. Ask one model to weigh all three at once and you usually get an answer that "sounds right" without being rigorous. Let three independent perspectives reason separately, then have the lead synthesize a conclusion — the result holds up much better.

③ The strike team for math and algorithm problems

Competition problems, proofs, algorithm optimization — an 8/10 on HMMT matching a 744B flagship already makes the point: when models' strengths complement each other, the merged result can reach a ceiling no single model can touch alone.

More importantly, all three categories share one commercial trait: They're worth using a good model for — but not worth paying flagship prices on every single call.

08 | 结语

For the past two years, the competitive logic in large models has mostly been "bigger": more parameters, more GPUs, pricier APIs. But the reality of putting this into production is simpler: nobody's budget is unlimited, and no task is actually worth unlimited money.

Fusion-MOA is proof of a different path — taking a set of open-source models that are affordable, runnable, and tangible, and binding them together with an "executor + advisors + stall detection" structure:

• On capability, it matches or beats cloud flagships with 10x, even 60x its parameter count;
• On cost, token consumption is a fraction of theirs, running entirely on our own hardware;
• On integration, it's one OpenAI-compatible endpoint — zero lines of code to change.

The competitive edge of the future won't come from how large your model is. It'll come from how well you organize your AI.

Fusion-MOA is now open for enterprise beta testing and private-deployment evaluation. If your team is dealing with agents stuck in dead loops, flagship-model bills spiraling out of control, or data that can't leave your internal network — we'd like to talk. Reply "Fusion" on our official account to get the beta application process and the technical whitepaper.

Fusion-MOA v0.9 · single 8-GPU node · OpenAI-compatible · ready for domestic hardware

Collective intelligence, beyond any single model's ceiling.