Nemotron 3.5 Bolt E4B 4GB：實際出貨了什麼，以及為何這個名稱會誤導人

NVIDIA-Nemotron-3.5-Bolt-E4B-4GB 於 2026 年 10 月 23 日在 Hugging Face 上線，而關於它首先值得說的是算術：檔案大小是 6.18GB。名稱寫的是 4GB。這兩個數字都是真的，它們衡量的是不同的事物，而兩者之間的差距是本次發布中最有用的一項事實。

NVIDIA 的技術部落格指出，4GB 是該模型目標工作負載的預期記憶體佔用範圍——也就是應用程式同時在旁運行時，模型應佔用的預算。這不是參數量，也不是下載大小。檢查點本身總計為 8B，有效參數為 4B，以 Gemma-4-E4B-it 為基礎進行後訓練，並且僅以兩種精度發佈：15.88GB 的 BF16 版本與 6.18GB 的 Q4_K_M GGUF。如果你是為了尋找一個可直接放進裝置的 4GB 檔案而來，儲存庫裡並沒有這樣的檔案。

這件事值得直說，因為這次發布的其他部分異常清晰易讀。模型卡很詳細，技術報告已公開，實測延遲表涵蓋四款裝置。欠缺的是獨立驗證，而模型卡本身也這麼說。

根據公開資訊重建的發布內容

這個沒有獲得正式發表。它只得到一則註腳，然後是一篇部落格文章。

• 2026 年 10 月 5 日 — Q4_K_M 與 BF16 版本的 Hugging Face 儲存庫已建立。兩者均尚未填入權重。

• 2026年10月15日 — NVIDIA 宣布推出 Nemotron 3.5 系列：Super VL 120B-A12B 與 Bolt 74B-A9B 24GB，兩者皆於當天上市。E4B 只獲得兩句話和一個日期：將於10月23日推出。

• 2026 年 10 月 23 日 — Q4_K_M 與 BF16 權重已發布，模型卡上線，NVIDIA 研究實驗室也發布技術部落格與技術報告。這次沒有企業新聞稿，而 10 月 15 日公告後隨之而來的發布報導，並未在此次發布中再次出現。

所以「低調推出」是準確的，但「秘密」則不然。NVIDIA 為這個模型命名、標註日期，並在當天就把它好好地記錄在文件中。它沒做的，是把 E4B 擺在那些曾報導過其同系列機型的同一批記者面前。對最初幾週讀到本文的人來說，實際後果是：以下幾乎每一項說法都只能追溯到同一個來源：NVIDIA。

四 GB 是預算，不是下載

只要查看儲存庫而不是名稱，已發布的檔案大小就明確無歧義。

• Q4_K_M GGUF — 6,180,446,208 位元組，以十進位計算為 6.18GB，位於單一檔案中，檔名為 Nemotron-3.5-Bolt-E4B-Q4_K_M.gguf。

• BF16 safetensors — 15,882,494,698 位元組，即 15.88GB，位於單一分片，外加一個 110MB 的凍結 shared-KV 檔案。

• 沒有 4GB 的產物 — 儲存庫中沒有更小的量化版本，而模型卡並未發佈符合名稱中數字的檔案。

NVIDIA 確實有公開的，是在四台裝置上進行的 batch-1 llama.cpp 測量，而 4GB 的說法正是在那張表中變得具體：

• RTX 5070 12GB — 3.5 至 4.3GB 的 VRAM，首個 token 時間 548 至 1,238ms，每秒 106.2 至 133.4 個 token。

• RTX Spark 32GB — VRAM 3.1 至 4.2GB，首個 token 耗時 930 至 1,988 毫秒，每秒 52.0 至 67.0 個 token。

• Jetson Orin Nano 8GB — 4.2 至 4.9GB 的 VRAM，產生首個 token 需 5,785 至 6,259ms，每秒 13.0 至 15.5 個 token。

• Jetson AGX Orin 32GB — 4.2 至 5.0GB 的 VRAM，首個 token 耗時 3,687 至 4,091ms，每秒 20.3 至 24.0 個 token。

VRAM 數字低於 6.18GB 的檔案大小，這意味著在那些執行中，執行環境並未將整個檔案常駐在 GPU 上。這張顯示卡並未解釋其機制，而這裡正是應該避免自行臆測機制的好地方：記憶體映射權重、部分卸載與 KV 快取大小都會相互作用，而 NVIDIA 尚未公布其分配方式。可以確定的是，4GB 的範圍是特定硬體在特定執行環境下測得的結果，而不是下載檔案本身的屬性。

Orin Nano 那一列若賣點是語音助理，值得多看兩遍。每秒十三到十五個 token、首個 token 要將近六秒，作為嵌入式代理還算堪用，作為即時對話夥伴卻很糟糕。RTX 5070 那一列則恰好相反：在桌上型 GPU 上，快到足以應付互動使用。

NVIDIA 在 Gemma 4 E4B 中實際改了什麼

架構是完全沿用的。這是 Gemma-4-E4B，一個總計 8B 的混合模型、有效參數為 4B，而 NVIDIA 的貢獻在於後訓練，而非新的主幹架構。模型卡將這項工作列為透過 NeMo-RL 與 NeMo-Gym 進行的可驗證獎勵強化學習與人類回饋強化學習，涵蓋工具呼叫與結構描述、指令遵循與層級結構、結構化輸出、自由形式格式化，以及生成式獎勵建模。訓練批次中非推理與推理樣本的比例為 2:1，而 NVIDIA 提高了長度懲罰以控制冗長程度——這個細節稍後會出現在基準測試表中。

Q4_K_M 版本是使用 llama.cpp 製作的，並以約一百萬個 RL rollout 的 token 進行 imatrix 校準。另有一個用於推測性解碼的 DFlash drafter，NVIDIA 表示其吞吐量比 Gemma-4-E4B 原本的多 token 預測 drafter 高出最多 21%。該 drafter 是獨立儲存庫，檢查時對匿名請求傳回 HTTP 401，因此請將其視為額外的存取步驟，而非當天即可下載。

兩個聊天範本切換開關承擔了大部分的行為層面作用。enable_thinking會開啟或關閉推理，並接受執行階段的思考預算；conversational_mode會加入口語對話的系統指令，以產生簡短、少格式化的回覆。第二個開關正是關鍵線索。這個模型是為了對話而打造，不是為了用分析填滿上下文視窗。

上下文長度為輸入 64K、輸出 64K。語言涵蓋範圍在 Hugging Face 中繼資料中為 34 種，在技術部落格中則為 35 種——這是個小不一致，並非實質問題；而訓練後卡片將英文、法文、德文、義大利文、日文、西班牙文和中文列為主要語言。

授權條款是一組堆疊，而非單一文件：NVIDIA 的貢獻採用 OpenMDW-1.1，Gemma 4 元件則採用 Apache 2.0。模型卡指出，此模型已可供商業或非商業使用。OpenMDW 屬於寬鬆式授權，但未經 OSI 核准，這一點對法務團隊比對開發者更為重要。

對照表中所列模型來解讀的基準測試表

NVIDIA 在一致的 NeMo-Gym 測試框架下，以 Gemma4 E4B-it、Qwen3.5 4B 及自家的 Nemotron 3 Nano-4B 對該模型進行評測。以下每個數字皆為廠商回報且未經重現。模型卡指出這些數字「可能與廠商自行回報的數字不同」，這既是誠實的告誡，也提醒比較對象是由 NVIDIA 選定的。

勝出點集中在對話與控制：

• RoleBench Custom — Bolt E4B 拿下 67.05，對比 Qwen3.5 4B 的 53.66、Gemma4 E4B-it 的 49.95，以及 Nano-4B 的 12.02。這是角色人格基準測試，而領先幅度是整張表裡最大的。

IHEval，指令階層——84.79 對比 60.57、67.04 與 51.31。在這個規模下，領先最接近的競爭對手達 17 個百分點並不尋常。

• When2Call Multi-Turn — 63.36，對比 Qwen3.5 4B 的 37.85、Gemma4 的 62.90，以及 Nano-4B 的 27.70。知道何時不呼叫工具，既是一項代理技能，也是一項對話技能。

RelyToolBench — 63.16 相較於 43.35、61.60 與 41.20。以工具輸出為依據，這又是一項與對話相關的技能。

• MultiChallenge — 53.10 對 51.76、42.08 與 35.30。在多輪挑戰處理上險勝。

損失同樣明顯，而如果你要的是行動者而非角色，真正重要的正是這些損失：

• Tau2-Bench — 55.10，對比 Qwen3.5 4B 的 75.06。這是在多輪代理式任務完成上的 20 分差距，再怎麼優秀的人設品質也無法彌補。

• 64K 下的 RULER — 86.99，對比 Qwen3.5 4B 的 95.15 與 Nano-4B 的 91.51。此模型可接受 64K 的上下文；但它在整個上下文範圍內檢索資訊的可靠性不如同級模型。

• LongBench v2 於 48K — 50.50，對比 Qwen3.5 4B 的 59.93。長文件推理方面也是同樣情況。

• BFCL-v3 — 68.51，對比 Qwen3.5 4B 的 70.95。在函式呼叫上略有落後，但仍勝過 Gemma4 的 66.39。

• EQ-Bench v3 — 39.40，相較於 Gemma4 E4B-it 的 41.17。這是唯一一項由母模型勝過子模型的情緒智力項目。

Q4_K_M 那一欄比一般量化表更有意思。壓縮並未一致地造成準確率損失：MultiChallenge 從 53.10 上升到 55.60，RoleBench 從 67.05 上升到 71.21，ToolSandbox 從 68.77 上升到 74.13，RelyToolBench 從 63.16 上升到 69.29。它在 Tau2 上從 55.10 下降到 52.32，在 LongMemEval 上從 72.10 下降到 69.92，在 RULER 上從 86.99 下降到 85.76。當校準資料來自模型自身的 RL rollouts 時，一個能提升多項對話分數的四位元版本是合理的，但這仍然是廠商量測，而且 4B 模型中的基準測試層級雜訊大到足以讓我們不應把這些差異解讀為精度階梯。

有兩列值得單獨標示。Brevity Bench 和 When2Call Multi-Turn 是 NVIDIA 描述為填補現有基準測試缺口的評測，而部落格表示它們將於日後發布。它們目前無法獨立重現——這對 Brevity 尤其重要，因為正是那一列承載了「輸出詞元更少」的敘事。

NVIDIA 的頭條說法是，該模型平均比 Nemotron 3 Nano-4B 好約 40%，並比同類模型好約 10%，而在啟用推理的比較中，輸出 token 數最多可減少 80%。80% 這個數字是關於冗長程度的說法，而非準確度的說法，且與 Brevity Benchmark 的 82.52 分相符——而這項基準正是 NVIDIA 納入自家評測套件中的。方向可以認真看待，具體百分比則輕鬆看待即可。

儲存庫不會告訴你的事

這張卡片對自身的不足直言不諱，而這些不足值得一一列出，因為它們界定了此次發布能支撐多大的信心。

• 沒有獨立評估。截至撰寫本文時，Artificial Analysis 尚未提供 E4B 的模型頁面，且尚無第三方公開發表對這張 21 列基準測試表的重現結果。

• 沒有託管價格。卡片將 Build.NVIDIA.com 上的一項刊登日期標為 10 月 23 日，但無論在該處或卡片中，都沒有公布每 token 價格。如果你想要 API，你是在議價或使用免費方案，而不是在閱讀費率表。

• 部署被標記為「llama.cpp（配方待補）」，儘管快速入門包含可用的 llama.cpp 指令。這是文件上的矛盾，而非技術上的矛盾，但這正是會讓自動化部署管線出錯的那類問題。

• 4GB 目標並未以檔案形式展示。實測的 VRAM 用量範圍才是證據；下載檔案為 6.18GB。

• 安全、偏誤、可解釋性與隱私等子卡以獨立檔案形式存在。本文並未稽核這些子卡，目前也尚無任何獨立機構進行稽核。

這些都不會讓這次發布變得不可信，只會讓它來得太早。由訓練該模型的團隊撰寫的模型卡，是現有關於模型用途的最佳說明；但這並不是模型真的能做到的證據。

本地 4B 模型的極限在哪，以及該在它背後搭配什麼

對這類模型而言，誠實的架構是分離式的。Jetson 或 RTX 顯卡上的 4B 對話檢查點非常擅長反射層：喚醒詞回應、角色對話、簡短工具呼叫、輸入接地，以及介面中無法承受網路往返的部分。它並不是你希望用來回答需要 200K 上下文或十步代理式計畫的問題的東西，而它自己的基準測試表也這麼說。

這就讓每個部署面臨第二個問題：本地模型不該處理的請求該由什麼來接手。透過 OrcaRouter 把託管模型放在同一個應用程式背後，意味著 200 多個模型共用一個 API、以供應商定價零加成計費，以及自動容錯移轉——當供應商服務品質下降時便會啟動，因此升級路徑是一項路由決策，而不是第二套 SDK、第二把金鑰和第二份帳務關係。本地模型仍是快路徑；託管模型則是在 E4B 從未受訓處理的情況下的備援。

什麼會改變這幅景象？

三件事，按實用性由高到低排序。在同一套測試框架上進行獨立基準測試，將能確定這個偏重對話的設定檔能否在 NVIDIA 的評估之外依然成立。發佈一個 4GB 或更小的成品，會讓這個名稱名副其實。而為 Build 端點定價，將使這個模型從一個下載項目變成可互相比較的服務。

在那之前，正確的解讀範圍狹窄但有用：{{1}}NVIDIA{{/1}} 對 {{2}}Gemma 4 E4B{{/2}} 進行後訓練，將其變成明顯更好的對話型小型模型，並在同一份文件中公布證據與不足之處，且在該系列發布一週後幾乎無聲無息地推出。名稱中的 4GB 是實測執行時可達到的目標，而下載檔則達不到。請以 6.18GB 規劃儲存空間，並依你實際擁有的裝置，將預期設在每秒 13 到 133 個 token。