Nanbeige 4.3 33B vs Qwen 3.8 27B: local tests, RAM and VRAM

Community tests ↓Memory needs ↓Model-fit calculator →

What Nanbeige 4.3 33B is

Nanbeige4.3-33B appeared on Hugging Face on 24 October 2026 under the Apache 2.0 licence. It is a dense model of 33.1 billion parameters on the ordinary Llama architecture: 52 layers, and every one of them uses full attention. The card lists English and Chinese, a 524,288-token (512K) context window, and a base checkpoint published alongside it. Model card · config.json.

The lab calls it the “teacher” of the 4.3 series: the large model it will distil into smaller ones, starting with a planned 3B. That matters for reading the card. The release is pitched at agent work, coding and office-style tasks, and most of the benchmarks chosen are agent benchmarks.

Qwen 3.8 27B is the model it compares itself against first, and the one I have already measured. It is 27.8 billion parameters, also Apache 2.0, and a hybrid: only 16 of its 64 layers use full attention, and the rest use linear attention with a fixed-size state. That difference decides how much memory a long context costs, covered below.

Nanbeige 4.3 33B benchmarks, as published

Every number in this table is Nanbeige’s. The card says all four models ran at their highest thinking effort, with the same inference settings and harness for each benchmark. I have not rerun any of them. Rows are six of the eight agentic-coding rows plus four others; the full table has 20 rows. Full table and footnotes.

On these rows Nanbeige leads the agent benchmarks, and the gap is widest where the task is long and runs in a terminal: 23.8 against 6.3 on Terminal-Bench 4.0, and 65.5 against 42.5 on DeepSWE. Qwen keeps a narrow lead on SWE-Bench Pro (61.7 against 60.3) and GDPval (86.4 against 84.8). On GPQA Diamond the two are level, and Gemma 4 31B is ahead of both.

What the card’s footnotes change

• Each benchmark has its own harness. Terminal-Bench 2.1 ran in Terminus 2; Terminal-Bench 4.0, DeepSWE and SWE-Atlas in mini-swe-agent v2.4.6; NL2Repo and JobBench in Claude Code. A score belongs to the model and the harness together, so a different agent on your machine can land somewhere else.
• Nanbeige ran with preserve_thinking=true. That keeps the reasoning from earlier turns in the conversation, which the card recommends for multi-turn tool use. Front ends differ in whether they send that earlier reasoning back, and the card does not say how Qwen’s earlier turns were handled.
• Some scores are judged by another model. SWE-Atlas-QnA answers were marked against 1,304 rubrics by GPT-6 Sol at medium effort. That is a grader’s opinion of an answer rather than a test that passes or fails.
• Nothing in the table describes a quantised build. The weights ship in BF16 and the card’s SGLang and vLLM examples split the model across four GPUs. Most people reading this will run a 4-bit file on a Mac or a single 32 GB card, and the card says nothing about that.

None of that makes the table wrong. It means the table answers “which checkpoint is stronger in these harnesses”, and the question for local use is narrower: does the lead survive quantisation, a smaller context budget and the agent you actually use? The note on why benchmark charts disagree goes through the same problem for speed figures.

Community tests: Nanbeige vs Qwen on the same hardware

On 2 November, nine days after release, most of the careful public tests so far sit on the model cards of community quantisations, with a few on personal blogs. Every figure in this section belongs to the person or team linked beside it; I have not reproduced any of them. I checked each one on its source page on 2 November 2026 and left out speed figures that the authors label as estimates.

Agent tasks on one RTX 3090 (Yamz Labs)

Yamz Labs ran both models on one RTX 3090 with its Kyojin engine (built on ExLlamaV3), both as 4.0-bit EXL3 files, through an agent client with shell and file tools and thinking on. Qwen used its built-in draft head for speculative decoding; Nanbeige ran without one. Yamz Labs model card.

Half of Nanbeige’s misses were tasks stopped by the wall-time limit rather than wrong answers: 2 of its 6 misses on the 30-task set and 3 of its 4 on the harder set. The card’s explanation is that it thinks at length and decoded at about half Qwen’s speed on that card. That is a different picture from the vendor table: on a 24 GB consumer card, at 4-bit, Qwen solved slightly more and finished in less than half the time.

On Macs: the same-machine speed test

tristanbes ran both models on one Mac Studio M5 Ultra (80-core GPU, 256 GB) with mlx-lm 0.32.2 and llama.cpp b11896, at 4-bit in each, and published the commands and most of the raw output. M5 Ultra benchmark dataset.

With a short prompt the two are close. As the context fills, Nanbeige slows much faster, because every token it writes has to read a cache three times the size of Qwen’s. At 128K, prompt reading was 630 tokens per second for Nanbeige against 1,220 for Qwen. Agents live at the long end of this table.

On smaller Macs

• M5 Max, 128 GB (fcmeyer, mlx-lm): the MLX 4-bit build decoded at 27.8 tokens per second with a 512-token prompt and 21.3 at 16K, peaking at 19.3 and 22.5 GB. The 8-bit build ran at 15.0 tokens per second in 35.6 GB, and BF16 at 7.9 in 66.9 GB. fcmeyer 4-bit card.
• Mac mini M5 Pro, 64 GB (pratikgx, mlx-lm 0.32.2): 14.4 tokens per second at 512 tokens and 9.9 at 32K, peaking at 26.4 GB. A needle-in-a-haystack test found the needle at 32K, 64K and 128K; the 128K run peaked at 47.8 GB. pratikgx MLX card.
• M4 Pro, 48 GB (killen8, mlx-lm 0.29.1): about 13.7 tokens per second, peaking at 18.8 GB. killen8 MLX card.

Which 4-bit file matters too. Kapitsa measured how far each quantisation drifts from BF16 on 768 tokens of Python: the plain MLX 4-bit conversion picked the same top token as BF16 90.5% of the time, a Q4_K_M it made with llama.cpp 93.5%, and Q8_0 99.0%. Kapitsa builds a competing Mac runtime, so read its speed claims with that in mind; the drift figures are for standard files rather than its own pack. Kapitsa MLX card.

Independent quality checks

• Korean document questions. A reviewer at bric.pe.kr ran 299 Korean questions with retrieved pages through both models in Ollama on an RTX 3090 (Nanbeige at Q4_K_S, Qwen at Q4_K_M). With thinking on, Qwen scored 77.3% and Nanbeige 66.2%, or 70.6% after rerunning, under changed settings, the 29 answers that hit the 8,192-token cap. A second judge, Claude Opus 5.5, gave the same order. Nanbeige produced about 38 tokens per second against Qwen’s 85; with thinking off each answer took 17.8 seconds against 4.0, partly because some answers looped to the output cap, and without thinking it often repeated its own sentences until it hit the output cap. The author’s conclusion is narrow: the card has no Korean or document results, and the lead simply does not carry over to that task. bric.pe.kr, 28 October.
• Artificial Analysis. Its Intelligence Index puts both models at 20. Nanbeige used 160 million output tokens to complete the index, Qwen 3.8 27B at its highest reasoning setting 130 million. Nanbeige on Artificial Analysis · Qwen 3.8 27B.

Has anyone reproduced the Terminal-Bench score?

Not that I could find. I found no independent rerun of Terminal-Bench, DeepSWE or SWE-Bench Pro, the benchmarks behind Nanbeige’s biggest claims. Until one appears, the long-horizon terminal lead rests on the card alone.

Tool calls and agents on vLLM and SGLang

• Tool-call score below Qwen’s. primitive-ai runs the same 200-item suite on every model it quantises. Nanbeige scored 80.8 on tool calls in BF16 and 78.8 as NVFP4; its mixed NVFP4/FP8 build of Qwen 3.8 27B scored 85.5. Nanbeige did better on knowing when to abstain (63.3 against 54.5). primitive-ai NVFP4 card.
• Claude Code works, after a template fix. Helix served the NVFP4 build on RTX PRO 6000 cards with vLLM and pointed Claude Code at it. It passed 9 to 10 of 10 coding tasks, but only 13–28% of prompt tokens came from the cache, because the chat template rejects system messages after the first one and Claude Code adds them mid-conversation. A one-line template change raised cache hits to 92–96% and finished the tasks 13–35% sooner. Turning thinking off halved the median task time but sent the two hardest tasks into Claude Code’s 60-turn limit. Helix, 28 October.
• One parser edge case. ProCreations audited SGLang 0.5.21 with both the Nanbeige and qwen3_coder parsers: 44 of 52 checks passed, and all eight failures were one bug. A literal </parameter> inside a string argument cuts the argument off at that point. Code that writes XML or HTML can hit it. My 40-check tool-calling test is one way to check a runtime before trusting it with a long session. ProCreations FP8 card.

Speed and memory on NVIDIA cards

Two things stand out. First, every measured RTX 5090 result I found uses ExLlamaV3 at 3 to 4 bits, not a llama.cpp GGUF or vLLM, so a 5090 owner on Ollama or LM Studio does not yet have a published number to compare with. Several of these runs use a 2-bit to 4-bit cache to fit long contexts. Yamz Labs measured the cache’s effect on this model and recommends 6-bit: at 4-bit, the top token matched the BF16 reference only 82.6% of the time against 90.4% at 8-bit (the KV cache precision note explains the trade). Second, the DFlash2 drafter is the single biggest lever (the speculative decoding note explains how a drafter works): ProCreations measured 1.51× on its NVFP4-A16 build and 1.76× on BF16 with SGLang at temperature 0 (1.39× and 1.63× at the agent setting of 1.0), and about 2.3–2.6× on agentic coding prompts. I found no published figure for the drafter combined with primitive-ai’s NVFP4 build on vLLM. DFlash2 drafter card.

Memory: will it fit a Mac or an RTX 5090?

The weights are only part of it. Nanbeige uses full attention in all 52 layers with 8 key-value heads of 128 dimensions, so its cache costs 208 KiB per token at 16-bit. Qwen 3.8 27B keeps a full cache in only 16 layers (4 heads of 256 dimensions), which comes to 64 KiB per token, plus a small fixed state for its linear-attention layers. At the same context, Nanbeige’s cache is about 3.25 times larger.

Adding the cache and the runtime gives the totals below. I used the same rule as the model-fit calculator: weights, plus the 16-bit cache, plus 1.5 GiB and 5% of the weights for the engine and its buffers. These are my estimates rather than measurements, and they run low: Qwen’s 18 GB NVFP4 build peaked at 27.9 GB at 64K in my coding test, against about 25 GB from the formula.

• RTX 5090 (32 GiB, about 34.4 GB). Nanbeige at Q4_K_M fits at 32K with a 16-bit cache and little to spare. 64K needs the cache at 8-bit, which brings it back to about 30.4 GB. Q5_K_M only fits with an 8-bit cache at 32K. Qwen at Q4_K_M fits at 128K with room left over. My M4 Max and RTX 5090 test compares the two machines on the same Qwen build.
• Macs. By default macOS lets the GPU use about 75% of unified memory on larger Macs, and somewhat less on small ones. On a 32 GB Mac that is roughly 23–27 GB depending on the model and macOS version, enough for Nanbeige’s 4-bit weights and a short context but not 32K. A 36 GB Mac (about 29 GB) is borderline at 32K, so measure before relying on it. A 48 GB Mac (about 38.7 GB) holds the MLX 4-bit build at 64K, and a 64 GB Mac (about 51.5 GB) just holds 128K. The Apple Silicon guide covers choosing a Mac by memory.
• The full 512K context needs about 112 GB of cache alone at 16-bit. That is a server or a 192 GB-plus Mac, before the weights.

Agent harnesses spend context quickly. Codex CLI’s own system prompt and tool definitions took about 14K tokens in my test, and 40 tool results can push a session past 32K, which is why that test ran at 64K (see the notes in the protocol file). For the same agent work at 64K, budget Nanbeige about 13 GB more than Qwen.

Settings the card asks for

• Thinking is on by default. enable_thinking=false turns it off. For agent loops the card recommends preserve_thinking=true, so earlier reasoning stays in the conversation; for ordinary chat it recommends setting it to false.
• Tool calls default to an XML format. The card says tool_call_format="xml" gives the best results, with JSON kept for compatibility. For SGLang and vLLM it uses Qwen’s parsers: --reasoning-parser qwen3 and --tool-call-parser qwen3_coder.
• Send your own system prompt. When tools are passed without a system message, the chat template inserts a default one written in Chinese. The plain-chat default also names the model as Nanbeige from BOSS Zhipin. Agents that already send a system prompt are unaffected.
• Text only. The template replaces image, audio and video input with a note that the model cannot read them.
• No official Ollama build yet. On 2 November the Ollama library had no Nanbeige 4.3 tag from Ollama itself. GGUF files load through Ollama’s Hugging Face path or llama.cpp, and MLX users have community 4-bit conversions.

Which one I would run for a local coding agent

For a local agent today I would stay on Qwen 3.8 27B. Both same-machine tests that scored accuracy had Qwen ahead, clearly on the Korean document questions and narrowly on Yamz Labs’ small task sets, and Qwen finished agent tasks 2.3 to 3.2 times faster where they were timed. Its smaller cache leaves room for the 64K or more that agents use. It also already passed all 24 attempts on my own coding protocol.

Nanbeige is worth a trial in three cases:

• You run long terminal tasks where its card shows the biggest gap (Terminal-Bench 4.0, DeepSWE) and can afford the extra time per task.
• You serve it on a large NVIDIA card with vLLM or SGLang, where 4-bit NVFP4 builds and the DFlash2 drafter recover much of the speed. The RTX 5090 serving guide covers those settings for Qwen, and the SGLang and vLLM comparison the engines.
• You care about refusing to answer when the information is missing: primitive-ai’s abstain score was higher for Nanbeige.

Whichever you try, give it the agent settings from the card, send your own system prompt, and check that tool calls parse in your runtime before trusting a long session to it.

How I’ll test it against Qwen on the M4 Max

Qwen 3.8 27B already has a full run on my frozen coding protocol: eight tasks on a small TypeScript repository, three attempts each, Codex CLI as the agent, 64K context, a 600-second or 40-tool-call cap, hidden acceptance tests and a blind review. It passed all 24 attempts, with a median of 213 seconds per passing attempt and 27.9 GB peak model memory. The coding note has the per-task results, the protocol and the CSV.

Nanbeige goes through the same protocol unchanged. I will record:

1. The build. bartowski’s Q4_K_M GGUF (20.8 GB) through Ollama, with its digest. Qwen ran as an 18 GB NVFP4 build on Ollama’s MLX engine, so the bit widths and engines differ; I will say so beside every number rather than pretend they match.
2. Speed and memory. Prefill and decode rates on a fixed probe prompt, time to first token, and peak memory at 64K.
3. Agent results. Pass, fail, time-cap hits, empty or malformed tool calls, and wall-clock time for each of the 24 attempts, beside Qwen’s.

Until that run exists, this page reports the card and other people’s measurements, and the memory figures above are estimates.

FAQ: Nanbeige 4.3 33B on Ollama, an RTX 5090 and a Mac

Sources and what I did not test

I researched this on 2 November 2026. Benchmark scores in the first table are Nanbeige’s. Every community figure belongs to the author linked beside it, and I read each one on its source page that day; speed figures labelled as estimates, and posts I could not open, are left out. The memory totals are my calculations from published file sizes and each model’s configuration. I have not run Nanbeige myself yet.

• Nanbeige4.3-33B model card, benchmarks and quickstart
• Qwen3.8-27B model card and configuration
• bartowski GGUF files and sizes
• Yamz Labs: same-card agent tasks on an RTX 3090
• tristanbes: M5 Ultra MLX and llama.cpp speeds
• bric.pe.kr: Korean document-QA comparison
• Helix: Claude Code on vLLM and the template fix
• primitive-ai: NVFP4 build, speed and tool-call suite
• ProCreations: DFlash2 drafter and SGLang parser audit
• Artificial Analysis: Nanbeige4.3-33B

Suhail Mohebi · published 3 November 2026 · the cover is a generated illustration