Nanbeige4.1-3B: How a 3B model sustains 600 tool calls and beats 30B models

TL;DR: Nanbeige4.1-3B is a 3.93B parameter LLaMA-architecture model from Boss Zhipin that achieves strong reasoning, code generation, and agentic behavior in a single model. The paper’s key innovation is a 4-stage RL pipeline that ends with a gated time-complexity reward arxiv 2602.13367. It only rewards efficient code when all tests pass. The model sustains 600+ tool-call turns and beats Qwen3-30B-A3B on execution-based coding. At Q4_K_M it fits in ~2.5 GB, making it top local-first agent model available.

Key takeaways:

• Nanbeige4.1-3B uses a 4-stage training pipeline: SFT to Point-wise RL to Pair-wise RL to Code RL (correctness then time-complexity) to Agentic RL. Each stage targets a different failure mode.
• The gated time-complexity reward is the standout technique. It pushes the model from O(N log N) solutions toward O(N) by only activating the efficiency signal when code passes all test cases.
• Deep search at 3B is real. The model scores 69.9 on GAIA (text-only), matching Tongyi-DeepResearch-30B, using entity-relation graph random walks and turn-level supervision.
• At Q4_K_M quantization, the model is roughly 2.5 GB. A 16 GB Mac Mini can run it with practical context windows for local agent loops.
• On LiveCodeBench-Pro-Medium, Nanbeige4.1 scores 28.1, nearly 2x the 80B Qwen3-Next-A3B (14.3) and 8x Qwen3-30B-A3B (3.5). This isn’t incremental. It’s a regime change.
• The tradeoff: vocabulary is Chinese-heavy (166K tokens), chat template targets Chinese-first usage, and independent long-context evaluations are still pending.

What problem does this solve?

The first time I ran a 3B model in an agent loop, it worked for about five turns. Then it forgot which tool it had called. By turn 12, it was repeating the same search query with different phrasing. By turn 20, it had hallucinated an API response.

This is the standard failure mode of small models in agentic settings. The model doesn’t collapse because of capacity. It collapses because its training signal never included multi-turn interaction. Its training objective targeted a single correct answer, not sustained tool-use conversation.

Nanbeige4.1-3B doesn’t have this problem. It sustains 600 tool-call turns. It scores 69.9 on GAIA, matching specialized 30B research agents. It scores 83.8 on GPQA, higher than Qwen3-32B (68.4) and competitive with 80B models.

The paper documents how they built this. This post explains what they did, why each stage matters, and what it means for running capable agents on a 16 GB Mac Mini.

Where does Nanbeige4.1 come from?

Nanbeige4.1-3B comes from the Nanbeige LLM Lab at Boss Zhipin, a Chinese recruitment platform. It builds on their Nanbeige4-3B-Base released in December 2025 and their Nanbeige4-3B-Thinking-2511 reasoning model nanbeige4 tech report.

The base architecture is standard LLaMA:

Parameter	Value
Layers	32
Hidden size	2560
Attention heads	20
KV heads	4 (GQA)
Head dimension	128
MLP intermediate	10496 (SwiGLU)
Context length	262,144 (256K)
Vocabulary	166,144 tokens
Parameters (BF16)	3.93B
License	Apache 2.0

Two things stand out in the config. The RoPE theta is 70,000,000, which is the extended-context modification that lets the model handle 256K tokens without positional collapse. The 4 KV heads with 20 query heads uses Grouped Query Attention with a ratio of 5:1, aggressive compression for inference efficiency.

The 166K vocabulary is a double-edged sword. It’s large because the model handles Chinese and English. Chinese characters get efficient single-token encodings. English text may waste more tokens depending on content. If you run this model mainly in English, check your tokenization overhead.

What changed in the SFT phase?

The SFT phase is where many papers would stop. Nanbeige4.1 uses it as a foundation for what comes next.

Data mixture changes. Compared to Nanbeige4-3B-2511, they increased the proportion of code data and introduced harder problems in mathematics and general domains. The final SFT mixture at 256K context:

• Code: 27%
• Deep search: 26%
• STEM: 23%
• Tool-use: 13%
• General: 10%

This is an agent-first mix. Over half the training data (code + deep search + tool-use at 66%) targets agentic behavior, not question-answering alone.

Previous Nanbeige models used a two-stage curriculum: 32K then 64K. Nanbeige4.1 adds a third stage at 256K. The model needs training signal at that length to learn how to use it, not only support it at inference.

Context scaling stages:

1. 32K for standard training
2. 64K for extended reasoning
3. 256K for agentic and long-horizon scenarios

Solution refinement and CoT reconstruction. The paper scales up the number of refinement iterations in their Solution Refinement loop, creating stronger critique-revision cycles. They also train a better CoT Reconstruction model to generate cleaner reasoning traces from refined answers, removing the noisy intermediate steps that corrupt the training signal.

The SFT results. The improvement from Nanbeige4-3B-SFT to Nanbeige4.1-3B-SFT:

Benchmark	Before	After	Delta
LCB V6	45.5	62.0	+16.5
LCB Pro Medium	1.8	22.8	+21.0
HMMT Nov	60.7	74.3	+13.6
IMO-Answer-Bench	34.8	48.9	+14.1
Arena-Hard V2	45.5	60.2	+14.7

The SFT phase alone turns a mediocre 3B model into a strong one. The jump on LCB Pro Medium, from 1.8 to 22.8, comes from the data mixture change. But the paper acknowledges that SFT still has problems: repetition, redundant thinking, and formatting errors.

Stage 2: Point-wise RL. Stopping the model from talking in circles

After SFT, the model could solve problems but produced verbose, redundant, and sometimes repetitive responses. The paper calls it “degradation.” This happens when you train a model on long reasoning traces. It learns that longer is better.

The fix: a general reward model trained on human preference data, used as the training signal for GRPO deepseekmath.

The reward model scores each response on a single scale. The key finding: a reward model trained on broad human preference data naturally learns to penalize redundancy, repetition, and low readability, even without explicit training for those qualities.

Results after point-wise RL:

Arena-Hard V2 goes from 60.2 to 66.6. Hard-prompt subset improves from 46.1 to 54.1. But the concrete metric: overlong truncation on LiveCodeBench drops from 5.27% to 0.38%. The model stops writing beyond the output limit.

This stage does not make the model smarter. It makes the model usable. A model that produces correct but truncated code is worthless. A model that produces correct, concise code ships.

Stage 3: Pair-wise RL. Preference boundaries at 3B

Point-wise RL has a limitation. The reward model can tell you a response is good, but it can’t tell you why it’s better than the alternative.

Pair-wise RL fixes this by comparing response pairs from a strong model and a weak model. The same checklist filtering strategy from Nanbeige4 applies: generate pairs, filter for reliability, train a pairwise reward model that outputs a win/loss probability.

Swap-consistency regularizer. Position bias is a known problem in pairwise rewards. The model learns to favor the first or second response in the pair regardless of quality. The paper mitigates this with a regularizer that minimizes the MSE between the predicted reward difference and the negated reward difference for the swapped pair. If swapping the responses doesn’t flip the prediction, the model isn’t learning preference.

Results after pair-wise RL:

Benchmark	Point-wise	Pair-wise	Delta
Arena-Hard V2	66.6	73.8	+7.2
Multi-Challenge	47.7	55.1	+7.4
LCB V6	66.0	65.6	-0.4

Code takes a tiny hit (negative 0.4 on LCB V6). Alignment improves substantially. The tradeoff is explicit: pair-wise RL sharpens preference boundaries at a small cost to raw coding performance. The paper accepts this because the next stage recovers and exceeds the coding baseline.

Stage 4: Code RL. The head chef at the pass

This is the heart of the paper. The code RL stage has two sub-stages. The second one contains the innovation worth studying.

Stage 4a: Correctness

The model trains on code problems with a pass-rate reward: the fraction of test cases passed. This is standard. The model learns to produce solutions that work.

Results after Stage 4a: LCB V6 climbs from 65.6 (post pair-wise RL) to 71.2. Correctness reaches a ceiling where the model can solve common problems but uses whatever algorithmic approach comes first.

Stage 4b: Gated time-complexity reward

This is the head chef at the pass. In a restaurant kitchen, the head chef does not cook. They check every plate before it leaves. If the plate is wrong, it does not leave. If the plate is right, they decide whether it meets the standard.

The gated time-complexity reward does the same thing. It is a three-component signal:

R = R_format + R_correctness + R_time

But R_time only activates when PassRate = 1. Otherwise, the reward is only format + correctness.

if PassRate < 1:
    reward = format_score + correctness_score
else:
    reward = format_score + correctness_score + time_complexity_score

This design is the critical insight. If you reward time complexity before the solution passes tests, the model prioritizes efficiency over correctness, producing fast wrong answers. If you always reward time complexity equally with correctness, the model can’t distinguish between “my solution is correct but slow” and “my solution is wrong.”

The gate forces the model to learn in two phases: first correctness, then efficiency. The judge system provides online feedback by comparing the model’s predicted time complexity against a reference optimal bound. The model needs a correct solution that also meets the algorithmic standard.

Concrete examples from the paper.

The appendix shows three AtCoder problems with before/after code. Every pair follows the same pattern. The “before” solution is correct but uses a heavier algorithm. The “after” solution is correct and uses the optimal approach.

Kagamimochi (mochi stacking): Before uses binary search over the answer at O(N log N). After uses two-pointer greedy matching at O(N).

Twice Subsequence: Before builds a value-to-positions map with binary search at O(N + M log N). After uses two greedy linear scans at O(N).

Minimum Cost Sort: Before uses a heap-driven bubble sort that degrades to O(N^2 log N). After uses a Fenwick tree at O(N log N).

These are real AtCoder competitive programming problems. The model had to invent a different algorithm, not only refine the same approach. The gated reward doesn’t tell the model how to be more efficient. It creates the signal that makes efficiency worth exploring.

Results after Stage 4b:

LCB-V6 peak: 76.9. LCB-Pro-Easy: 81.4. LCB-Pro-Medium: 28.1. The medium subset is the hardest. These are problems that require algorithmic insight, not only code. The 28.1 score is nearly 2x the 80B Qwen3-Next-A3B (14.3) and 8x Qwen3-30B-A3B (3.5).

Stage 5: Agentic RL. The 600-turn cherry on top

The final stage is a lightweight agentic RL round that strengthens tool-use and search behavior. The paper does not detail this as thoroughly, but the results speak: Nanbeige4.1-3B sustains 600+ tool-call turns for deep search.

The deep search data pipeline enables this:

1. Entity-relation graph construction. Extract head entities from Wikipedia updated in the last six months for temporal relevance. Build a graph of entities and their relations.

2. Conditional random walks. Walk the graph to extract relational paths of predefined length. These paths become the skeleton for multi-hop questions.

3. Question synthesis. Feed the paths with temporal context into a strong LLM to generate complex multi-hop questions that require multiple search steps.

4. Trajectory synthesis. Multiple agent frameworks solve the same query, producing diverse reasoning paths. Map these into multi-turn tool-invocation sequences.

5. Turn-level judgment. A critic model evaluates each interaction step on three criteria: logical soundness, tool-call accuracy, and informational gain. Steps that fail any criterion get excluded from training or provide negative reward.

This is the pipeline that bridges the gap between 3B chat models and 100B+ research agents. The key is the turn-level supervision. Standard agent training uses trajectory-level reward, which is too sparse for 600-tool sequences. Turn-level judgment gives the model signal at every step.

The dataset is open-sourced as ToolMind-Web-QA on HuggingFace.

What the benchmarks mean

The paper evaluates across five categories. Here are the numbers that matter for local-first agents.

Code

Benchmark	Qwen3-4B	Qwen3-32B	Qwen3-30B-A3B	Qwen3-Next-80B-A3B	Nanbeige4.1-3B
LCB-V6	57.4	55.7	66.0	68.7	76.9
LCB-Pro-Easy	40.2	42.3	60.8	78.8	81.4
LCB-Pro-Medium	5.3	3.5	3.5	14.3	28.1

The LCB-Pro-Medium gap is the interesting result in the paper. At this difficulty level, larger models do not automatically win. The training recipe matters more than parameter count. The gated time-complexity reward creates a signal that other models do not get.

Deep search (agentic)

Benchmark	Qwen3-4B	Qwen3-32B	Qwen3-30B-A3B	Tongyi-DeepResearch-30B	Nanbeige4.1-3B
GAIA (text)	28.3	30.2	31.6	70.9	69.9
BrowseComp	1.6	3.2	1.6	43.4	19.1
SEAL-0	15.7	8.2	9.2	—	41.4
xBench-DeepSearch-05	34.0	39.0	25.0	75.0	75.0

On GAIA, Nanbeige4.1 matches Tongyi-DeepResearch-30B, a specialized research agent with 10x the parameters. On BrowseComp it trails significantly (19.1 vs 43.4), suggesting web browsing agents at 3B still struggle. But on SEAL-0 and xBench, the model is competitive or dominant.

The comparison that matters for local-first agents: Nanbeige4.1-3B on deep search outperforms every Qwen model tested, including Qwen3-32B, Qwen3-30B-A3B, and Qwen3-Next-80B-A3B, while running at a fraction of the memory footprint.

Real-world: LeetCode Weekly Contest

Qwen3-4B: 55.0% pass rate Qwen3-32B: 50.0% Qwen3-30B-A3B: 65.0% Nanbeige4.1-3B: 85.0%

Seventeen out of twenty problems solved. First place in Weekly Contest 487. Third place in Weekly Contest 488. The model submitted directly to the official LeetCode platform. No cherry-picked test cases. No self-reported metrics.

What this means for local-first agents

I run everything on a 16 GB Mac Mini. Here is why this model changes the calculus for local agent workloads.

Model size. At 3.93B parameters in BF16, the weights are roughly 7.9 GB. Q4_K_M quantization (standard for consumer hardware) brings this to approximately 2.5 GB. An 8-bit quantized version is about 4 GB. Either fits alongside other services on a 16 GB machine.

KV cache at 256K context. The practical bottleneck is not model weights. It’s the KV cache. At 256K context with 4 KV heads and a head dimension of 128, per-layer KV cache is:

2 (K+V) x 4 (KV heads) x 128 (head_dim) x 262,144 (seq_len) x 2 bytes (FP16) = 536 MB per layer. Across 32 layers: 17.2 GB for the full KV cache.

That is too large for a single 16 GB machine at full 256K context. But practical agentic workloads do not use 256K context at every turn. The typical agent loop runs with 8-32K context windows where the KV cache is 0.5-2 GB. The 256K ceiling is valuable for long-horizon tasks where the agent accumulates context over hundreds of turns. The model can flush or compress older turns.

Where it fits. At Q4_K_M with a 32K context window, the total footprint is roughly 3-4 GB. This runs comfortably on a 16 GB Mac Mini alongside the operating system, browser, and your development environment. No GPU required. No cloud API calls.

What you lose. The tokenizer’s 166K vocabulary targets Chinese. English prompts may use more tokens than an English-native tokenizer. The chat template includes Chinese system prompts for tool calling. You will need to override the default system prompt for English-only applications.

Who is this not for

The tradeoff: Nanbeige4.1-3B beats larger models on execution-based coding, agentic search, and alignment. It underperforms on open-ended creative writing and long-context recall at the 256K ceiling.

Skip this model if you need:

• Creative writing or long-form dialogue. Larger models still produce more natural prose.
• 100% English-native tokenization. The 166K vocabulary is Chinese-heavy. For English-only workloads, check token efficiency against Qwen2.5-3B or Llama-3.2-3B.
• Validated 256K context. The paper claims it. No independent evaluation confirms coherence at that length. Run your own tests.
• Production agent infrastructure. The model is Apache 2.0, but the chat template and tool-calling format target Chinese-first usage. Adapt the system prompt and verify tool-call parsing.

Use this model if you:

• Run agents locally on consumer hardware and need sustained multi-turn interaction.
• Build coding agents that need to generate efficient solutions, not only correct ones.
• Research training recipes for small models. The 4-stage RL pipeline with gated rewards is directly transferable.
• Want the best 3B model for agentic workloads available today.

The whole training recipe

The complete pipeline, in order:

1. Base model: Nanbeige4-3B-Base
2. SFT: 256K context, agent-first data mixture (27% code, 26% deep search, 23% STEM, 13% tool-use, 10% general), solution refinement with CoT reconstruction
3. Point-wise RL: GRPO with general reward model. Targets redundancy, repetition, formatting errors.
4. Pair-wise RL: Strong-weak response pairs, swap-consistency regularizer. Targets preference alignment.
5. Code RL Stage 1: Correctness. Pass-rate reward on execution-based test cases.
6. Code RL Stage 2: Gated time-complexity. Activates efficiency reward only when all tests pass.
7. Agentic RL: Lightweight stage. Strengthens tool-use and search behavior.

Each stage adds a capability the previous stage could not produce. SFT gives baseline competence. Point-wise RL makes the output usable. Pair-wise RL aligns preferences. Code RL Stage 1 ensures correctness. Code RL Stage 2 improves efficiency. Agentic RL extends to sustained interaction.

No single stage is revolutionary. The combination is.

FAQ

Is this model available on Ollama? Not yet at time of writing. The model is available as a HuggingFace Transformers checkpoint and supports vLLM and SGLang for serving. GGUF quantization via llama.cpp should work since the architecture is standard LLaMA. Expect community conversions within weeks of this post.

Does it support tool calling out of the box? Yes. The chat template includes native tool-call formatting with <tool_call> XML tags and multi-turn tool-use handling. The model trains on the ToolMind-Web-QA dataset which includes diverse tool-use trajectories.

How does it compare to specialized agent models like AgentCPM-Explore-4B? AgentCPM-Explore-4B scores 63.9 on GAIA vs Nanbeige4.1’s 69.9. AgentCPM is a specialized search-agent model. Nanbeige4.1 is a generalist that happens to match specialized agents on deep search while also outperforming them on code and reasoning.

Can I fine-tune it for my use case? Yes, Apache 2.0 license. The architecture is standard LLaMA, so any fine-tuning framework that supports LLaMA works. The aggressive GQA (4 KV heads) may require different sharding strategies for multi-GPU training.

What is the inference speed on a Mac Mini? Depends on quantization. At Q4_K_M via llama.cpp, expect roughly 20-40 tokens/second on a 16 GB Mac Mini M-series. At BF16 via MLX, slower but higher quality. The 4 KV heads reduce memory bandwidth requirements compared to full GQA setups.

Related Posts

• llama.cpp: The local inference engine that changed how developers ship AI. How to run quantized models like Nanbeige4.1-3B locally with GGUF format, CLI commands, and Python bindings.
• How to host an AI agent: A beginner’s guide from localhost to production. The deployment pipeline for bringing locally-inferred agents to production.
• Model-agnostic agents: Building agent workflows that work with any LLM backend. Why the agent framework should outlive any single model, including this one.

---

This article was published on Agentic Up (https://agenticup.dev): practical guides for developers and founders building with AI agents. Reach me at [email protected]