Nanbeige4.3-33B: Benchmarks and Memory Needs for Business

Nanbeige4.3-33B is an open Apache-2.0 language model that beats Qwen3.8-27B on 18 of 20 benchmarks in its own model card, trailing only on SWE-Bench Pro and GDPval. Nanbeige ran those scores itself and nobody has reproduced them independently. It is runnable on one large GPU only when quantized. 4-bit weights plus a 32,768-token cache come to about 23.6 GB before overhead, which is not a safe fit on a 24 GB card. 8-bit weights alone are 33.1 GB, and the model card's own examples spread the model across 4 GPUs.

At Layer3Labs, we build custom agents and enterprise integrations for business teams. When an open weights model surfaces with claims of leading its size class, leadership teams need to know whether the hardware footprint and operational boundaries justify running it over a hosted model from another provider.

The model has 33,118,977,024 parameters and a 524,288-token context window. Reddit posts about the model are community posts. Nanbeige's own model card table is the evidence for the scores.

Nanbeige4.3-33B vs Qwen3.8-27B on the Vendor's Own Benchmarks

Nanbeige evaluated Nanbeige4.3-33B against Qwen3.8-27B, Muse-Glimmer-30B, and Gemma4-31B using identical inference hyperparameters across 20 distinct benchmarks at maximum thinking effort. Across these tests, Nanbeige4.3-33B scores higher than Qwen3.8-27B on 18 evaluations and trails on two. The evaluations divide across agentic coding, cowork tasks, and general reasoning, with Nanbeige4.3-33B evaluated using the preserve_thinking parameter set to true.

In agentic software development, Nanbeige reports large margins on terminal and coding benchmarks. Nanbeige4.3-33B achieved 80.9 on Terminal-Bench 2.1 compared to 73.0 for Qwen3.8-27B, 23.8 on Terminal-Bench 4.0 compared to 6.3, and 65.5 on DeepSWE compared to 42.5. It also leads on SWE-Atlas-QnA (50.8 to 41.9), NL2Repo at 53.0 to 48.3, Scicode at 52.6 to 46.7, and SkillsBench at 61.1 to 56.4. However, on SWE-Bench Pro, Qwen3.8-27B leads at 61.7 while Nanbeige4.3-33B scores 60.3.

On agentic cowork and enterprise workflow benchmarks, Nanbeige reports that Nanbeige4.3-33B leads on eight tests while trailing on GDPval. Nanbeige4.3-33B scored 54.2 on Automation Bench compared to 38.3 for Qwen3.8-27B, 44.8 on JobBench compared to 34.5, 78.3 on Claw-Eval pass^3 compared to 75.2, and 70.4 on Toolathlon-Verified compared to 68.5. It recorded 63.3 on DeepPlanning versus 49.2, 41.0 on EnterpriseOps-Gym versus 40.2, $1,025,437 on YC-bench versus $641,290, and 48.8 on Tau3-Bench versus 48.5. On GDPval, Qwen3.8-27B leads at 86.4 compared to 84.8 for Nanbeige4.3-33B. For general reasoning, Nanbeige4.3-33B reached 89.5 on Graduate-Level Google-Proof Q&A (GPQA) Diamond where Gemma4-31B led at 91.3, 95.2 on the 2026 American Invitational Mathematics Examination (AIME 2026), and 84.0 on AA-LCR.

• Nanbeige4.3-33B leads Qwen3.8-27B on 18 of 20 vendor-reported benchmarks but trails on SWE-Bench Pro and GDPval
• Terminal-Bench 4.0 score reached 23.8 for Nanbeige4.3-33B compared to 6.3 for Qwen3.8-27B
• DeepSWE score reached 65.5 for Nanbeige4.3-33B versus 42.5 for Qwen3.8-27B
• JobBench evaluation shows Nanbeige4.3-33B outperforming baselines across most of the 35 occupations evaluated
• All reported scores reflect Nanbeige's internal benchmark harness and have not been independently reproduced

Architecture Specifications and Apache-2.0 Release Terms

Nanbeige released Nanbeige4.3-33B on Hugging Face on October 24, 2026, with repository updates continuing through October 25, 2026. The weights distribute across 14 safetensors shards in Brain Floating Point 16 (BF16) format, totaling 33,118,977,024 parameters without gating requirements. As of October 26, 2026, the repository lists 511 likes and 2,787 downloads. Nanbeige provides the weights under the permissive Apache-2.0 license, allowing commercial software deployment, private self-hosting, and fine-tuning.

The model architecture uses the LlamaForCausalLM design within the Transformers framework. The network configuration specifies 52 transformer layers, a hidden dimension size of 7,168, 56 attention heads, and 8 key-value heads using grouped-query attention with a head dimension of 128. It supports both English and Chinese text generation across an extended context window of up to 524,288 tokens (512K). Nanbeige positioned this model as the flagship teacher model for its Nanbeige4.3 family, having trained it from the Nanbeige4.3-33B-Base checkpoint, with planned distillation into smaller models such as Nanbeige4.3-3B.

Prompt formatting relies on a built-in chat template that enables chain-of-thought reasoning by default. Operators can turn the enable_thinking parameter to false for immediate responses, or toggle preserve_thinking to true for multi-turn tool interaction, code development agents, and professional tasks. Nanbeige recommends Extensible Markup Language (XML) tool-call formatting, while JavaScript Object Notation (JSON) tool calls remain supported. For agentic pipelines, Nanbeige recommends setting temperature to 1.0, top_p to 0.95, and maximum new tokens to 65,536, while reasoning tasks use temperature 0.6 and top_p 0.95.

• Published under the Apache-2.0 license with ungated access to all 14 BF16 safetensors shards
• Features 52 transformer layers, 7,168 hidden size, 56 attention heads, and 8 key-value heads
• Native context window processes up to 524,288 tokens in English and Chinese
• Serves as the teacher model for future planned distillations like Nanbeige4.3-3B
• Supports XML and JSON tool calling with configurable chain-of-thought thinking parameters

Hardware Requirements and Serving Calculations

In our own calculation from the published numbers (not a test), we worked out the memory the model needs using the published parameter counts and transformer layer dimensions from the model card config. Memory consumption splits into model weight storage and dynamic key-value (KV) cache allocation. Model weight storage equals parameters multiplied by bytes per parameter. At 16-bit precision, 33,118,977,024 parameters require 66.2 gigabytes (GB) of video random access memory (VRAM). Quantizing the weights to 8-bit precision requires 33.1 GB, and 4-bit precision reduces the weights to 16.6 GB before accounting for quantization format overhead or execution runtimes.

Serving dynamic context adds heavy memory demands as sequences expand. KV cache memory scales by multiplying the number of layers, key-value heads, head dimension size, 2 for key and value states, 2 bytes for 16-bit storage, and the token count. For Nanbeige4.3-33B, this formula equals 52 layers multiplied by 8 heads, 128 dimensions, 2 states, and 2 bytes, yielding 212,992 bytes per token. A sequence of 32,768 tokens consumes 7.0 GB of VRAM strictly for the KV cache. At 131,072 tokens, the KV cache requires 27.9 GB, and utilizing the full 524,288-token window requires 111.7 GB of memory for the cache alone.

These numbers establish strict hardware boundaries for production infrastructure. A single 24 GB GPU cannot safely serve Nanbeige4.3-33B even at 4-bit quantization because 16.6 GB of weights combined with a 32,768-token cache of 7.0 GB totals 23.6 GB before overhead. A community post on r/LocalLLaMA shares a GGUF quantization, but the quality of community quantizations is not established by Nanbeige's benchmark table and should be checked before relying on one. For a worked example of local memory planning on a different open model, see our Muse Spark local setup guide. BF16 weights alone are 66.2 GB, and the model card's own vLLM and SGLang examples use tensor parallel size 4 with the qwen3 reasoning parser and the qwen3_coder tool-call parser. In practice, 4-bit weights need a card with clearly more than 24 GB once the cache is added, 8-bit weights plus a 32,768-token cache come to about 40.1 GB, and 16-bit weights plus that cache come to about 73.2 GB, and the model card's own vLLM and SGLang examples use tensor parallel size 4.

• Weights require 66.2 GB in 16-bit BF16, 33.1 GB in 8-bit, and 16.6 GB in 4-bit representation
• Dynamic KV cache requires 212,992 bytes per token at 16-bit precision across 52 layers and 8 KV heads
• A 32K context cache requires 7.0 GB, a 131K cache requires 27.9 GB, and a 512K cache requires 111.7 GB
• A 24 GB GPU cannot safely host 4-bit weights alongside a 32K context window due to execution overhead
• Official serving examples in vLLM and SGLang configure tensor parallelism across 4 GPUs

Enterprise Workflows and Commercial Deployment Limits

An Apache-2.0 license allows commercial use and private self-hosting. For organizations handling sensitive source code, confidential documents, or regulated internal records, private hosting avoids sending raw inputs to external application programming interface (API) providers. Nanbeige positions it for complex coding and professional cowork tasks and reports scores on terminal, repository and office-workflow benchmarks. Those are the workloads to pilot where proprietary data cannot leave your network.

Deploying Nanbeige4.3-33B remains the wrong operational decision for organizations without GPU capacity or in-house machine learning engineering staff. The Nanbeige4.3-33B model card lists no hosted price, so the break-even against a hosted API cannot be computed yet. Teams evaluating total cost of ownership should consult our guide on open weights models costs before purchasing compute capacity.

Run a pilot if you have GPU capacity and a coding or tool-use agent workload that wants Apache-2.0 weights. Stay on a hosted API if you lack GPUs or machine learning staff to run them. Revisit the decision when independent evaluations or a published hosted price exist, because neither is available today. For other options, see our list of best open weights AI models before scheduling an operational audit.

• Apache-2.0 license permits private corporate deployment and commercial software redistribution
• The model card lists no hosted price
• BF16 weights alone require 66.2 GB of memory based on published parameter calculations
• The model card does not describe training data or safety evaluations, so teams need to validate internally