NVIDIA Nemotron 3.5 Lightning：30B 開源模型，專為 AI Agent 做「執行」而生

NVIDIA Nemotron 3.5 Lightning 最好唔好當成另一個「萬能聊天機械人」，而係一個專門畀自主 AI Agent 使用嘅執行模型。

模型於 2026 年 8 月 11 日推出，總共有 300 億個參數，但每次生成 token 時大約只會啟用 30 億個參數。呢個設計令佢更適合處理大量、重複而且需要長時間持續運行嘅工作，而唔係取代大型推理模型。

Lightning 到底係做乜？

一個 AI Agent 接到任務之後，未必每一步都需要最強嘅推理能力。真正執行期間，往往有大量細碎但高頻嘅操作，例如：

• 呼叫外部工具或 API；
• 從文件抽取指定欄位；
• 檢查政策、規則或格式；
• 將資料轉換成結構化輸出；以及
• 按指定格式整理結果。

Lightning 就係針對呢一層工作而設。大型模型可以負責理解目標、制定計劃；Lightning 則負責之後一輪又一輪嘅例行步驟，務求減低延遲同運算成本。

NVIDIA 將 Nemotron 系列定位為開放模型，公開模型權重、訓練資料同訓練配方，方便開發者部署前自行評估，亦可以按需要作客製化或後訓練。

30B 總參數，點解只講 3B active？

Lightning 採用 Mixture-of-Experts（MoE，混合專家）設計。簡單講，模型內有一個較大嘅參數池，但每次處理 token 時，只會路由到其中一部分「專家」參與運算。

所以「30B」同「3B active」代表兩樣嘢：

• 30B 總參數： 模型完整儲存嘅學習參數總量。
• 約 3B active parameters： 每一步生成時實際參與運算嘅參數數量。

好處係模型可以保留較大模型嘅容量，同時用接近細型模型嘅每 token 運算量去工作。當然，稀疏啟用唔代表完全唔使儲存或管理完整模型；佢主要係減少每一步推理所需嘅計算量。

模型同時採用結合 Mamba 或 state-space processing、Attention 同 routed experts 嘅混合式架構，並提供 BF16 及 NVFP4 版本。

點解佢定位係「執行層」？

長時間運作嘅 Agent 通常會產生好多模型請求。即使最初嘅計劃已經由大型模型完成，後面仍可能要不斷揀工具、讀資料、驗證結果、處理例外同整理輸出。

如果每個細步驟都交畀 frontier-scale 模型，延遲同成本都可能上升。Lightning 嘅角色，就係接手當中較可預測、頻率較高嘅部分；遇到含糊決定或者高風險推理時，再交返畀能力更強嘅模型。

一個典型嘅雙層架構可以係：

1. 大型推理模型理解目標，制定整體計劃。
2. Lightning 對工具、文件或結構化資料執行例行步驟。
3. 工作流程遇到不確定性、例外情況或複雜判斷時，再呼叫大型模型。

NVIDIA 將總參數 550B、active parameters 55B 嘅 Nemotron 3 Ultra 定位為 frontier reasoning 同 Agent orchestration 模型，正好同 Lightning 形成分工對比。

NeMo Switchyard 負責揀模型

要實現上述分工，Agent 系統必須知道每一步應該交畀邊個模型，而唔係所有請求都送去同一個 endpoint。

NVIDIA 嘅 NeMo Switchyard 係一套 provider-agnostic routing SDK，即係唔綁死單一服務商。佢可以表示請求、設定可用模型目標，並管理向選定模型或服務商發出的呼叫。

實際應用上，開發者可以建立一個模型階梯：Lightning 處理一般及高頻請求；大型模型就留畀需要更多能力嘅個案。

呢點亦解釋咗 Lightning 最有價值嘅產品定位：佢唔係單獨用嚟傾偈最有優勢，而係作為多模型 Agent 系統入面嘅其中一個執行元件。

100 萬 token 上下文與部署選項

Lightning 宣傳支援最高 100 萬 token 上下文容量，對需要保留長對話狀態、處理大型文件，或者長時間追蹤任務資料嘅 Agent 特別有用。不過實際可用上下文長度及效能，仍會受 serving stack 同配置影響。

模型提供 BF16 同 NVFP4 checkpoint。NVFP4 版本針對推理部署，並使用 NVIDIA 喺支援 GPU 世代上提供嘅專用 kernel。NVIDIA 列出嘅部署場景包括本地基礎設施、工作站、數據中心及雲端，模型亦可經 Hugging Face 同其他託管服務使用。

AWS 表示，Nemotron 3.5 Lightning 已經加入 SageMaker JumpStart。AWS 用戶可以透過 SageMaker 主控台或者 Python SDK 部署模型。 NVIDIA NIM 文件則提供另一條容器化部署路線，當中列明 Ubuntu、CUDA、GPU driver 同 Docker 等系統要求。

不過，硬件要求唔應該一概而論。量化 checkpoint 可以令部署更實際，但係咪可以單卡運行，要睇 GPU 型號、記憶體、上下文長度、量化方式、batch size 同 serving software。至於某一款 GeForce RTX 筆電或桌面電腦係咪一定支援，亦應該以當時嘅 model card 同官方部署配方核實，而唔係直接套用到所有消費級裝置。

「快 4 倍」要睇用咩工作負載比較

NVIDIA 及 AWS 宣稱，針對指定 Agent 工作負載，Lightning 吞吐量最高可達 4 倍，任務完成速度最高快 30%。 呢啲數字唔係模型智慧程度嘅通用指標，亦唔代表每個生產環境都可以原樣得到相同表現。

實際結果可能受以下因素影響：

• 比較時採用嘅基準模型；
• GPU 世代及記憶體配置；
• batch size 同並發量；
• prompt 及上下文長度；
• 工具呼叫、網絡及外部服務延遲；
• decoding 設定；以及
• 工作可以接受幾多錯誤。

因此，評估 Lightning 唔應該只睇 tokens per second。對一個真實 Agent 來講，更重要嘅可能係資料抽取準確度、工具呼叫可靠性、結構化輸出合規程度，同埋由頭到尾完成任務所需時間。

託管價格吸引，但要留意係邊個 provider

託管服務可以令 Lightning 對高流量推理工作更有吸引力。以 DeepInfra 列出嘅價格為例，每 100 萬個輸入 token 收費 0.05 美元，每 100 萬個輸出 token 收費 0.20 美元；服務按用量計費，毋須自行管理 GPU 基礎設施。

但呢個價格唔係模型永久固定嘅成本。不同 provider 可能有唔同收費，精度、快取、路由及服務層級亦會影響最終支出。

如果要比較 Lightning 同大型模型，最好計埋整個 workflow 成本，包括重試、工具呼叫、路由，以及仍然需要交畀更強模型處理嘅請求。單睇每百萬 token 價格，未必反映實際每個任務嘅總成本。

結論：係 AI Agent 嘅快手工人，不是萬能大腦

Nemotron 3.5 Lightning 最適合被理解為一個快速、可客製化嘅 worker model。當應用程式需要產生大量相似請求，而任務又可以透過規則、格式限制或後訓練加以專門化，佢嘅設計就相當對路。

佢並唔係大型 orchestration model 嘅通用替代品。複雜規劃、含糊判斷、深度推理，或者一旦出錯代價好高嘅任務，仍可能需要 Nemotron 3 Ultra 或其他 frontier 系統。

一句講晒：Lightning 最合理嘅位置，係路由式 Agent stack 入面負責低延遲執行嘅一層。30B 總容量、約 3B active parameters、開放模型材料、NVFP4 推理選項，以及本地到雲端嘅部署路線，全部都係為咗令例行 Agent 工作做得更平、更快。至於 NVIDIA 宣稱嘅效能提升，就應該用自己實際嘅 Agent workflow 驗證，先好當成生產環境結果。