# When One Model Gets Stuck, Let It “Hold a Meeting”: A 27B Team Matches a 1.6-Trillion-Parameter Giant, at a Fraction of the Token Cost > Source: > Published: 2026-08-12 06:00:57+00:00 Summary: No stacking more parameters, no burning more cash — an open-source model “technical committee” beats a 1.6T cloud flagship by 15 percentage points on real engineering tasks. 01 | A Scene Every Dev Team Has Lived Through 11 PM, the night before a release deadline. An eight-year-old legacy repo. An issue that's been open for three months. You hand the task to the most expensive cloud model you have and watch it get to work: read the code, edit the code, run the tests, hit an error, edit again, error again... On round 9, it reverts the same block of code back to what it looked like on round 3. On round 14, it reverts it again. It's stuck. But the billing isn't. Tokens keep burning, the context keeps growing, and the issue is still sitting there open. This scene keeps repeating itself across real-world AI coding deployments. Based on our own data: in agentic tasks, a substantial share of failures aren't because the model “can't” do something — they happen because the model gets stuck with no one to pull it out: spinning in circles, repeating the same actions, blowing through context, and eventually timing out. Since June this year, the industry has essentially converged on the same answer: OpenRouter launched Fusion, letting multiple models answer independently and then merging their outputs into the best solution; Hermes turned Mixture of Agents into an official feature; Cursor rewrote SQLite using a swarm of thousands of agents. A path that one model can't get through, a group of models can. But that raises a new question: does assembling a group of models mean you need a whole GPU cluster and a truckload of tokens? Over the past six months, we built our own answer to that — and it's counterintuitive: Fusion-MOA. On a single GPU server, with a 27B open-source model taking the lead and a few other models brought in for “consultations” as needed, we hit a 50% pass rate on real-world terminal engineering tasks — beating a 295-billion-parameter cloud flagship, and beating a 1.6-trillion-parameter giant by 15 percentage points. Token consumption is a small fraction of theirs. Let's break down exactly how. 02 | “Pick the Single Strongest Model” Is Already the Wrong Question Harvard Business School and BCG's joint research introduced a well-known concept: the Jagged Frontier. AI's capability boundary isn't a smooth curve — it's a cliff full of peaks and chasms. The same model can be a genius on one problem and worse than an intern on the next. Put in engineering terms, it gets even more brutal: ●Some models are great at reading between the lines of legacy code; ●Some models are great at sniffing out root causes in error logs; ●Some models are great at reasoning through whether a change will break something else. And fixing a real issue requires all three abilities — none of them optional. Expecting one model to be the best at every single step is like expecting one engineer to simultaneously be the company's best architect, best debugger, and best tester. It's not that they're not capable — the expectation itself is simply unreasonable. So Fusion-MOA's first principle comes down to one sentence: It's not about whose model is strongest — it's about who organizes the models the smartest. 03 | Fusion-MOA: Staffing an AI Team With Defined “Roles,” Not Just Adding “Headcount” Multi-model systems can easily treat “number of models” as a stand-in for collaboration capability. Pioneer R1 takes a different definition: a model only counts as a unit within the system once it has a clearly defined responsibility, service endpoint, execution policy, version, and traceable record. The i-th model unit is written as: Celli = (modeli, rolei, endpointi, policyi, versioni, tracei) The resident fleet is denoted F. Rather than searching for arbitrary models on the fly, each business Profile p is bound to a fixed participant set Cₚ, a communication policy Mₚ, a resolution 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 correspond to different system-level privileges, not different conversational styles. The Client or Agent holds the external task state and is responsible for sending messages and executing tools. The Gateway validates interface contracts, generates call-tracing IDs, and computes a deterministic stall-detection gate — but does not execute tools itself. The Executor E maintains the main thread and is the sole author of all text, tool calls, and action plans. The three Analysts read the same immutable evidence snapshot, operate independently of each other, and can only return structured Packets. A validation-and-selection module checks format, references, time limits, and duplication, returning at most two Packet IDs. An operations control plane handles isolation, qualification, promotion, and rollback of candidate units, and never enters the online request's action-permission chain. The relationships between roles can be summarized with three boundaries. The participation boundary answers “who may enter the current Profile”; the information boundary answers “what participants can see and what they can return”; the permission boundary answers “who can modify state, call tools, or submit the final result.” Only when all three boundaries are clearly defined can multi-model participation form auditable group collaboration. This structure also explains why adding more models doesn't automatically add capability. If every model reads different state, overwrites each other's workspace, or executes tools directly, the system just accumulates conflict and recovery costs. Pioneer R1 keeps ordinary requests on a short path and only triggers a bounded consultation after a deterministic stall is detected — always preserving a single author of action. Fig.: Fusion-MoA Pioneer R1 — three-plane architecture Whatever way your application currently calls GPT, it can call Fusion-MOA the same way — change one line, the base_url, no code refactor required. All the complexity of multi-model collaboration stays behind the interface. 04 | About the Team Drawing on its deep expertise in intelligent operating systems, ThunderSoft (中科创达) has fully embedded its core chip and AI algorithm capabilities into an AI data center and model-serving platform. Its NovaStack team brings together top R&D talent to deliver a next-generation AI Agent and token infrastructure: FusionMOA. FusionMOA is more than a model framework — it's the intelligent hub that connects the strengths of heterogeneous models to deliverable, executable results. It moves past the limits of a single model, deeply combining reinforcement learning for models with multi-agent collaboration mechanisms. Here, “Fusion” is never simple weighted voting — it's a deep logical fusion of multiple models' capabilities, candidate paths, and verifiable evidence, ensuring every decision step is traceable. “MoA” (Mixture of Agents) gives the system the intelligence to dynamically orchestrate, scheduling the best-fit combination of agents in real time based on task structure, and abandoning the inefficiency of running every model redundantly. Built on FusionMOA, we're focused on turning complex, ever-changing model capabilities into precise, verifiable, deliverable business value — providing a solid intelligent foundation for putting AI applications into production. 05 | Where the Rubber Meets the Road: What Does a 27B Team Match? First, the test methodology: every system runs the same set of tasks, the same agent framework, and the same official scorer — the only variable is “solo model” versus “team collaboration.” Round One: Terminal-Bench 2.1 (Real Terminal Engineering Tasks, 3-Hour Limit per Task) System Passed Pass rate Fusion-MOA (27B leading, local 8-GPU) 10/20 50% Cloud flagship HY3 (295B-parameter MoE) 9/20 45% Same 27B model, solo 8/20 40% LongCat-2.0 (1.6T-parameter MoE) 7/20 35% Three numbers are worth pausing on: 50% vs. 40%: the same 27B model solves 25% more problems once it's teamed up — that's the pure contribution of “organization.” 50% vs. 35%: the 1.6-trillion-parameter giant gets beaten by 15 percentage points by a local combination with a small fraction of a fraction of its parameter count. Fusion-MOA also exclusively solved kv-store-grpc and password-recovery — two problems neither cloud flagship managed to solve. Not through brute force, but because “when it got stuck, someone else stepped in with a different way of thinking.” Round Two: HMMT Math Competition Problems (Official sympy Equivalence Scoring) System Score Fusion (multi-model fusion) 8/10 GLM-5.2 (744B-class flagship) 8/10 LongCat-2.0 (1.6T) 7/10 Best single model (31B) 6/10 DeepSeek-V4-Flash 1/10 A fusion of open-source models in the 20B–30B range matched a 744B-class flagship, raising the best solo score (6/10) by a full two problems. What's more interesting is the process: on one hard problem, all three models got it wrong in the first round; after one round of anonymous cross-discussion, all three self-corrected to the right answer — the chemistry that comes from collaboration is real. Round Three: SWE-bench Verified (Real GitHub Issue Fixes, In Progress) Among the tasks that have completed official scoring so far, Fusion-MOA has a pass rate of 11/14, including two problems that even the 295-billion-parameter flagship HY3 couldn't fix. And the cost side of the story is a different dimension entirely. Running 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 — only 1/18th of the former And it's all running on our own servers: no metered billing, no rate limits, no surprise invoices. Thinking is expensive — but repeatedly thinking your way into the same dead end shouldn't be. That's the whole point of on-demand collaboration: 98% of the road, one model walks alone; the other 2% of tough spots, the team crosses together. 06 | Plenty of Systems Can Score Well on Benchmarks — Few Can Actually Go to Production Beyond the benchmark numbers, what Fusion-MOA does on the engineering side may be its most commercially relevant part: ●Fast. Thanks to MTP speculative decoding, the core model's decoding speed goes from 16 tokens/s to 62 tokens/s (nearly 4x); prefix cache hit rate holds steady at 90%–98%, and long tasks get smoother the longer they run. ●Long-context. The full system supports a 128K context window — large files in legacy repos, long logs, and tool-call histories running hundreds of turns all fit. ●Stable. In a 3,600-second continuous stress test with 906 calls, zero restarts. Dropped connections auto-cancel, timeouts auto-fallback, and any non-compliant advisor output automatically falls back to a single-model path — at every moment, the system is only ever allowed to “gracefully get simpler,” never to “fail in a fancy way.” ●Ready for domestic compute. The system currently runs in production on domestic MetaX GPUs, and has also completed full validation on the AMD W7900D platform. It doesn't depend on hardware subject to export restrictions and doesn't require NVLink — one card, one model, with only text passed between cards. Domestic hardware, consumer-grade hardware, and data-center-grade hardware are all viable paths. 07 | Who Is This System For? Back to the scene we opened with. We believe Fusion-MOA is the best fit for three kinds of work that “one model alone can't handle”: ① The “Night-Shift Doctor” for Legacy Systems Old issues that have sat in the backlog for months, ancestral code no one dares touch — exactly the territory where a single model is most prone to getting stuck in a loop, and exactly where on-demand consultation pays off the most. Submit a batch of issues at night, get a batch of patches back in the morning. ② The “Review Committee” for Complex Technical Decisions Technology selection, architecture review, migration plans — these tasks inherently need multiple perspectives: performance, cost, risk. Asking one model to weigh all of that at once tends to produce an answer that “looks right on the surface.” Letting three perspectives reason independently and then having a lead process synthesize them produces far more solid conclusions. ③ The “Tiger Team” for Math and Algorithm Challenges Competition problems, proofs, algorithm optimization — matching a 744B flagship at 8/10 on HMMT already proves the point: when several models have complementary strengths, fusion can reach a ceiling that no single model can reach alone. More importantly, these three kinds of work share one business trait: They're all worth using a good model for — but none of them are worth paying flagship prices for every single call. 08 | Closing Thoughts Over the past two years, the competitive logic in large models has been “bigger”: bigger parameter counts, more GPUs, pricier APIs. But the reality of putting this into production is: no one's budget is unlimited, and no task deserves an unlimited budget. What Fusion-MOA validates is a different path — taking a group of open-source models that are affordable, that you can actually run, that you can see and touch, and twisting them into a single rope through an organizational structure of “lead model + advisors + stall detection”: ●In capability, it matches or even beats cloud flagships with 10x, even 60x, the parameter count; ●In cost, token consumption is a fraction of theirs, and it runs on your own hardware; ●In integration, it's one OpenAI-compatible interface — no code changes required. Future competitiveness won't come from how big your model is — it will come from how strong your AI's “organizational capability” is. Fusion-MOA is currently open for enterprise pilot testing and private-deployment evaluation. If your team is dealing with any of “agents stuck in loops,” “flagship model bills spiraling out of control,” or “data that can't leave the internal network,” we'd love to talk. Reply “Fusion” on our WeChat official account to get the pilot application process and technical whitepaper. Fusion-MOA v0.9 · Single 8-GPU server · OpenAI-compatible · Ready for domestic compute Collective intelligence, beyond the limits of any single model.