BOSS 直聘是做招聘的。它开源了一个模型，专门处理终端里的任务。
10 月 25 日，BOSS 直聘（看准科技）旗下的 Nanbeige 实验室把 Nanbeige4.3-33B 放上了 Hugging Face。同一天上架的还有 Base 版本，许可证是 Apache 2.0，商用不用另外申请。
图1、官方账号的发布帖
这份榜排的是什么模型卡给了 20 项基准，分成三块。智能体编程 8 项，智能体办公 9 项，推理 3 项。
对比对象是三家同档开源模型，千问 3.8 27B，Muse-Glimmer-30B，Gemma4-31B。四家都按最高 thinking 档跑，每项基准用同一套 harness 和同一组推理参数。区别只有一处，Nanbeige 这边把前面回合的思考过程保留了下来，另外三家没有。
所有数字都出自发布方，目前没有第三方复测。下面的对比都依据这一张表。
差距最大的地方在终端Terminal-Bench 2.1 这一项，Nanbeige 拿到 80.9，千问 3.8 27B 是 73.0，Muse 61.8，Gemma4 47.2。
换到更难的 Terminal-Bench 4.0，四家一起往下掉。Nanbeige 还有 23.8，千问 6.3，Muse 1.6，Gemma4 是 0 分。分数都不高，差距却比 2.1 那一版更大。
DeepSWE 考的是在仓库里改代码。Nanbeige 65.5，千问 42.5，差 23 分。Terminal-Bench 和 DeepSWE 都跑在 mini-swe-agent 上，4.0 那一版用的是 v2.4.6。
图2、官方模型卡里的八项基准对比
另一半考的是办公Automation Bench 用 600 个公开任务测自动化流程。Nanbeige 54.2，千问 38.3。
JobBench 换了个做法，把 35 个职业的日常任务直接交给模型，执行环境里接了 Claude Code 和一个搜索工具。Nanbeige 平均 44.8，千问 34.5。按官方的说法，多数职业上它超过了基线。
35 个职业的日常任务，正好落在招聘平台的业务范围里。模型卡末尾还留了联系方式，欢迎一起做行业专用的 Agent，数据和训练都能合作，邮箱是 nanbeige@kanzhun.com。这类任务的数据，一家招聘公司本来就有。
还有一项直接按钱算。YC-bench 让模型运营一家模拟公司，最后看账面结余，Nanbeige 是 102.5 万美元，千问 64.1 万美元。这个数要连脚注一起看，每次模型调用只把最近 10 轮对话算作历史上下文。
三项没赢，官方也写进表里SWE-Bench Pro，Nanbeige 60.3，千问 61.7。GDPval，Nanbeige 84.8，千问 86.4。两项分别差 1.4 分和 1.6 分。
GPQA Diamond 这一项，Nanbeige 89.5，比千问的 89.2 高一点，但 Gemma4-31B 拿到 91.3，四家里最高。
20 项里有 18 项超过千问 3.8 27B，17 项是四家里最高的。输掉的三项，发布方一条都没删。
图3、20 项基准的完整数字
先造教师，再蒸 3B官方把定位写得很直接，这是 Nanbeige4.3 系列的旗舰教师模型。
先把 33B 做出来，用它产出的结果去训练更小的模型，第一个要蒸的是 Nanbeige4.3-3B。3B 版还没上线，官方只说在路上。
这家实验室此前的 4.1 和 4.2 都是 3B 档，这次先发 33B，顺序反了过来。先在大模型上把智能体能力做实，再交给小模型。
33B 稠密，装得下才算数回到模型本身，33B 是稠密模型，不是 MoE。区别在每一步要用多少参数，稠密模型每生成一个 token，33.1B 参数全部参与计算，MoE 则把参数分成若干组，每次只激活其中几组。稠密的好处是每一步的计算量固定，速度稳定。代价在显存，全部参数都得同时留在显卡里。
先从权重算起。33.1B 参数按 BF16 存，每个参数占 2 字节，合计大约 66GB。一张家用显卡放不下这么多，官方给的服务端示例用了 4 路张量并行，把每一层的权重矩阵切成四份，四张卡各放一份，合起来才是完整的一份模型。
显存还要留出第二块，KV cache。模型每处理一个 token，都要把它的中间结果存进显存，上下文越长，这块就越大。它跟层数和 KV 头数成正比，按这份 config 推算，512K 全开是 104GB，比权重本身还大。
架构这一版没有做特殊处理。52 层，标准 Llama 结构，56 个查询头配 8 个 KV 头，也就是 GQA。长上下文没有用 YaRN 这类压缩方案，旋转位置编码的基数直接调到 1.2 亿，用来覆盖 524288 个位置。好处是几乎所有推理引擎都能直接跑，不用额外适配。代价是每一层都要做全注意力，每个 token 都得和前面所有 token 算一遍，KV cache 也就省不下来。
所以想在本地跑，多数人会选量化版。全量 BF16 的门槛，普通家用显卡过不去。
跑起来之后，聊天模板里还有几个参数要设。enable_thinking 决定这一轮要不要先生成推理，默认打开。preserve_thinking 决定多轮对话里保不保留前面几轮的思考过程，官方建议在多轮工具调用和办公任务里打开它，代码 Agent 也一并打开。工具调用的格式由 tool_call_format 指定，默认 xml，兼容场景可以换成 json。
图4、官方给的推理参数与三个开关
已经有人跑起来了一位开发者在自己机器上测了显存。他把这个模型和另外两个模型放在一起，比了 128k 上下文下的 KV cache。Muse Glimmer 是 1.6GB，DeepSeek 是 0.5GB，Nanbeige 是 26GB。
速度也没到他预期。prefill 能到 1400 tok/s，但 128k 上下文下生成只有 14 tok/s，缩到 16k 才回到 41 tok/s。他连整套测试都没跑完就停了，按他的说法，写代码这块 Python 还行，其它语言差一截。
图5、一位开发者实测的显存占用与速度
另一位叫 Pratik Gandhi 的开发者，在发布七个多小时后把模型转成 MLX 4-bit，在自己的机器上跑了起来。文件 18.6GB，机器是一台 64GB 内存的 Mac mini（M5 Pro）。
512 token 上下文时 14.4 tok/s，4k 掉到 13.9，16k 是 11.7，32k 是 9.9。从 512 到 4k 这一段，首 token 延迟由 1.65 秒涨到 11.7 秒。
他做了一组质量检查，数学 20 题全对，代码 10 题全对，指令遵循 10 题全对，128k 上下文里藏的信息也全部找出来了。同一台机器上，千问 3.8 27B 是 17.8 tok/s，按他的说法，这个倍数和参数量的倍数基本一致。
图6、开发者在自己机器上的实测数据
服务器那一侧也有人试。另一位用单张 NVIDIA H200 跑了一整套医学考题，答对 88.8%，他还让 10 道题同时流式输出，全部答对。这一项跟智能体和代码无关，看的是通用答题能力。
图7、单张 H200 上的医学考题结果
33B 教师落在 30B 档位上，3B 学生还没出。等蒸馏版落地，本地跑智能体的显存门槛才会降下来。