Nanbeige4.3-33B Released: 33B Dense, 512K Context, Apache 2.0 Weights, Self-Reported Benchmarks Clash With Rival Model Cards
According to a MarkTechPost report dated October 25, 2026, BOSS Zhipin's Nanbeige LLM Lab released the 33B dense model Nanbeige4.3-33B on Hugging Face under the Apache 2.0 license, along with a Base version for custom post-training. It supports a 524,288-token context and a self-reported table leads on 17 of 20 benchmarks, but some competitor figures conflict with those rivals' official model cards.
What changed
According to a report by MarkTechPost journalist Asif Razzaq dated October 25, 2026, Nanbeige LLM Lab (described in the report as belonging to recruiting platform BOSS Zhipin) released Nanbeige4.3-33B on Hugging Face under the Apache 2.0 license, alongside Nanbeige4.3-33B-Base for custom post-training. The report says the model is a 33B dense (non-MoE) language model whose cited config.json declares a standard LlamaForCausalLM architecture: 52 layers, hidden dimension 7,168, 56 query heads and 8 key-value heads (grouped-query attention), FFN intermediate dimension 22,016, vocabulary of 166,912 tokens, RoPE theta of 120,000,000, up to 524,288 positions (512K context), and text-only input modality; the report also says the model card lists one community quantization. The report says the chat template exposes three controls—enable_thinking (on by default), preserve_thinking, and tools—and that Nanbeige recommends enabling preserve_thinking for multi-turn tool use and coding agent scenarios, with XML call format recommended for tool calls. The report says the lab positions Nanbeige4.3-33B as the series' "teacher" model, planning to distill agent capabilities into smaller models, starting with Nanbeige4.3-3B. On benchmarks, the report says that in Nanbeige's own comparison table the model leads 17 of 20 items against Qwen3.8-27B, Muse-Glimmer-30B, and Gemma4-31B: Terminal-Bench 2.1 scores 80.9 (Qwen3.8-27B at 73.0), DeepSWE 65.5 versus 42.5; Terminal-Bench 4.0 scores 23.8 (described as the model's lowest score), and SWE-Bench Pro at 60.3 trails Qwen3.8-27B's 61.7. The report specifically notes that several competitor figures in Nanbeige's table conflict with the rivals' official model cards: Meta reports Muse-Glimmer-30B at 51.2 on SWE-Bench Pro and Gemma4-31B at 36.9, while Nanbeige lists them exactly reversed; Google lists Gemma 4 31B at 84.3 on GPQA Diamond, while Nanbeige's table shows 91.3; Meta reports Muse-Glimmer-30B at 51.7 on Terminal-Bench 2.1, while Nanbeige measured 61.8. The report argues different test harnesses can explain some gaps, but the SWE-Bench Pro pair appears swapped, so these rows should be treated as provisional until independent reproduction appears. On deployment, the report says the model card provides Transformers, SGLang, and vLLM recipes, with a server example using 4-way tensor parallelism together with Qwen3's reasoning and tool-call parsers; based on config.json the report estimates BF16 weights need about 66 GB, and at BF16 the KV cache is about 208 KiB per token, roughly 112 GB for a full 524,288-token sequence; the report says that as of its publication no Hugging Face inference provider hosted the model. All the above benchmarks are vendor self-reported or media-relayed; the weight and KV cache figures are estimates given by the report, not official disclosures; we have not tested them, nor independently verified the model repository's config and license files.
What it means for developers
The most direct constraint for developers is the deployment shape. The official recipe described is 4-way tensor parallelism on a multi-GPU server, not a single-card workstation path; the report also gives an estimate of about 66 GB for BF16 weights, meaning even without quantization you need a multi-GPU or multi-machine environment to get the service running. Evaluation plans have to solve hardware first, then talk about model quality. This part is conditional analysis: actual VRAM usage varies with inference framework, batch size, and concurrency, and must be measured on your own machines. The second issue is the real cost of long context. The report estimates about 208 KiB per token of KV cache at BF16, roughly 112 GB for a full 524,288-token sequence—the same order of magnitude as the weights themselves. That makes 512K more of an "on-demand capability" than a default configuration: if long requests are rare in your business, lowering the context cap will significantly change VRAM budgets and concurrency; if you truly need full length, the KV cache becomes the main cost item, and quantizing weights does not directly solve that—you need separate KV quantization or paging strategies. The third issue is integration and framework fit. The report says XML format is recommended for tool calls, and the server example pairs with Qwen3's reasoning and tool-call parsers. For teams that already built agent loops on OpenAI-style function-calling protocols, this typically means changing the parsing layer and prompt templates, not just swapping an endpoint. The described enable_thinking default-on and preserve_thinking retaining prior reasoning content also change per-turn token composition and multi-turn costs; if your framework truncates or reorders history, confirm the actual behavior of these controls first. The fourth issue is evaluation methodology. The report lists conflicts between Nanbeige's self-reported table and Meta's and Google's official model cards on several benchmark rows, with the SWE-Bench Pro row seemingly swapped, so any cross-model conclusion like "how much stronger than some near-30B model" does not hold until independent reproduction. What can be used as reference is the structural information inside the same table: Terminal-Bench 2.1 self-reported lead, while Terminal-Bench 4.0 self-reported absolute score is only 23.8—a drop within the same benchmark family suggesting capability is highly sensitive to task and test harness, so selection should be based on reproduction on your own tasks. The fifth issue is modality and licensing. The model is text-only input and cannot directly handle screenshots, charts, or video, so it is not a substitute for workflows needing visual input. On licensing, open weights should be distinguished from license terms: the report says the weights are released under Apache 2.0, which is more permissive than "weights-only" releases, but the license file bundled with the model repository should still govern—do not infer commercial use and redistribution terms merely from downloadable weights. According to the current KimiSeek catalog check, neither Nanbeige4.3-33B nor Nanbeige4.3-33B-Base is on the list of listed models; the distribution described in the report refers to Hugging Face weight downloads, and any hosted API would be the vendor's own channel.
Integration and evaluation
The following are suggestions or conditional analysis, not factual conclusions from the report. Decision one (inference stack choice): The report says the model card provides both SGLang and vLLM recipes, and the server example uses 4-way tensor parallelism bound to Qwen3's reasoning and tool-call parsers. The choice is whether to maintain one stack or two in parallel. The condition is whether you rely on tool calls: if agent flows need stable function-call parsing, the disclosed parser binding means switching stacks may change parsing behavior, and only then is dual-stack maintenance worth the cost; for pure text inference, a single stack is more economical. A measurable validation standard is preparing 20 to 50 tasks with tool calls, counting tool-call format error rates and parse failure rates on each stack, and converging to a single stack if the difference is acceptable. Decision two (context cap and VRAM budget): The report estimates about 66 GB for BF16 weights, about 208 KiB KV cache per token, and about 112 GB for a full sequence. The choice is the service's context length cap and concurrency cap. The condition depends on the real request context distribution: if the vast majority of requests are within 32K, capping far below 512K frees substantial VRAM for concurrency, reserving 512K for a few long tasks. A measurable validation standard is recording context-length percentiles from production or load tests, and measuring peak VRAM and P95 first-token latency under the chosen cap, confirming both fit within hardware headroom; if not, lower the cap or switch to the community quantization (the report says one is listed; quality impact must be tested yourself). Decision three (evaluation priority and order): The report notes conflicts between the self-reported table and others' official model cards on rows such as SWE-Bench Pro, GPQA Diamond, and Terminal-Bench 2.1, and judges the SWE-Bench Pro row as seemingly swapped. The choice is whether to keep arguing over public leaderboards or spend budget on reproducing on your own tasks. The condition is whether your workload is strongly tied to agentic coding or office collaboration: if so, your own repositories and real tasks matter more than leaderboards. A measurable validation standard is measuring executable success or pass rate on your own task set under one evaluation script, comparing against a same-size baseline in the same script; only differences within the same test harness can inform selection. Decision four (token composition in multi-turn agents): The report says enable_thinking is on by default, preserve_thinking retains reasoning content from previous turns, and the vendor recommends enabling it for multi-turn tool use and coding agents. The choice is whether to retain historical reasoning by default or trim by turn. The condition is the number of conversation turns: the more turns, the more retaining reasoning amplifies context and cost. A measurable validation standard is comparing task success rate, total token consumption, and first-token latency between retained and trimmed settings on the same batch of multi-turn tasks, and adopting trimming to control cost only if success rate shows no significant drop.
Limits and open questions
To be clear: according to the current KimiSeek online catalog check, neither Nanbeige4.3-33B nor Nanbeige4.3-33B-Base appears on the list of listed models; this version is not currently offered on KimiSeek, and the distribution and availability mentioned in the report refer to Hugging Face weight downloads, or the vendor's own channel for any hosted API. The report only confirms that as of its publication no Hugging Face inference provider hosted the model; it does not assert that every other hosting channel lacks it, and whether other channels offer it should be verified separately. We have not independently verified the model repository, configuration files, or bundled license files; the architecture parameters, controls, and license description in this article all come from the report's relay of the model card and config.json. All benchmark scores in the report are Nanbeige self-reported or media-relayed, with no independent third-party reproduction yet, and the report itself points out that several competitor figures conflict with Meta's and Google's official model cards, with the SWE-Bench Pro row seemingly swapped—these rows should be treated as provisional until independent reproduction. The roughly 66 GB weights, about 208 KiB KV cache per token, about 112 GB KV cache for a full sequence, and 4-way tensor parallelism are estimates by the report based on config.json or relay of the model card, not official disclosures and not our own measurements; actual VRAM usage is affected by inference framework, batch size, concurrency, and context distribution, and must be measured on your own hardware. Apache 2.0 is the license description given in the report; downloadable weights are not the same as license terms, and specific commercial use and redistribution conditions should be governed by the license file bundled with the model repository. Behaviors such as the recommended XML format for tool calls, parser pairing with Qwen3, and enable_thinking defaulting to on all come from the report's description of the model card and chat template, and actual behavior may change with version updates. The distillation plan for Nanbeige4.3-3B is a vendor-stated plan with no public weights or capability data yet and should not be treated as a delivered capability.