Nvidia Nemotron 3.5 Bolt 以 4GB 預算瞄準本地助理

Nvidia 於 10 月 23 日推出 Nvidia Nemotron 3.5 Bolt E4B 4GB，瞄準本地助理，同時為周邊應用程式保留記憶體空間。此版本將一項實際限制置於主張的核心：對話模型必須與其運行裝置上的其他程式共用資源。其約 4GB 的目標適用於特定工作負載，而非為每一段對話設定通用上限。

這項區別對於在本地處理與雲端服務之間作選擇的開發者尤其重要。即使模型能裝入裝置，仍須為語音處理、應用程式狀態及其他軟件預留空間。作為 Nvidia 模型基礎的 Google Gemma 4 E4B 亦提供直接比較的基準：Nvidia 額外訓練帶來了甚麼改變？

商業層面的問題在於，較小型的對話元件是否能令完整助理更容易推出。可下載的權重讓開發者有具體可評估的對象。記憶體消耗、回應延遲及動作的可靠性，將決定最終產品是否值得在電腦或嵌入式裝置中長期保留一席之地。

Nvidia Nemotron 3.5 Bolt 將應用程式預算置於核心

Nvidia 在其 Nemotron 模型系列中推出這款較小模型，並同時發布面向不同部署需求的較大型版本。其於 10 月 15 日的公告安排 E4B 版本在 10 月 23 日推出。隨後的發布將該公告化為開發者可下載及測試的模型。

關鍵改變在於，這款對話模型的定位，是圍繞一個完整本地應用程式可負擔的資源而設。

這種定位將評估焦點從孤立的聊天機械人移開。助理必須理解要求、查閱應用程式資訊，並在不壓垮主機裝置的情況下提供有用回應。除了準確度與行為之外，模型的資源需求亦成為產品規格的一部分。

對開發者而言，這帶來不同的起始問題。團隊不再只問哪個模型能產生最令人印象深刻的答案，而是問哪個模型能支援預期的互動。答案取決於還有甚麼會同時運行，以及介面可容忍多少延遲。

例如，桌面助理可能在用戶編輯文件或參與通話時運作。嵌入式助理則可能與監察周遭環境的軟件共用資源。這些只是示例部署情境，並非證明某一特定商業產品已在使用 Bolt。

在任何一種情況下，若將所有可用記憶體都用於語言生成，周邊應用程式便會立即面臨問題。若每當其他元件忙碌時介面便變得不可靠，額外的模型能力價值亦有限。

因此，Nvidia 的做法促使開發者更精確地界定其助理。簡短指令介面與開放式研究夥伴有不同需求。將兩者視為可互換的對話工作負載，對硬件規劃幫助不大。

此次發布亦改變買家在評估時應提出的要求。在其他方面閒置的電腦上示範，只能證明基本功能可運作。與預定應用程式一同示範，才能證明建議的部署是否具備合理的運行餘裕。

這項區別並不代表雲端處理已過時，而是令部署位置的決定更具針對性。團隊可評估哪些互動應在用戶附近處理，哪些則值得使用遠端服務，而非預設採用其中一種路線。

當助理的動作與資訊本已存在於裝置上時，本地助理可以很有吸引力。然而，僅憑部署位置並不能證明其實用性。應用程式仍須具備存取控制、最新資訊，以及對成功完成任務的清晰定義。

此次發布的即時價值，在於開發者可透過可用模型研究這些問題。更廣泛的重要性則取決於應用程式團隊能否將受限的語言元件轉化為可靠的介面。

4GB 目標會隨對話而改變

Nvidia 的記憶體與延遲測量顯示，不應按產品名稱字面理解其限制。在 RTX 5070 上，短工作負載使用了 3.5GB 圖形記憶體；保留 32,000 個 token 上下文的工作負載則使用了 4.3GB。

Token 是模型處理的文字單位。上下文是在提出要求時可供使用的資訊，包括指令與對話歷史。當助理累積更多內容時，即使底層模型不變，其運行條件亦會改變。

Nvidia 在 Jetson Orin Nano 上測得這些工作負載分別使用 4.2GB 及 4.9GB。其測試使用以較低精度儲存模型數值的壓縮 Q4_K_M 模型，並僅有一個活躍工作階段。在解讀結果時，這些條件相當重要。

約 4GB 的部署目標是有用的規劃資訊，但並不保證能嚴格維持在 4GB 限制以內。

當團隊已擁有資源受限的硬件時，這項區別尤其相關。模型名稱無法證明其與該裝置相容。可用記憶體、軟件設定及預期對話長度，都必須與建議部署相符。

買家亦不應將模型記憶體視為整個應用程式的完整需求。語音元件、用戶介面、儲存資訊及連接工具均會帶來額外需求。能成功處理初始要求的助理，可能在長時間工作階段後表現不同。

這就產生了應保留多少活躍歷史的產品決定。保留每次交流固然方便，但可能增加資源壓力。移除較舊內容可減低壓力，卻會帶來助理應記住甚麼的問題。

摘要引入另一項選擇。它們可在不保留每則原始訊息的情況下保存選定資訊，但摘要步驟可能遺漏細節。開發者必須決定哪些事實值得長期儲存，哪些只屬於當前互動。

對用戶而言，這項區別解釋了長對話與持續記憶系統為何是不同功能。助理可保留近期對話，卻未必維持過往工作的可靠記錄。反過來說，組織完善的資訊庫可支援有用的回憶，而無須在每次要求中載入所有內容。

這種關連對圍繞個人知識庫建立的應用程式尤其重要。語言模型負責理解及生成回應，而周邊產品決定其檢索及保存哪些資訊。

當助理接收冗長工具結果時，同樣會出現預算問題。文件搜尋可能回傳遠多於用戶原始問題所包含的資訊。應用程式此時必須先挑選相關證據，再要求模型回應。

因此，記憶體測量應配合真實使用模式。簡短問候幾乎無法說明一個預期要檢視文件、維持指令及處理重複動作的助理。工作負載應貼近產品的預定工作階段。

因此，對 Nvidia 定位最站得住腳的解讀是有條件的：它為特定對話任務提供緊湊的運行目標。團隊仍須確認完整應用程式在持續使用下所需的空間。

只有在動作維持正確時，較短答案才有幫助

Nvidia 的模型規格描述了一個文字輸入、文字輸出的模型，合共有 80 億個參數，當中 40 億個為有效參數。參數是塑造模型行為的已學習數值。此版本支援 64,000-token 上下文，並提供推理及對話回應的控制選項。

對話模式鼓勵更適合語音互動的短回應。推理控制讓開發者調整模型處理要求的方式。這些選項為應用程式團隊提供行為上的選擇，但每一項選擇仍須在預定任務中評估。

當簡潔可減少等待時間，同時不刪除用戶作決定所需資訊時，簡短才有價值。

以更改裝置設定的示例要求為例。在應用程式核實更改後，有用的回應可能是一句簡潔確認。冗長解釋會佔據用戶注意力，卻不一定改善結果。

現在考慮涉及多個可能設定的模糊要求。最短的答案可能掩蓋不確定性，或觸發錯誤動作。在這種情況下，提出澄清問題比優化即時完成更能服務用戶。

這正是對話助理的內在張力。自然對話重視回應速度，而具後果的動作需要足夠資訊。開發者需要模型辨識何時適合簡短回答，何時必須再進行一次交流。

工具呼叫，即模型要求應用程式執行某項功能，令這項區別變得具體。模型可以提出動作建議，但周邊軟件決定該動作是否有效及獲准。產生看似合理的要求，只是完成任務的一部分。

應用程式亦須區分嘗試執行的動作與已確認結果。若工具失敗，助理應準確描述該失敗。自信地宣稱完成，不能取代要求更改確已發生的證據。

這些要求令整合層承受壓力。開發者需要清晰的工具描述、明確結果，以及一致地處理無法取得的資訊。否則，即使對話行為很有能力，仍可能帶來不可靠的產品體驗。

Nvidia 的模型卡亦說明為何比較須配合任務。在其全精度客戶任務評估中，Qwen 3.5 4B 獲得 75.06 分，相比 Bolt 的 55.10 分。這些是 Nvidia 測得的結果，而非獨立確認其在買家應用程式中的表現。

這項比較令 Qwen 成為評估組合中可信的選項。它並不能證明每個助理都應使用 Qwen，正如 Bolt 的定位亦不能證明其具備普遍優勢。產品實際的工具定義與成功條件仍是決定因素。

Google 亦透過 Gemma 4 基礎模型提供另一個相關參考。Google 表示，其較小型 Gemma 模型專為本地執行而設，功能超越一般文字聊天。因此，應以一個本已具備能力的起點來評估 Nvidia 的發布。

這種關係令比較比單純的品牌競爭更有意思。Nvidia 正將既有基礎調整至特定應用程式輪廓。真正相關的問題是，這些改變是否改善了開發者實際需要的互動。

合理的評估應比較相同的請求、工具結果與應用程式限制，也應涵蓋需要釐清或拒絕執行的請求。與成功完成任務一樣，適當克制亦應納入助理評估。

對企業買家而言，這不僅影響工程，也影響採購。一般基準測試平均值有助縮小選擇範圍，但不能界定驗收標準。採購決策需要與員工將委派的工作直接相關的證據。

因此，小型對話模型最有力的理據在於具體應用：它能在可接受的資源預算內處理一組明確互動，同時保留令這些互動值得信賴的檢查機制。

本地部署將更多責任轉移至產品之中

這次發布讓開發者能更自主決定對話元件在何處運行。這種控制權亦擴大了應用程式團隊需要承擔的決策範圍。模型選擇、軟件更新、資訊存取與故障復原，均成為彼此相連的產品責任。

本地執行改變的是部署邊界；它本身並不能解決私隱、權限或可靠性問題。

在電腦上運行的助理，若其工具容許，仍可調用遙距服務。它亦可能透過日誌或不當回應洩露敏感資訊。真正相關的私隱邊界取決於完整工作流程，而非僅僅語言生成所在的位置。

對職場採購者而言，這意味著要問清楚助理能讀取甚麼，以及能修改甚麼。可存取文件，並不代表理所當然可存取每一個資料夾。獲准草擬訊息，也不代表理所當然獲准發送訊息。

這些區別應在介面中保持清晰可見。使用者需要明白助理是在提出建議、準備操作，還是正在執行操作。即使底層模型表現一致，含糊的狀態訊息亦可能削弱信心。

本地部署亦帶來更新方面的問題。產品團隊需要一套方法，在替換使用者倚賴的模型前，先評估新模型版本。一項任務上的改進，可能伴隨其他方面行為的改變，因此可重複的應用程式測試相當重要。

發布提供的可下載格式有助進行比較，但可取得性與營運成熟度並不相同。團隊仍須了解封裝方式、支援的設定，以及重現所選配置所需的工作。

回應時間亦帶來另一項重要限制。Nvidia 表示，在其短工作負載中，RTX 5070 的首個 token 時間為 548 毫秒；在 Jetson Orin Nano 上，該數字為 5,785 毫秒。

首個 token 時間衡量的是生成開始前的延遲，並不涵蓋完整的語音互動。聆聽、將語音轉換成文字、執行工具及產生音訊，都可能各自增加延遲。

這些數字說明，「本地」不應成為「即時」的同義詞。本地部署雖可避免部分遙距通訊，但硬件仍決定模型處理請求的速度。完整互動需要在目標裝置上量度。

在草擬文件時可接受的延遲，在語音交流中可能顯得彆扭。同樣地，使用者對可見進度指示器的容忍度，與面對無從解釋的沉默並不相同。產品設計與模型表現需要一併評估。

開發者亦應區分示範成功與可靠復原。預先準備的互動可以展示預期路徑；可用的助理則必須能處理缺失資訊、中斷的操作，以及在對話途中改變的請求。

一個說明性的檔案搜尋助理足以闡明問題。找出相關文件固然有用，但產品亦必須處理過時副本與不確定的匹配結果。模型不應將不完整的搜尋結果轉化為毫無根據的確定陳述。

這正是知識管理與本地 AI 討論產生關聯之處。整理資訊並保留其來源，可改善助理接收到的材料。這無法保證回應正確，但可為應用程式提供更清晰的核查基礎。

解讀基準測試比較亦有實際限制。Nvidia 的評估描述的是特定條件下的行為，並不能證明開發者改動指令、工具或資訊來源後，自訂助理會如何表現。

獨立的問題依然存在：這些結果能以多高的一致性轉移至完整產品？要回答這個問題，需要可重現的應用程式證據，而不是在發布公告上使用更強烈的措辭。

真實助理揭示共享資源問題

Nvidia 的 Reachy Mini 示範，將 Bolt 的對話及行動處理，與 Cosmos 3 Edge 在 Jetson Orin Nano 8GB 上的視覺理解能力結合。該公司亦展示一個遊戲角色使用應用程式工具完成一段交流。這些示範說明了其預期的部署模式。

模型的價值取決於其周邊系統的行為，尤其當多個元件共享有限資源時。

機械人需要的不只是流暢回應。其應用程式必須將對話與環境資訊及獲准動作連接起來。每個元件都影響整體體驗，任何一處故障都可能中斷互動。

遊戲角色面對相近挑戰。對話聽來可以很有說服力，但應用程式狀態可能講述另一個故事。有用的角色需要令其陳述與行動，持續符合遊戲實際執行的規則。

這些例子令資源論點更容易理解。語言模型只是更大系統中的一個參與者。為其他元件保留空間，只有在這些元件能於產品效能要求內協同運作時才有價值。

同樣邏輯亦適用於桌面軟件中較不顯眼的助理。模型可能協助理解請求，搜尋功能找出證據，而應用程式程式碼則執行所要求的變更。使用者體驗到的是合併後的結果。

這為較小型模型創造了有意義的機會。界定嚴謹的應用程式能提供不受限制的聊天機械人所欠缺的結構。它可提供相關操作、供應最新資訊，並在向使用者呈現結果前核實成效。

不過，應用程式結構亦帶來整合工作。開發者必須決定如何呈現目前狀態，以及如何報告變更。描述不佳的工具，會令任何模型都難以一致地理解原本合理的使用者請求。

因此，對買家而言，有用的示範應包括變化中的情況。助理應遇到無法取得的項目、不完整的請求或失敗的操作。其回應比另一段成功的預備交流更能揭示產品準備程度。

助理的記憶行為亦值得在這些示範中留意。它會否保留已修正的偏好？它能否區分較早前的假設與後來的指令？它能否準確說明哪些資訊仍無法取得？

這些問題直接源於建議的使用情境。對話式產品會讓使用者在先前交流的基礎上繼續進行；若這種連續性中斷，使用者便要重複指令，或手動核查助理是否理解正確。

評估亦應包括周邊工作負載。若桌面模型在沒有主應用程式的情況下測試，便留下重要缺口；若機械人模型在沒有感知元件的情況下測試，也有相似缺口。

這正是 Nvidia 這次發布為市場帶來的實際壓力。模型供應商需要清楚說明資源條件；應用程式供應商則需要展示，其組裝後的產品能在這些條件下維持反應迅速及準確。

這次發布並未解決該工程問題。它為團隊提供了一個更聚焦的元件以供研究，其部署要求亦促使團隊直接針對自身應用程式的資源預算進行測試。

未來三個月值得留意的事項

第一個訊號，是獨立重現完整助理工作負載。具參考價值的報告應披露硬件、模型設定、對話長度，以及同時運行的其他軟件；它們亦應量度整段工作階段中的記憶體使用量，而非只記錄初始狀態。

來自完整應用程式的證據，將比另一個孤立模型示範更具分量。

若這些報告能重現實際記憶體使用情況，同時保持任務品質，Nvidia 的部署論點便會更有力。若資源需求在日常互動下急劇上升，適用的應用程式範圍便會收窄。無論結果如何，均有助開發者作出更現實的選擇。

獨立的延遲量度亦應配合這項工作。有用的報告應追蹤使用者的完整等待時間，包括任何連接的操作；並應區分生成開始與助理交付有意義結果的時刻。

第二個訊號，是讓持續使用情況可見的應用程式發布。可下載模型證明其可取得性；持續維護的助理、遊戲整合或嵌入式介面，則可展示團隊如何處理安裝、權限、復原及更新。

若這類發布在預先準備的互動以外仍能表現一致，便會強化理據；若要維持可接受表現，必須採用異常受限的對話或頻繁人手介入，則會削弱較廣泛的論述。真正相關的證據，是產品在持續使用下的行為。

第三個訊號，是在相同應用程式條件下，對 Gemma 與 Qwen 作出可重現的比較。Nvidia Nemotron 3.5 Bolt 必須透過對特定部署真正重要的行為與資源使用組合，證明其價值。

該比較應包括含糊的請求及不成功的工具調用，亦應評估較短的答案是否仍保留必要資訊。當使用者理解結果並能辨識尚未解決的事項時，精簡回應便有價值。

開發者應公布足夠細節，讓其他人能重複比較。買家則應詢問哪些條件與自身裝置及工作流程相符。來自無關設定的結果可為決策提供參考，但不應決定決策。

對知識工作者而言，最有用的問題是助理能否可靠地將請求連繫到正確資訊與操作。模型在哪裡運行固然重要，但該位置只是整體體驗的一部分。

在採用 Nvidia Nemotron 3.5 Bolt 前，應要求一個圍繞實際工作而設計的示範。當中應包括較長對話、含糊請求及一次失敗的操作。觀察助理記住了甚麼、如何傳達不確定性，以及主應用程式是否仍能正常使用。在你計劃部署的硬件上，並在其他必要元件正在運行時，比較相同互動。若涉及私人文件，應檢查完整資料路徑，以及附加於每項工具的權限。有用的結果，是證明整個助理能在其資源預算內滿足你的需要。哪一項重複性工作最能清楚測試這項承諾？