Why Five Small Models Teamed Up Can Beat a Large Model: Lessons from Memdoor
Memdoor's team of five Qwen3.8-27B models beat Fable 5, sparking discussion on multi-agent collaboration and compute economics.
A hot Reddit post introduced the Memdoor project: a team of five Qwen3.8-27B models that defeated the larger Fable 5 on LiveCodeBench Hard, confirming the view that "it's how you use the model, not the model itself." Community discussion focused on the difference between parallel multi-agent teams and sequential "implement-review" loops, noting they work through different mechanisms—the former relies on perspective redundancy and voting, the latter on iterative refinement—but no public benchmark currently quantifies which is better. Hardware constraints are the main reason individual developers favor sequential approaches, while Memdoor demonstrates the potential feasibility of single-machine multi-model collaboration. The post didn't disclose collaboration mechanisms, inference costs, or specific scores, so the conclusions still require reproducible experiments for validation.
Starting from a Hot Reddit Post: Small Models "Teaming Up" for a Comeback
A recent post on Reddit sparked considerable discussion: a project called Memdoor formed a team of five Qwen3.8-27B models that defeated Fable 5 on LiveCodeBench Hard. The post itself didn't elaborate on technical details, but one comment nailed the key point: "It's always how you use the model, not the model itself."
The post was recommended by the community Discord, and the author even received a special badge—indicating it struck a chord with many developers: under limited compute, can coding capability be improved through architectural design rather than parameter scaling?
Multi-Agent Collaboration: An Approach That Doesn't Rely on Parameter Count
Memdoor's approach isn't complicated: have multiple medium-scale models work in parallel as a team to jointly solve the same programming problem. Qwen3.8-27B ranks mid-to-upper among single models, but five such models working together surpassed the larger Fable 5 on a high-difficulty benchmark like LiveCodeBench Hard.
The consensus in the comments is that this "swarm intelligence" route may be the next wave. One user put it bluntly: "Swarm is the next frontier. People selling their compute to run Agent swarms." This hints at a new compute economy: rather than buying a top-tier GPU to run one large model, rent multiple medium-compute resources to run a swarm of small models.
LiveCodeBench is a benchmark specifically designed to evaluate large models' coding capabilities, with problems sourced from real programming competition platforms (such as LeetCode, Codeforces, etc.) and continuously updated to avoid data contamination. The Hard subset typically contains problems with high algorithmic complexity and stringent edge cases, demanding extremely high reasoning depth and code correctness from models. Fable 5 is a model that performs strongly on this benchmark (specific parameters undisclosed), often used as a reference baseline. Memdoor surpassing Fable 5 on the Hard subset means multi-model collaboration can produce measurable gains even on the most challenging programming tasks—not just "stacking numbers" on easy problems.
Core Debate: Parallel Teams vs. Sequential Review Loops
The most valuable discussion under the post came from a developer's serious question: is there a measurable performance difference between parallel multiple AI agents and a sequential "implement-review" loop (automatically iterating until no significant issues remain)? He mentioned he'd been using the latter with Qwen 27B, because he didn't want to invest in hardware for multiple parallel sessions, and the quality had already approached or even exceeded Sonnet level.
Another user chimed in: "How is 5 in parallel different from 5 in a row." This is actually a classic problem in distributed systems: parallelism brings redundancy and voting from independent perspectives, while serialization brings iterative refinement. Both can improve quality, but through different mechanisms.
Currently there's no recognized benchmark in the community to quantify this difference. No one in the discussion provided concrete data either—just empirical judgments. This means that while Memdoor's results are impressive, whether "parallel teams" are generally superior to "sequential loops" remains an open question.
The "implement-review" loop is a common agent workflow: one model generates code implementations, another (or the same) model plays the reviewer, pointing out flaws and triggering revisions, iterating until the reviewer no longer finds significant issues. It's essentially a serial refinement process, where each round builds on the previous round's output. A parallel team, by contrast, has multiple agents independently solving the same problem simultaneously, then selecting the best solution through voting, debate, or answer aggregation. The former leverages iterative depth; the latter leverages perspective diversity. In distributed systems theory, this resembles the two fault-tolerance strategies of "retry and refinement" versus "redundancy and consensus," which differ fundamentally in cost structure and benefit curves.
Practical Choices Under Compute Constraints
A recurring real-world factor in the discussion is hardware. The developer using the sequential loop explicitly said he "won't invest in hardware to support multiple parallel sessions" and can only run on a single card. This represents the situation of many individual developers and small-to-medium teams: no data center, only one GPU to work with.
Memdoor's significance lies in demonstrating a potentially viable path for single-machine multi-model scenarios. If five 27B models can run on consumer-grade hardware through reasonable scheduling and communication and achieve results surpassing large models, that would be a huge liberation for the community. But the post doesn't specify the hardware configuration or inference costs, which is one of the information gaps.
Running multiple 27B-parameter models on consumer-grade hardware faces dual pressure on VRAM and throughput. Estimated at FP16 precision, a single 27B model requires about 54GB of VRAM just for weights, and five parallel instances far exceed the capacity of a single consumer-grade GPU (typically 24GB or 48GB). Practical solutions usually rely on quantization (e.g., 4-bit quantization can compress a single model's weights to about 14GB), sharing underlying weights across models, or sequential scheduling rather than true simultaneous residency. Therefore, the single-machine implementation of "five models teaming up" is likely not five complete copies inferring simultaneously, but rather time-sharing reuse or multiple experts after parameter-efficient fine-tuning. The post doesn't disclose these details, leaving its hardware feasibility still in question.
The Real Question Behind the Humor: Model Scale Is No Longer the Only Yardstick
There are plenty of jokes in the comments—analogies about "model size isn't everything," quips about AI girlfriends. But behind the humor is a serious trend: model capability is shifting from "parameter scale" to "how it's used." The same batch of Qwen3.8-27B models, used individually, might only be mid-tier, but as a team they can defeat the larger Fable 5—showing that the leverage of architectural design and collaboration strategies may be underestimated.
For developers, this means you don't have to blindly pursue the largest and strongest single model; instead, you can think about how to use multiple medium models with appropriate collaboration protocols to approach or even surpass top-tier model performance. Of course, this requires more public benchmarks and reproducible experiments to verify.
Open Questions
Memdoor's post only gives conclusions, not methodological details: how do the five models divide work? How are answers aggregated? Is it voting, debate, or layering? What are the specific scores on LiveCodeBench Hard? All this information is missing. No one in the comments supplemented it either.
Furthermore, does the inference cost of parallel teams increase proportionally? If five models in parallel means 5x compute, does the cost-effectiveness still hold? Sequential loops are slower but may be more resource-efficient. These questions were all raised in the discussion but remain unanswered.
For developers focused on multi-agent systems, Memdoor is a signal worth tracking, but it's currently more of an "existence proof" than a reproducible solution. What's needed next is a public technical report and benchmark comparisons.
Related articles
VERS: Editing Activation Explanations to Halve Reasoning Model Tokens
VERS guides reasoning models by editing activation explanations, cutting 45.8% of tokens on GSM8K with only a 0.82 pp accuracy drop and transferring to larger models, but losing accuracy on competition problems.
Finding Errors Is Not Enough: Selective Model Escalation for Entity-Targeted Sentiment Analysis
This study explores selective model escalation for entity-targeted sentiment analysis, comparing data collection ordering, uncertainty-driven re-examination, and model routing—finding that minority-class priority only helps at very small data volumes, the oracle upper bound far exceeds actual gains, and escalation must be tailored to each dataset.
WAS-PO: Using Whitened Advantages to Solve the Correlation Trap in Multi-Reward Reinforcement Learning
WAS-PO paper proposes whitening advantages to correct correlation bias in multi-reward RL: when rewards are correlated, naive weighted summation effectively applies Σ^{1/2}w instead of w. Experiments show training reward improves steadily, but held-out accuracy does not improve in sync, and under two rewards it actually falls behind.