1. Nanbeige4-3B 到底解決了什么痛點(diǎn)30 億參數(shù)小模型對(duì)標(biāo)千億級(jí)大模型的真實(shí)場(chǎng)景先說結(jié)論Nanbeige4-3B 是一個(gè)參數(shù)量只有 30 億的小語言模型但它在數(shù)學(xué)推理、科學(xué)推理、工具調(diào)用和寫作這幾類任務(wù)上跑出了接近甚至部分超過 300 億參數(shù)級(jí)別模型的成績(jī)。它適合誰適合預(yù)算有限、只有一張消費(fèi)級(jí)顯卡、或者干脆只想走 API 按 token 付費(fèi)的個(gè)人開發(fā)者和中小團(tuán)隊(duì)。你不需要湊一機(jī)八卡也不需要為了跑一個(gè) demo 去申請(qǐng)一筆算力預(yù)算。我先把這件事的背景講清楚。過去兩年大語言模型的發(fā)展基本是參數(shù)軍備競(jìng)賽百億起步、千億常見、萬億也不稀奇。參數(shù)漲上去效果確實(shí)漲但推理成本和微調(diào)成本同步漲。一個(gè) 300 億參數(shù)的模型哪怕用 4bit 量化顯存占用也要十幾 GB 起步想跑長(zhǎng)上下文還得再翻。對(duì)個(gè)人開發(fā)者來說這不是要不要用的問題是用不起的問題。小語言模型SLM因此重新被關(guān)注參數(shù)小、推理快、部署便宜只要能力別掉太多就是普惠落地的關(guān)鍵。Nanbeige4-3B 出自 Boss 直聘南北閣大模型實(shí)驗(yàn)室Nanbeige LLM Lab。它的技術(shù)路徑不是簡(jiǎn)單地把大模型裁小而是在數(shù)據(jù)和訓(xùn)練調(diào)度上做了相當(dāng)細(xì)的活。預(yù)訓(xùn)練階段用了 23T tokens核心是一套 Hybrid 數(shù)據(jù)篩選體系一邊用 20 個(gè)質(zhì)量標(biāo)簽知識(shí)密度、推理密度等對(duì)大模型標(biāo)注加小模型蒸餾的方式給全部語料打 0 到 9 分一邊建了一個(gè)支持百億級(jí)混合檢索文本加向量的數(shù)據(jù)庫用高質(zhì)量種子集做相似度召回。兩路結(jié)合從數(shù)十 T tokens 原始語料里淘出 12.5T 高質(zhì)量數(shù)據(jù)再對(duì)其中 6.5T 高分?jǐn)?shù)據(jù)多輪上采樣最終拼出 23T 訓(xùn)練語料。訓(xùn)練調(diào)度上它用了細(xì)粒度 WSDWarmup-Stable-Decay調(diào)度器。傳統(tǒng) WSD 是預(yù)熱、恒定學(xué)習(xí)率、衰減三段它把恒定階段再拆開前期側(cè)重語料多樣性打基礎(chǔ)后期逐步聚焦高質(zhì)量數(shù)據(jù)。完整訓(xùn)練分四段——Warmup 0.1T、多樣性穩(wěn)定 12.4T、高質(zhì)量穩(wěn)定 6.5T、衰減 4T衰減階段還結(jié)合 ABF 把上下文擴(kuò)到 64K保證論文、代碼庫、思維鏈不被截?cái)唷：笥?xùn)練是四階段遞進(jìn)Cold-Start SFT 用 3000 萬條數(shù)學(xué)、科學(xué)、代碼樣本建立基礎(chǔ)推理能力數(shù)學(xué) 50%、科學(xué) 30%、代碼 20%Overall SFT 拓展人類偏好對(duì)齊和工具調(diào)用然后用旗艦?zāi)Ｐ?Nanbeige3.5-Pro 做蒸餾提出 DPD 算法在 token 級(jí)和 sequence 級(jí)聯(lián)合對(duì)齊最后分階段分領(lǐng)域做 RL數(shù)學(xué)科學(xué)、代碼、寫作開放問答各一段。評(píng)測(cè)結(jié)果是最有說服力的部分。AIME 2024 和 AIME 2025 上它拿到 90.4 和 85.6超過 Qwen3-32B 的 81.4 / 72.9也超過 Qwen3-30B-A3B 的 89.2 / 85.0。GPQA-Diamond 科學(xué)推理 82.2 分對(duì)比 Qwen3-32B 的 68.7 和 Qwen3-30B-A3B 的 73.4。工具調(diào)用 BFCL-V4 比 Qwen3-32B 和 Qwen3-30B-A3B 高出 10% 以上。Arena-Hard-V2 人類偏好對(duì)齊拿到 60.0 分和 Qwen3-30B-A3B 并駕齊驅(qū)。2025 年 11 月的 WritingBench 寫作榜54 個(gè)開源閉源模型里它排第 11多個(gè)創(chuàng)作場(chǎng)景可比肩 DeepSeek-R1-0528 這類千億級(jí)模型。這些數(shù)字說明一件事參數(shù)不是唯一變量數(shù)據(jù)質(zhì)量和訓(xùn)練調(diào)度能把小模型的潛力榨出來。對(duì)開發(fā)者而言這意味著你可以在很低的成本下拿到一個(gè)夠用且好用的推理引擎。接下來的問題就變成——怎么把它接進(jìn)你的工程里用統(tǒng)一通道調(diào)起來快速做效果對(duì)比。這就是下面要講的 TaoToken 統(tǒng)一 API 接入。2. TaoToken 前置準(zhǔn)備統(tǒng)一 API 通道是什么、為什么適合小模型對(duì)比實(shí)驗(yàn)TaoToken 是一個(gè)統(tǒng)一的大模型 API 接入通道官網(wǎng)是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite API 入口是 https://taotoken.net/api 。它的價(jià)值在于你不用為每個(gè)模型單獨(dú)注冊(cè)、單獨(dú)管 Key、單獨(dú)記不同的請(qǐng)求格式而是用一套 Base URL 加一個(gè) Key就能在多個(gè)模型之間切換。對(duì)于我想拿 Nanbeige4-3B 和幾個(gè)大模型做橫向?qū)Ρ冗@種需求統(tǒng)一通道能省掉大量膠水代碼。為什么小模型對(duì)比實(shí)驗(yàn)特別需要這個(gè)因?yàn)閷?duì)比實(shí)驗(yàn)的核心是控制變量。你要保證請(qǐng)求參數(shù)、溫度、max_tokens、提示詞完全一致只換模型 ID。如果每個(gè)模型走不同廠商的 SDK光是字段名差異就能讓你調(diào)半天。統(tǒng)一通道把請(qǐng)求格式拉平你改一個(gè) model 字段就能換模型對(duì)比結(jié)果才有可比性。前置準(zhǔn)備分三步。第一步注冊(cè)并拿到 API Key。打開 https://taotoken.net/api 進(jìn)入控制臺(tái)在 API Keys 頁面創(chuàng)建一個(gè)新 Key。建議按項(xiàng)目命名比如nanbeige-compare方便后面區(qū)分。Key 只在創(chuàng)建時(shí)完整顯示一次復(fù)制后存到環(huán)境變量里別硬編碼進(jìn)代碼。第二步確認(rèn)你要用的模型 ID。TaoToken 的模型列表里可以查到當(dāng)前可用的模型標(biāo)識(shí)Nanbeige4-3B 對(duì)應(yīng)的模型 ID 以控制臺(tái)展示為準(zhǔn)。同時(shí)把你要對(duì)比的大模型 ID 也記下來比如某個(gè) 300 億級(jí)別的模型。這一步別偷懶模型 ID 寫錯(cuò)是最常見的 404 來源。第三步準(zhǔn)備運(yùn)行環(huán)境。Python 3.9 以上裝 openai 兼容 SDK 即可因?yàn)?TaoToken 的接口是 OpenAI 兼容格式。命令如下python -m venv venv source venv/bin/activate pip install openaiWindows 下激活用venv\Scripts\activate。裝完之后設(shè)置環(huán)境變量Linux/macOS 用export TAOTOKEN_API_KEY你的Key export TAOTOKEN_BASE_URLhttps://taotoken.net/apiWindows PowerShell 用$env:TAOTOKEN_API_KEY你的Key $env:TAOTOKEN_BASE_URLhttps://taotoken.net/api這里有個(gè)容易踩的坑Base URL 到底帶不帶/v1。OpenAI 兼容接口的慣例是 SDK 內(nèi)部會(huì)拼/chat/completions所以 Base URL 通常寫到/api或/api/v1這一層具體以文檔為準(zhǔn)。如果你請(qǐng)求返回 404第一件事就是檢查這個(gè)后綴。文檔地址在 https://taotoken.net/api 的文檔入口里面有明確的 Base URL 寫法。還有一點(diǎn)值得說為什么不在本地直接跑 Nanbeige4-3B 而要接 API兩個(gè)原因。一是對(duì)比實(shí)驗(yàn)需要頻繁切換模型本地部署多個(gè)模型顯存吃不消二是 API 通道能讓你先驗(yàn)證效果確認(rèn)值得再考慮本地部署。對(duì)于中小團(tuán)隊(duì)先用 API 做 PoC跑通了再?zèng)Q定要不要自建推理服務(wù)這是更穩(wěn)的路徑。如果你后面確定要長(zhǎng)期跑編碼類或 Agent 類任務(wù)可以看 Coding Plan 那條線成本結(jié)構(gòu)更適合高頻調(diào)用。3. 可復(fù)制配置把 Nanbeige4-3B 接進(jìn) OpenAI 兼容客戶端的完整片段這一節(jié)給的是可以直接復(fù)制粘貼的配置。核心是三件套Base URL、API Key、Model ID。三者缺一不可任何一項(xiàng)寫錯(cuò)都會(huì)在驗(yàn)證階段報(bào)錯(cuò)。先給 Python 的最小可運(yùn)行配置。新建一個(gè)config.py把通道參數(shù)集中管理import os TAOTOKEN_CONFIG { base_url: os.getenv(TAOTOKEN_BASE_URL, https://taotoken.net/api), api_key: os.getenv(TAOTOKEN_API_KEY, ), model_nanbeige: nanbeige4-3b, model_baseline: 你的對(duì)比大模型ID, timeout: 60, }注意model_nanbeige這個(gè)值要以控制臺(tái)實(shí)際展示的模型 ID 為準(zhǔn)上面寫的是占位示例。如果你不確定先去模型列表頁確認(rèn)別直接抄。然后是客戶端初始化。新建client.pyfrom openai import OpenAI from config import TAOTOKEN_CONFIG client OpenAI( base_urlTAOTOKEN_CONFIG[base_url], api_keyTAOTOKEN_CONFIG[api_key], timeoutTAOTOKEN_CONFIG[timeout], )這段代碼的關(guān)鍵在base_url。OpenAI SDK 會(huì)在你給的 base_url 后面拼/chat/completions所以 base_url 不要寫到/chat/completions這一層寫到/api或文檔指定的層級(jí)即可。寫多了會(huì)變成/api/chat/completions/chat/completions直接 404。如果你用 Cline 這類編輯器插件做對(duì)比配置方式類似。Cline 的 API Provider 選 OpenAI Compatible然后填三項(xiàng)Base URL 填https://taotoken.net/apiAPI Key 填你的 KeyModel ID 填nanbeige4-3b以控制臺(tái)為準(zhǔn)。這三件套填完保存Cline 就能通過統(tǒng)一通道調(diào) Nanbeige4-3B。同理如果你用 CC Switch 管理多個(gè)配置也是在這三件套上做切換Base URL 和 Key 不變只換 Model ID。如果你用 Codex 的auth.json方式配置結(jié)構(gòu)大致是這樣字段名以你本地版本為準(zhǔn){ api_base: https://taotoken.net/api, api_key: 你的Key, model: nanbeige4-3b }這里提醒一句auth.json里的 key 是明文別提交到 Git。用.gitignore排除掉或者用環(huán)境變量注入。再給一個(gè) TOML 形式的配置適合放在項(xiàng)目根目錄做多模型管理[provider.taotoken] base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY [models.nanbeige] id nanbeige4-3b provider taotoken max_tokens 4096 temperature 0.6 [models.baseline] id 你的對(duì)比大模型ID provider taotoken max_tokens 4096 temperature 0.6這個(gè) TOML 的好處是把兩個(gè)模型的max_tokens和temperature設(shè)成一樣保證對(duì)比實(shí)驗(yàn)的控制變量。溫度 0.6 是個(gè)折中值數(shù)學(xué)推理可以調(diào)低到 0.2 到 0.3寫作類可以調(diào)到 0.7 到 0.8。但對(duì)比實(shí)驗(yàn)里兩邊必須一致否則結(jié)果沒法歸因。最后強(qiáng)調(diào)一個(gè)細(xì)節(jié)Nanbeige4-3B 支持 64K 上下文衰減階段用 ABF 擴(kuò)展的但你在請(qǐng)求里設(shè)max_tokens時(shí)要注意max_tokens是輸出上限不是上下文上限。上下文長(zhǎng)度由模型本身決定輸入超長(zhǎng)會(huì)報(bào)錯(cuò)。做長(zhǎng)文檔對(duì)比時(shí)先把輸入 token 數(shù)算一下別一上來就塞整本書。4. 驗(yàn)證請(qǐng)求與成功結(jié)果跑通第一次調(diào)用并做模型對(duì)比配置寫完下一步是驗(yàn)證。驗(yàn)證分兩層先確認(rèn)單模型能通再做雙模型對(duì)比。別跳過第一層直接對(duì)比否則報(bào)錯(cuò)時(shí)你分不清是配置問題還是模型問題。第一層最小請(qǐng)求。新建smoke_test.pyfrom client import client from config import TAOTOKEN_CONFIG resp client.chat.completions.create( modelTAOTOKEN_CONFIG[model_nanbeige], messages[ {role: user, content: 用一句話解釋什么是小語言模型。} ], temperature0.6, max_tokens256, ) print(resp.choices[0].message.content) print(usage:, resp.usage)運(yùn)行python smoke_test.py。成功的話你會(huì)看到模型返回的一句話解釋以及 usage 里的 prompt_tokens、completion_tokens、total_tokens?？吹?usage 就說明請(qǐng)求完整走通了通道計(jì)費(fèi)信息也拿到了。如果返回內(nèi)容為空但沒報(bào)錯(cuò)檢查一下max_tokens是不是設(shè)得太小或者模型是不是把內(nèi)容放進(jìn)了 reasoning 字段部分推理模型有單獨(dú)字段。第二層對(duì)比請(qǐng)求。新建compare.py用同一組提示詞分別打兩個(gè)模型from client import client from config import TAOTOKEN_CONFIG PROMPT 一個(gè)水池有甲乙兩個(gè)進(jìn)水管甲單獨(dú)注滿需 6 小時(shí)乙單獨(dú)注滿需 4 小時(shí)。兩管同時(shí)開多久注滿請(qǐng)給出推理過程。 def ask(model_id): resp client.chat.completions.create( modelmodel_id, messages[{role: user, content: PROMPT}], temperature0.3, max_tokens1024, ) return resp.choices[0].message.content, resp.usage.total_tokens for name, mid in [ (Nanbeige4-3B, TAOTOKEN_CONFIG[model_nanbeige]), (Baseline, TAOTOKEN_CONFIG[model_baseline]), ]: answer, tokens ask(mid) print(f {name} (tokens{tokens}) ) print(answer) print()這道題正確答案是 12/5 即 2.4 小時(shí)。跑完之后你重點(diǎn)看三件事答案對(duì)不對(duì)、推理過程是否完整、token 消耗差多少。實(shí)測(cè)下來Nanbeige4-3B 這類經(jīng)過 RL 強(qiáng)化的小模型在數(shù)學(xué)題上往往會(huì)把步驟寫全而部分大模型反而會(huì)跳步。token 消耗上小模型通常更省因?yàn)檩敵龈o湊。第三層工具調(diào)用驗(yàn)證。Nanbeige4-3B 的 BFCL-V4 成績(jī)是它的強(qiáng)項(xiàng)值得單獨(dú)驗(yàn)一下。用 OpenAI 兼容的 tools 參數(shù)tools [{ type: function, function: { name: get_weather, description: 查詢指定城市天氣, parameters: { type: object, properties: {city: {type: string}}, required: [city], }, }, }] resp client.chat.completions.create( modelTAOTOKEN_CONFIG[model_nanbeige], messages[{role: user, content: 北京今天天氣怎么樣}], toolstools, tool_choiceauto, ) print(resp.choices[0].message.tool_calls)成功的話tool_calls里會(huì)有g(shù)et_weather和{city: 北京}。如果tool_calls是 None先確認(rèn)模型 ID 是否支持工具調(diào)用再確認(rèn)tool_choice參數(shù)有沒有被通道透?jìng)?。這一步跑通說明你可以把它接進(jìn) Agent 流程了。驗(yàn)證階段建議記錄一張對(duì)比表把每個(gè)模型的答案質(zhì)量、token 消耗、響應(yīng)耗時(shí)都記下來。這張表比任何評(píng)測(cè)榜單都更貼近你的真實(shí)場(chǎng)景因?yàn)樘崾驹~是你自己的業(yè)務(wù)提示詞。5. 本篇常見錯(cuò)排查401、local proxy failed、reading choices、OAuth 四類報(bào)錯(cuò)對(duì)照接入過程里報(bào)錯(cuò)是常態(tài)關(guān)鍵是能快速定位。下面按真實(shí)遇到的頻率排四類每類給現(xiàn)象、原因、解法。第一類401 Unauthorized?，F(xiàn)象是請(qǐng)求直接返回 401消息里帶 invalid api key 或 authentication failed。原因基本是 Key 問題Key 沒設(shè)置、設(shè)置成了空字符串、復(fù)制時(shí)帶了空格或換行、或者 Key 被刪除/過期。排查順序先echo $TAOTOKEN_API_KEY看環(huán)境變量是否為空再看代碼里os.getenv的默認(rèn)值是不是空串導(dǎo)致靜默失敗最后去控制臺(tái)確認(rèn) Key 狀態(tài)。特別注意從網(wǎng)頁復(fù)制 Key 時(shí)容易帶上首尾空白用.strip()處理一下。還有一種隱蔽情況你在 A 項(xiàng)目設(shè)了環(huán)境變量但在 B 終端窗口跑代碼環(huán)境變量沒繼承也會(huì) 401。第二類local proxy failed?，F(xiàn)象是連接被拒絕或超時(shí)報(bào)錯(cuò)里出現(xiàn) proxy、connection refused、ECONNREFUSED 之類字樣。這類多半是本機(jī)網(wǎng)絡(luò)環(huán)境或代理配置干擾了請(qǐng)求。排查先確認(rèn)你的運(yùn)行環(huán)境沒有設(shè)置HTTP_PROXY/HTTPS_PROXY環(huán)境變量指向一個(gè)不存在的本地端口再確認(rèn)防火墻沒有攔截出站 443。如果你在公司內(nèi)網(wǎng)問一下網(wǎng)管是否需要走統(tǒng)一出口。解法是把無關(guān)的代理環(huán)境變量清掉或者確認(rèn)網(wǎng)絡(luò)策略允許訪問taotoken.net。注意別去折騰任何繞過網(wǎng)絡(luò)策略的手段合規(guī)訪問是前提。第三類reading choices 報(bào)錯(cuò)?，F(xiàn)象是請(qǐng)求返回 200 但解析響應(yīng)時(shí)拋異常典型信息是KeyError: choices或list index out of range日志里能看到 reading choices 相關(guān)字樣。原因通常是響應(yīng)體結(jié)構(gòu)和預(yù)期不符可能是模型返回了錯(cuò)誤對(duì)象比如額度不足、模型不存在但 HTTP 狀態(tài)碼仍是 200也可能是流式響應(yīng)沒處理完就解析。排查先把原始響應(yīng)打印出來print(resp.model_dump())看里面到底有沒有 choices。如果沒有看有沒有 error 字段。常見觸發(fā)是模型 ID 寫錯(cuò)通道返回了一個(gè)錯(cuò)誤 JSON 而不是標(biāo)準(zhǔn)補(bǔ)全結(jié)構(gòu)。解法是核對(duì)模型 ID并在代碼里加防御先判斷resp.choices是否存在再取[0]。第四類OAuth 相關(guān)報(bào)錯(cuò)?，F(xiàn)象是提示 token 過期、refresh failed、unauthorized_client 之類。這類一般出現(xiàn)在你用某個(gè)客戶端工具比如帶 OAuth 登錄的編輯器插件而不是純 API Key 時(shí)。原因是你混用了兩種認(rèn)證方式工具期望走 OAuth 登錄流程但你填的是 API Key或者反過來。排查確認(rèn)當(dāng)前工具的認(rèn)證模式是 API Key 還是 OAuth兩者別混。如果你用的是 OpenAI Compatible 模式就老老實(shí)實(shí)填 Base URL、Key、Model ID 三件套別去點(diǎn) OAuth 登錄按鈕。解法是清掉工具的登錄緩存重新按 API Key 模式配置。再補(bǔ)一個(gè)高頻但不在四類里的404 model not found。這個(gè)幾乎都是模型 ID 拼寫問題或者你用的模型 ID 在當(dāng)前通道未開通。去控制臺(tái)模型列表核對(duì)一遍復(fù)制粘貼而不是手打。排查的通用心法是先看 HTTP 狀態(tài)碼分層4xx 是請(qǐng)求問題5xx 是服務(wù)端問題再看響應(yīng)體里的 error message最后才去翻代碼。很多人一上來就改代碼結(jié)果問題在 Key 上白折騰半小時(shí)。6. 從驗(yàn)證到落地把 Nanbeige4-3B 用進(jìn)你的真實(shí)工作流跑通驗(yàn)證只是起點(diǎn)真正有價(jià)值的是把它嵌進(jìn)日常工作流。這里給幾條實(shí)操建議都是圍繞低成本、可對(duì)比、能持續(xù)這三個(gè)關(guān)鍵詞。第一條先做任務(wù)分層再選模型。不是所有任務(wù)都值得上大模型。把任務(wù)分成三類高難度推理數(shù)學(xué)證明、復(fù)雜代碼重構(gòu)、中等任務(wù)摘要、改寫、信息抽取、輕量任務(wù)分類、格式化、簡(jiǎn)單問答。Nanbeige4-3B 在數(shù)學(xué)和工具調(diào)用上的表現(xiàn)足以覆蓋第一類的大部分場(chǎng)景中等和輕量任務(wù)更是綽綽有余。你可以用統(tǒng)一通道寫一個(gè)路由層輕量任務(wù)直接打 Nanbeige4-3B只有它連續(xù)失敗或置信度低時(shí)才升級(jí)到大模型。這樣成本能壓下來一大截。第二條建立自己的小評(píng)測(cè)集。別迷信公開榜單你的業(yè)務(wù)提示詞才是唯一標(biāo)準(zhǔn)。挑 30 到 50 條真實(shí)任務(wù)固定提示詞和參數(shù)每次換模型或換版本都跑一遍記錄正確率、token 消耗、耗時(shí)。這個(gè)評(píng)測(cè)集放在 Git 里版本管理比任何口頭結(jié)論都可靠。Nanbeige4-3B 的寫作能力在 WritingBench 排到第 11但你的業(yè)務(wù)文體可能和榜單不同自己測(cè)過才算數(shù)。第三條注意上下文和輸出的預(yù)算管理。Nanbeige4-3B 支持 64K 上下文但長(zhǎng)上下文意味著更高的 prompt token 成本。做長(zhǎng)文檔處理時(shí)先做分塊和檢索只把相關(guān)片段喂進(jìn)去別整篇塞。輸出側(cè)用max_tokens卡上限避免模型啰嗦。工具調(diào)用場(chǎng)景里把工具描述寫精簡(jiǎn)每個(gè)工具的 description 控制在兩行以內(nèi)能顯著降低 token 消耗。第四條Agent 場(chǎng)景優(yōu)先考慮 Coding Plan。如果你要把 Nanbeige4-3B 接進(jìn)編碼助手或自動(dòng)化 Agent調(diào)用頻率會(huì)很高按量付費(fèi)可能不如套餐劃算。Coding Plan 那條線適合長(zhǎng)期高頻的編碼和 Agent 任務(wù)具體額度去控制臺(tái)看。選之前先估算你的日均調(diào)用量用驗(yàn)證階段記錄的 token 數(shù)據(jù)乘一下再對(duì)比套餐價(jià)格別拍腦袋。第五條保留降級(jí)路徑。任何單一通道都有波動(dòng)風(fēng)險(xiǎn)工程上要留后手。你的客戶端封裝里應(yīng)該有一個(gè)模型列表主模型失敗時(shí)自動(dòng)切備用模型。統(tǒng)一通道的好處是切換只改 model 字段不用改請(qǐng)求邏輯。把重試和降級(jí)寫成通用邏輯別散落在業(yè)務(wù)代碼里。最后說一個(gè)我踩過的坑早期做對(duì)比實(shí)驗(yàn)時(shí)我給兩個(gè)模型用了不同的 temperature結(jié)果小模型答案更穩(wěn)、大模型更發(fā)散我一度以為是模型能力差異后來發(fā)現(xiàn)是參數(shù)沒對(duì)齊。對(duì)比實(shí)驗(yàn)的第一原則是控制變量提示詞、溫度、max_tokens、系統(tǒng)消息全部一致只留 model 一個(gè)變量。這個(gè)習(xí)慣建立起來之后你得到的每一個(gè)結(jié)論才站得住。Nanbeige4-3B 這類小模型的意義不是取代大模型而是讓夠用這件事變得便宜。把統(tǒng)一通道配好把評(píng)測(cè)集建起來把路由和降級(jí)寫進(jìn)工程你就能用很低的成本把這件事跑起來。剩下的就是持續(xù)用真實(shí)任務(wù)去校準(zhǔn)讓數(shù)據(jù)告訴你哪個(gè)模型該出現(xiàn)在哪個(gè)位置。