AI tools
SMRA — VibeThinker-3B Reasoning Amplifier
A local research system testing whether a 3B BF16 mathematics model can improve through independent sampling, deterministic verification, and adaptive test-time compute.
Can a small model reason better as a system?
SMRA, or Small Model Reasoning Amplifier, is a local research project built around WeiboAI/VibeThinker-3B. It asks whether a 3B mathematics model can produce better final answers under a fixed compute budget by using independent solution paths, deterministic checks, error-driven retries, key-claim review, and adaptive allocation of additional attempts.
The project does not claim that the underlying 3B model becomes equivalent to a frontier model. Its subject is system-level performance: how far careful inference orchestration and verification can raise the quality of a fixed local model on specific, verifiable mathematics tasks.
A complete local experiment environment
The current system runs the official VibeThinker-3B revision in BF16 through MLX on a 24GB M4 MacBook Air. One model instance stays resident in memory and serves up to two independent sequences; a FIFO scheduler queues extra requests and immediately refills a slot when either active sequence finishes.
A local FastAPI service manages runs, cancellation, health state, SSE token events, and JSONL records. The React interface and Electron desktop app expose separate Chats, live candidate output, verification state, run history, model settings, and diagnostics. The service binds only to localhost, and every new problem starts in a clean Chat without inheriting another problem or candidate’s context.
From a frozen baseline to adaptive reasoning
The experiment is designed as a staged ladder. S0 is one unassisted BF16 answer per problem. S1 adds three independent paths and majority selection. S2 introduces deterministic checks such as symbolic equivalence, substitution, finite enumeration, and boundary validation. S3 adds retries directed by detected error types, while S4 and S5 introduce Lite-CLR key-claim challenges and an adaptive controller that can expand from three to five or seven candidates.
The current application exposes the implemented S0 and S1 paths. S2–S5 remain later research stages and will only be reported after their rules, prompts, seeds, and budgets are frozen. This keeps planned enhancement methods separate from capabilities that have already passed engineering validation.
Reproducibility before results
The v0 BF16 baseline was frozen on July 16, 2026 with a fixed model revision, prompt hash, generation settings, seed list, dataset manifest, and Git tags. The runtime uses a 131,072-token context limit and a 65,536-token output ceiling, while recording prompts, raw outputs, token counts, finish reasons, latency, memory, swap, verifier results, and source commit.
The main benchmark is the blind Frontier Text-20 set. Its answer key is kept outside the model-accessible project tree and is used only by the scoring bridge. The Mixed-20 set remains frozen for a later visual and proof track rather than being silently converted into text for a model without image input.
Current status
The local API, real MLX model adapter, continuous two-way scheduling, SSE streaming, run logging, batch evaluation bridge, Chat interface, settings, diagnostics, documentation, and desktop packaging are working. The v0 engineering acceptance has passed, including real-model output, concurrent generation, FIFO queuing, cancellation, cleanup, and dynamic slot refill.
Formal Frontier Text-20 results are still pending and are intentionally not shown as completed. The next milestone is to finish the frozen baseline evaluation, review its records, and then implement the verification and adaptive stages without changing the baseline after seeing the answers.