NVIDIA Nemotron EKS 部署讓多模態代理由團隊掌控

AWS 於 10 月 29 日發布 NVIDIA Nemotron EKS 部署指引，為團隊提供一條在 Kubernetes 上提供具 1,200 億參數多模態模型服務的途徑。Kubernetes 是用於協調容器化應用程式的系統，讓團隊掌控部署。團隊仍須決定，這份掌控權是否足以證明承擔更多基礎設施責任是合理的。

該指引涵蓋 NVIDIA Nemotron 3.5 Super VL 在 Amazon Elastic Kubernetes Service、EKS Auto Mode 及 Amazon SageMaker HyperPod EKS 上的部署。其核心取捨在於營運責任：AWS 處理多少基礎設施工作，以及多少工作仍由應用程式團隊承擔。

這項發展緊隨 NVIDIA 於 10 月 15 日公布模型，以及 AWS 於 10 月 16 日宣布 SageMaker JumpStart 上架之後。JumpStart 提供以目錄為基礎的部署途徑。Kubernetes 指引則面向尋求更直接掌控服務架構、軟件設定及工作負載配置的團隊。

對開發者而言，其意義不止於多一個可用模型。多模態代理是可理解不同輸入格式並使用工具的軟件，會同時牽動運算、網絡及應用程式設計方面的需求。將這些元件納入受控環境，能讓工程師有更多選項，同時亦令部署決策更具影響。

NVIDIA Nemotron EKS 部署擴展服務選項

AWS 記錄的是額外的部署途徑，而非宣布推出新模型。

在評估變化時，這項區別相當重要。10 月 29 日的多模態部署指引描述了一項參考實作，涵蓋標準 EKS、EKS Auto Mode 及 HyperPod EKS。AWS 表示，模型部署清單在這些編排選項之間維持相同。

該架構採用 NVIDIA Dynamo——一個協調推論服務的框架——以及運行語言模型的引擎 vLLM。推論是指使用已訓練模型產生輸出的過程。AWS 描述了同置式服務，以及把處理階段分散至不同節點的部署安排。

AWS 表示，該架構已在 p6-b200.48xlarge 及 p5en.48xlarge 執行個體上完成驗證，兩者分別配備 NVIDIA B200 及 H200 加速器。這說明了 AWS 已測試的配置，但不代表所有受支援執行個體、工作負載或軟件版本均有通用效能表現。

對既有 Kubernetes 團隊而言，這份指引為評估提供具體起點。工程師可在將模型引入應用程式前，檢視部署邊界。他們亦可判斷哪些既有營運做法可沿用，哪些需要調整。

當機構已在預期模型端點附近運行應用程式服務時，這點尤其重要。部署方案應說明模型如何接入該環境，並界定誰負責發布、監察故障，以及調查跨越服務邊界的請求。

參考實作的出現，令這些討論變得更具體。審查者可討論實際架構，而非批准「自行託管 AI」這類抽象方案。然而，原封不動採用範例，仍會留下重要的應用程式決策未解決。

以一個閱讀技術文件並查詢公司工具的內部研究助理為例，其模型端點只屬整項服務的一部分。檢索、權限、來源追蹤及工具執行，仍需要明確的負責人。

因此，NVIDIA Nemotron EKS 部署應與模型評估一併納入應用程式架構審查。相關問題是，該部署途徑是否支援預期工作流程，以及負責維護它的團隊。

這亦釐清了它與 SageMaker JumpStart 的關係。AWS 早前的公告已透過其目錄提供模型存取方式。較新的指引則提供另一條營運途徑，帶來不同的自訂機會與責任。

兩種途徑都不會自動適合每個機構。團隊應將選擇連結至具體需求：服務配置、整合邊界或營運做法。否則，額外控制權只會變成沒有明確應用效益的工作。

稀疏架構改變運算方程

Nemotron 的活躍參數數量描述運算量，而部署規劃亦必須考慮完整模型。

NVIDIA 的量化模型卡描述了一種專家混合架構，會將每個 token 路由至指定模型元件。Token 是模型處理文字時使用的單位。該模型包含 1,200 億個參數，每個 token 有 120 億個活躍參數。

模型卡描述了一種結合 Mamba-2 與注意力層的混合架構；Mamba-2 是維持循環狀態的序列架構，注意力層則將不同輸入之間的資訊連繫起來。視覺編碼器會把視覺素材轉換為語言系統可處理的表徵。支援輸入包括文字、圖像及影片，輸出則為文字。

NVIDIA 列出的上下文容量最高可達 100 萬個 token。上下文容量是指模型可考慮的輸入及對話材料。這個上限應為測試提供參考，但不應被視為實際併發量或回應時間的假設。

模型卡亦區分了針對特定硬件的配置。其精簡部署範例與 AWS 指引中的較大型最低配置不同。這兩份文件不應被視為可互換的規格指引。

對採購方而言，這個區別可避免一個常見規劃捷徑：把稀疏運算等同於較小的部署佔用空間。活躍參數數字有助說明模型設計，但無法決定應用程式在負載下需要多少記憶體。

文件助理正好說明這個問題。針對單一頁面的簡短提問，與橫跨冗長文件的請求，對服務提出不同需求。兩者使用相同模型權重，但其處理模式及暫時記憶體需求仍有差異。

實際含意是應評估工作負載分布。團隊應納入預期的文件、圖像大小、對話長度及輸出模式。單靠平均請求，可能會掩蓋主導資源消耗的個案。

精度亦帶來另一項選擇。BF16 以 16 位元格式儲存數值，而 NVFP4 則以較低精度表徵處理指定模型的運算及儲存。NVIDIA 提供針對不同部署需求的 checkpoints。

較低精度值得在應用程式層面驗證。收據擷取工作流程或許可容許措辭略有差異，卻要求交易欄位完全準確。研究工作流程則可能更重視結論是否仍有引用證據支持。

這些差異意味著，單一品質分數不足以應對每項部署決策。評估人員應在比較配置前界定哪些錯誤最重要。否則，較小的記憶體佔用空間看似吸引，卻未能顯示其對實際任務的影響。

同樣的審慎態度亦適用於最大上下文。可接收大量輸入的系統，仍需要挑選證據。即使請求符合技術上限，提供不相關材料仍會令審查更困難。

對正在建立可搜尋知識庫的工程團隊而言，文件組織仍是答案品質的一部分。模型容量不能取代來源維護、存取規則或清晰的證據邊界。

架構說明了模型為何值得評估；工作負載測量則決定哪種配置適合特定服務。將這些決策分開，有助團隊避免把模型規格誤當作生產容量計劃。

AWS 的叢集選擇轉移營運責任

標準 EKS、Auto Mode 與 HyperPod EKS 之間的選擇，應取決於團隊的營運需求。

標準 EKS 提供部署指引所述的熟悉 Kubernetes 途徑。對已維護專門叢集配置的團隊而言，其相關性相當直接。他們可在既有營運環境內評估模型。

當工程師了解既有部署流程時，這種延續性具有價值。不過，這亦需要誠實評估可用專業能力。熟悉應用程式容器，並不會自動解決涉及加速器容量或分散式模型服務的所有問題。

EKS Auto Mode 改變了管理邊界。AWS 的叢集基礎設施管理文件描述了受管理的運算擴展、網絡、負載平衡、儲存整合及 GPU 支援。GPU 即圖像處理器，是此處用於模型運算的加速器。

AWS 亦表示，客戶仍須負責應用程式容器，包括可用性、安全性及監察。客戶繼續控制其網絡環境及叢集配置。因此，Auto Mode 會委派基礎設施工作，同時保留應用程式責任。

對模型服務而言，該責任邊界應有明確負責人。必須有人決定新的服務映像是否可接受；亦必須有人調查未成功的請求，並判斷模型更新是否改變應用程式行為。

自動化基礎設施管理並不能回答這些問題。它可減少圍繞這些問題的工作，從而讓團隊專注於評估。其效益取決於受管理配置是否符合工作負載要求。

HyperPod EKS 則處理另一組營運關注事項。AWS 的HyperPod 編排文件描述了連接至 EKS 控制平面的受管理運算叢集；控制平面是協調叢集運作的元件。它支援推論與訓練工作負載。

該文件亦說明健康檢查、故障節點復原，以及與監察工具的整合。當機構管理大量機器學習基礎設施時，這些功能提供評估 HyperPod 的理由。它們並不免除驗證應用程式復原能力的需要。

節點復原與用戶工作流程復原，是兩種不同結果。應用程式可能需要重新提交請求、重建對話狀態，或避免重複執行工具操作。這些行為需要超越叢集健康機制的設計。

壓力會同時落在平台團隊與應用程式擁有人身上。平台團隊需要可維護的服務模式；應用程式擁有人則需要在底層服務變更或不可用時，仍有可預期的行為。

因此，基礎設施決策應包括預期的故障體驗。審查者應詢問未完成回應會如何處理，以及用戶端如何識別可重試的故障。他們亦應界定由哪個團隊調查每一類事故。

對於評估 NVIDIA Nemotron EKS 部署的組織而言，有用的比較重點在於責任分工，而非功能數量。最佳選擇是既能符合應用程式需求，又不會帶來超出組織承擔能力的營運負擔。

規模較小的團隊可能重視委託管理基礎架構。專門的平台團隊則可能需要更多設定控制權。已經使用 HyperPod 的組織，或會優先考慮與現有機器學習營運方式的一致性。

這些是決策準則，而非放諸四海皆準的建議。已發布的指南提供部署選項，組織則必須將選項與其人手配置、可靠性期望及應用程式架構連結起來。

Dynamo 將互相競爭資源的處理階段分開

分散式服務帶來調校選項，而每個選項都需要以目標工作負載的證據支持。

NVIDIA 的分散式推論框架支援解耦式服務，將不同的推論階段配置在獨立資源上。其文件亦說明路由、快取管理及擴展元件。Dynamo 可配合 vLLM、SGLang 及 TensorRT-LLM 使用，這些都是執行模型的替代引擎。

這為 AWS 範例提供了更廣泛的背景。服務引擎只是較大型系統中的其中一個元件。選擇引擎並不能決定請求路由、保留狀態、資源配置，或服務如何回應需求變化。

各階段有不同工作。Prefill 處理傳入提示，而 decode 則逐個 token 生成回應。視覺編碼會在語言模型使用其表徵前，處理圖像或影片輸入。

分開各階段讓工程師能夠獨立檢視其需求，但同時亦引入資料必須移動及必須處理故障的邊界。部署決策應說明這些邊界為何有助應用程式。

以擬議的文件審閱助理為例，部分請求要求從圖像中擷取簡短欄位，另一些則要求跨文件提供延伸說明。若將這些請求視為相同，容量結果便會難以解讀。

評估分隔階段的團隊應詢問請求把時間花在哪裏。若輸入處理佔主導，只改變輸出生成容量便是在處理錯誤的限制因素。若生成答案佔主導，增加輸入容量可能幫助不大。

這正是可觀測性——即透過量度理解系統行為的能力——成為架構一部分的地方。服務需要能區分等候、輸入處理、生成及外部工具活動的量度指標。

面向使用者的延遲可在模型服務以外出現。研究代理可能在等候搜尋服務或文件儲存庫。改善模型生成不會消除該延遲，因此評估應保留完整的請求時間線。

快取同樣需要背景脈絡。快取會保留可重用的運算或資料，以避免重複工作。重複的系統指令，與在個別請求中到達而彼此無關的文件，帶來不同的重用機會。

採用重複提示的基準測試應披露該模式。否則，讀者無法判斷其結果是否適用於重複性較低的工作負載。同一原則亦適用於比較已預熱服務與剛啟動的部署。

生態系統比較亦始終比一般模型競賽狹窄。Dynamo 對替代引擎的支援顯示，分散式服務是一種更廣泛的基礎架構方法。這並不能證明每個引擎都為此模型支援相同設定。

工程評審應保留這項區別。獲支援的框架、獲支援的模型，以及經測試的組合，是三項不同主張。在決定某項設定是否已準備好接受評估時，特定版本的文件相當重要。

對於 NVIDIA Nemotron EKS 部署，這形成清晰的決策順序：先確立應用程式工作負載，找出限制因素，再按該限制評估服務安排。當量度顯示具實際效益時，複雜性才有其價值。

共置部署仍是合理的比較基準。分散式安排需要透過與應用程式相關的收益，證明其額外協調工作的合理性。這項比較應包括復原行為及營運工作量，並與回應量度一同考慮。

模型基準測試未能解決工作流程可靠性問題

供應商評估有助識別候選方案，但企業代理需要來自自身工作的證據。

NVIDIA 的多模態推理模型公告報告，該模型在 Hermes Bench 取得 63.44%，在 LangChain 評估取得 87.05%。公告亦報告其在圖表推理基準 CharXiv 取得 80.8%。這些是 NVIDIA 報告的結果，而非對 AWS 部署的獨立驗證。

公告提到 Ramp 利用該模型將收據資料擷取至結構化欄位。NVIDIA 報告該工作流程預期可改善吞吐量及延遲。合作夥伴範例中的預期，應與另一組織的實測結果區分開來。

NVIDIA 亦將較小型 Nemotron 模型定位為適合高容量文字工作，並將 Nemotron 3 Ultra 定位為適合複雜規劃。這項比較支持評估模型系統，但不能證明 Super VL 應處理每一項請求。

這項區別很重要，因為工作成功包含多個部分。收據工作流程需要正確欄位、可接受的格式，以及對不確定輸入的適當處理。流暢的說明無法彌補錯誤的付款金額。

文件代理則帶來另一項挑戰。它可能正確閱讀圖表，卻從周邊資料得出沒有支持的結論。評估應區分視覺擷取、詮釋，以及最終決策。

工具使用又增加一道邊界。模型能提出工具呼叫，並不能證明應用程式應否執行該呼叫。周邊系統需要具備權限、驗證及處理不完整參數的規則。

這些考慮是評估要求，而非某項特定 Nemotron 缺陷的證據。所審閱的供應商來源並未為每項企業工作流程提供通用結果。讀者不應以信心或假定失敗來填補這個缺口。

有用的評估案例包括含糊的文件及遺漏資訊。模型應有既定方式表達不確定性。審閱者應知道，對於該應用程式而言，未回答的問題是否比沒有支持的答案更可取。

測試集亦應把熟悉範例與保留案例分開。保留案例是未納入客製化及調校的範例。若沒有這種區分，團隊可能會把對已知範例的適應，誤當成更廣泛的工作流程可靠性。

效能比較同樣需要清晰界線。各項設定應採用相同文件、輸出要求及推理設定。否則，較快的生成可能只是反映要求的答案較短，或工作較簡單。

推理設定值得注意，因為它們會改變模型處理請求的方式。更廣泛的推理應透過更佳工作成果，證明其資源使用合理。部署不應假定最複雜的設定總會令使用者受益。

人手審閱亦應納入比較。若自動輸出持續需要修正，便會在流程其他環節產生工作。評估者應記錄這些工作，而不是在模型完成生成時便停止量度。

因此，證據缺口是具體的。這些公告確立了模型產品、報告的評估結果、合作夥伴情境及部署選項。至於在目標服務內驗證品質、效能及復原能力，仍由每位潛在採用者負責。

下一批證據應將容量與已完成工作連結

最有用的後續證據，將展示在真實營運條件下可重複取得的結果。

首先值得關注的訊號，是可重現的部署量度。在未來數月，有用的報告會列明軟件版本、模型精度、硬件、請求模式及併發量。併發量是指同時處理的請求數目。

若其他團隊能重現結果，這類報告將強化更廣泛採用的理據，同時亦令限制更容易解讀。與狹窄設定綁定的結果，只要界線清晰，仍然可以有用。

重要結果是在既定回應要求下的服務容量。單一峰值吞吐量數字，會令讀者只能猜測使用者體驗。報告應把生成輸出與等候時間、請求完成情況及觀察到的故障連結起來。

第二個訊號是客製化後的領域特定品質。可信的後續研究應在保留工作上，比較初始模型與調整後版本，並披露工作定義及仍然存在的錯誤。

若改善能在訓練範例以外持續出現，該證據便會支持 NVIDIA 的專門化論點。若收益在不熟悉文件或真實的工具互動下消失，則會削弱採用理據。無論是哪一種結果，都有助買家作出更佳決定。

對於文件工作流程，審閱者應超越整體準確度。他們需要了解哪些欄位或結論會失敗，以及這些失敗是否需要介入。錯誤的相關性取決於應用程式所執行的工作。

第三個訊號是變更期間的營運行為。有用的報告會說明服務軟件更新、模型更換、節點故障及服務復原。在日常維護期間保持穩定效能，將強化 Kubernetes 部署的理據。

這些報告應包括應用程式的實際體驗。若使用者遺失工作，或重複請求觸發重複操作，基礎架構復原便是不完整的證據。營運成熟度體現在完整工作流程的行為方式。

這些訊號合在一起，將釐清已發布指引的價值。可重現的效能確立容量；保留評估確立工作適合度；復原證據則確立團隊能否以可接受的中斷程度營運服務。

它們亦提供了比較部署路線的實際方法，而無須宣稱存在普遍贏家。每個組織均可按自身要求判斷相同證據，令討論始終與工作負載相連，而非平台偏好。

評估應從範圍明確的工作、具代表性的輸入，以及可接受結果的清晰定義開始。記錄設定，讓另一位工程師可以重現。納入失敗、需要審閱，或在服務中斷期間到達的請求。

讓決策與已完成工作保持連結。詢問模型能否產生可用結果、服務能否符合回應期望，以及團隊能否維護它。將額外的服務複雜性視為需要證據支持的事物。

NVIDIA Nemotron EKS 部署現已具備涵蓋 AWS Kubernetes 選項的文件化路徑。利用這條路徑測試具體應用程式、比較營運責任，並選擇團隊能夠支援的設定。