NVIDIA 全棧協同設計瞄準 AI 記憶體瓶頸,不止於更大 GPU
NVIDIA 認為,單靠增加 GPU 記憶體,無法解決 AI 代理日益增長的需求。該公司在 11 月 5 日的說明中,將 NVIDIA 全棧協同設計置於這項主張的核心。NVIDIA 希望買家把處理器、記憶體、網絡、儲存及軟件一併評估,而非將記憶體容量視為足以衡量效能的指標。
眼前的張力在於推論,即運行已訓練模型以生成答案的過程。更大的記憶體池可容納更多資訊,但保存資訊與提供反應迅速的答案,是兩種不同的成果。隨着更長的對話及會使用工具的應用程式令容量愈來愈難以忽視,NVIDIA 的立場正挑戰以容量為先的採購策略。
把記憶體管理視為效能問題,亦有歷史依據。FlashAttention 與 vLLM 背後的學術研究顯示,以不同方式組織資料流動及配置,可改善現有硬件的利用率。NVIDIA 現在將這套系統觀點延伸至整個平台。買家面對一個實際問題:在自身的工作負載及回應要求下,哪些改善能轉化為實際可用的產出?
NVIDIA 全棧協同設計改變記憶體討論方向
NVIDIA 的公告將記憶體效率重新界定為整個服務系統的特性。
11 月 5 日的文章是在說明平台策略,而非獨立推出記憶體晶片。在其記憶體效率分析中,NVIDIA 描述了壓縮、共享情境管理,以及不同記憶體層級之間的資料移動。
高頻寬記憶體(HBM)是堆疊式記憶體,設於加速器附近以快速傳送資料。NVIDIA 說明如何降低對這類資源的需求,同時更有針對性地運用系統的其他部分。
該公司亦引用了一項引人注目的效能比較。它表示,在指定的 AgentX 工作負載下,Vera Rubin 的每美元吞吐量最高可達 GB300 NVL72 的 30 倍,同時每枚 GPU 的 HBM 容量僅約多 3%。
這些是 NVIDIA 所報告的數字,並非通用的效能保證。其意義較為有限:該公司將平台進展歸因於不只是按比例增加記憶體容量。
買家應區分這項主張與其提出的解釋。平台基準測試衡量的是多項改動的綜合結果,並不會分離出有多少改善來自記憶體管理。
在將標題中的結果轉化為採購決策時,這個區別十分重要。考慮增加記憶體的公司,需要知道現有系統欠缺的是空間、傳輸速度,還是有效的排程。
容量衡量系統可儲存多少資料。頻寬衡量資料可移動得多快。延遲衡量一次操作所需時間。這些限制彼此互動,但購買更多容量並不會自動消除其他限制。
試想一個企業助理,一邊處理文件,一邊回答員工問題。其營運人員可能會發現,記憶體在加速器達到運算極限之前已被填滿。另一個部署則可能能輕鬆放入記憶體,卻難以足夠快速地移動資料。
兩種情況的合適應對方式並不相同。更多空間可直接處理第一項限制;在第二種情況下,更佳的傳輸行為、軟件改動或不同的工作負載配置會更為重要。
因此,NVIDIA 全棧協同設計改變了評估單位。相關產品成為經配置的服務,包括其軟件行為及支援基礎設施。
這也為供應商帶來更廣泛的責任。若其優勢取決於協調運作的組件,相關證據便必須清楚說明這些組件。買家需要足夠細節,才能重現產生該優勢的條件。
這亦改變了客戶閱讀規格的方式。記憶體容量仍是必要資訊,但無法獨力支撐完整的效能論點。規格表描述資源;工作負載測試則證明那些資源能交付甚麼。
AI 代理為基礎設施團隊帶來不同壓力
即使運算暫時停止,基礎設施團隊仍必須為模型呼叫之間持續有用的資訊預留資源。
AI 代理是一種使用模型選擇及執行步驟的應用程式,通常涉及外部工具。其工作負載不同於一次提示後只產生一次答案。
試想一個程式編寫助理檢視程式庫、運行測試、讀取失敗結果及修改修補程式。測試運行期間,應用程式仍需保留連貫的任務記錄。當生成恢復時,這些資訊必須仍可存取。
這個例子說明的是營運上的張力,而非已量度的客戶成果。把所有內容保留在接近加速器的位置,有利於快速恢復;把不活躍資訊移至其他地方可釋放稀缺空間,但取回時會帶來額外工作。
鍵值快取(KV cache)儲存中間注意力資訊,讓模型毋須重新計算所有先前情境便能繼續運作。注意力是模型用於關聯序列中資訊的機制。
對營運人員而言,這個快取除了儲存模型權重這項熟悉挑戰外,亦帶來排程問題。權重是在模型執行期間使用的已學習數值。
一項服務可有足夠空間容納模型,卻未必有充裕空間容納活躍對話。反過來,它亦可能為正在等待工具回應的對話預留大量空間。
這兩種情況都不會清晰地呈現在簡單的模型大小比較中。應用程式的行為決定了有多少記憶體持續被佔用,以及這些資訊何時再次變為活躍。
這為推論供應商、企業平台團隊及開發代理產品的開發者帶來壓力。他們必須支援可變的活躍程度,同時避免緩慢請求佔用原本需要分配予高回應性請求的資源。
因而需要更緊密地協調應用程式行為與服務基礎設施。工具執行、取消操作、情境保留及請求排程,都會影響加速器效率。
產品團隊亦承擔了部分責任。保留更多對話歷史的功能會改變基礎設施需求;啟動額外平行工作的功能亦會再次改變需求。
對知識工作者而言,影響會體現在回應速度及服務限制上。一個在複雜任務中反覆停頓的助理,帶來的體驗與一個能保持穩定進展的助理並不相同。
這亦是為何不應把應用程式記憶體與持久知識庫混為一談。暫時的執行狀態有助模型延續工作;已儲存文件則提供應用程式可於日後檢索的資訊。
個人知識庫處理的是來源材料的組織與檢索。加速器記憶體處理的,則是模型處理已選材料期間所需的資源。
更佳的文件檢索可減少不必要的輸入,但無法消除所有運行時限制。服務仍需處理有用證據,並保留足夠的任務情境。
因此,短期壓力非常實際。營運人員需要了解哪些資訊值得即時存取、哪些可以等候,以及系統能否可靠地區分這些狀態。
更有用的記憶體始於減少浪費
最有力的技術論據,在於購買額外容量前先減少不必要的儲存及資料移動。
獨立研究為這種做法提供了先例。它並不驗證 NVIDIA 目前的基準測試主張,但支持記憶體感知軟件具有更廣泛的重要性。
FlashAttention 研究提出了一種圍繞不同記憶體層級之間資料流動而設計的注意力演算法。其方法透過審慎安排運算,減少成本高昂的傳輸。
這項結果之所以重要,是因為數學運算與其實作是問題的不同層面。軟件可保留預期的運算,同時改變硬件執行該運算的效率。
對買家的推論很直接。加速器的實體資源並不會獨立於使用它們的軟件而決定效能。實作品質可改變從這些資源獲得的實際可用產出。
另一個例子來自支撐 vLLM 服務系統的PagedAttention 研究。它把快取的注意力資料組織成可管理的區塊,以處理空間浪費並支援共享。
這些研究工作處理不同來源的低效率。FlashAttention 強調注意力運算期間的資料移動;PagedAttention 則強調快取資訊的配置及管理。
它們共同帶來的啟示很明確。記憶體壓力除了反映實際工作負載需求,也可能反映可避免的額外負擔。消除這些額外負擔,可在毋須實際擴充裝置的情況下釋出空間。
壓縮提供了另一種機制。量化,即以較少位元表示數值,可在模型及執行軟件支援時降低儲存需求。
不過,較小的表示方式並不會自動形成等效服務。營運人員必須評估品質是否仍適合其任務,亦須計入任何轉換或管理額外負擔。
對文件助理而言,保留一般流暢度並不足夠。壓縮後的系統仍必須能檢索相關證據、區分相似事實,並在真實文件中遵從指示。
對程式編寫助理而言,平均基準品質可能掩蓋特定程式語言或程式庫模式中的失敗。一項有用的評估應反映客戶實際提交的工作。
同樣的審慎原則亦適用於移動不活躍資訊。卸載是指將資料從加速器記憶體轉移至另一個記憶體或儲存層級。其效益取決於該資訊是否會在延誤有用工作之前被取回。
一個假設中的支援代理展示了這項取捨。在等待業務系統回應時,其情境可維持不活躍。當該系統回覆時,模型又需要重新取得情境。
若取回可成功與其他工作重疊進行,應用程式便可獲得可用的加速器容量。若取回來得太遲,用戶便會經歷另一次停頓。
這正是 NVIDIA 全棧協同設計具有具體技術理據之處。協調的軟件可作出孤立組件無法有效作出的決定。
但協調亦需要準確資訊。系統必須理解哪些情境正在使用、哪些可重用,以及哪些很可能很快再次需要。
錯誤預測可令瓶頸轉移。若儲存系統變得擠塞,釋出的加速器記憶體價值便有限。同樣地,壓縮只有在最終執行仍保持效率時才可節省空間。
因此,應把這項機制視為一條鏈來評估。配置、表示、放置及取回,必須在負載下共同運作。任何一環薄弱,都可能耗盡預期收益。
AMD 顯示容量為何仍然重要
系統層面的論點強化了對記憶體的比較;但不代表更大的記憶體容量池變得無關重要。
AMD 提供了一個有用的競爭參考。其 MI350 記憶體規格列出 288GB HBM3E 記憶體及 8TB/s 頻寬。
這些數字描述了軟件可使用的實體資源,卻不能證明哪一家供應商可為每一種模型或應用程式帶來較佳結果。
不過,這項比較說明了為何買家應避免陷入錯誤的二選一。容量與軟件效率是相輔相成的;系統可同時受惠於更大空間及更佳管理。
有些工作負載需要足夠記憶體容納關鍵資訊,優化才會發揮作用。若所需資料無法放入可接受的配置中,單靠高效排程無法解決部署問題。
另一些工作負載雖可放入記憶體,卻因配置、重複資料或閒置狀態而浪費資源。其營運者需要不同的介入措施。額外容量或許能掩蓋問題,卻不能處理其根源。
這令核心競爭不僅限於 NVIDIA 與 AMD 之間。首要問題仍是:買家重視原始容量,還是經驗證的系統層面輸出。
供應商比較應維持這個焦點。較大的記憶體規格為對容量敏感的工作建立潛在優勢;較佳的服務堆疊則為資源利用率建立潛在優勢。
兩者均不能保證最終結果。實際效能取決於模型、其數值表示方式、軟件實作,以及應用程式對回應的要求。
因此,公平的評估應固定工作負載。在不同模型或品質設定之間比較,回答的是與比較相同服務基礎設施不同的問題。
評估亦應區分部署便利性與穩定運作時的效能。經過大量調校後可高效運行的配置,所需工程投入或會超出客戶能夠支援的範圍。
即使不附上價格數字,這些投入亦應納入決策。專業人手、維護及版本發布協調,都會影響理論效能能否轉化為營運價值。
軟件可攜性同樣重要。採用深度協調基礎設施的公司,應了解有多少應用程式行為依賴特定運行環境或硬件功能。
這不代表整合本質上不可取。整合可為客戶省去大量工作。問題在於,所帶來的好處是否足以合理化相關依賴。
買家應要求供應商在相同驗收準則下展示同一個應用程式。這表示答案品質相等、回應預期可比,以及清楚說明系統邊界。
若額外記憶體令原本會失敗的工作負載得以運行,這具實質意義。若更佳管理利用既有容量支援更多回應迅速的工作階段,同樣具實質意義。
有用的比較是所交付的服務。硬件規格解釋部分結果,而軟件行為與營運複雜度則解釋其餘部分。
基準測試增益需要清晰的計算邊界
只有當買家明白量度涵蓋甚麼,吞吐量聲稱才值得作為決策依據。
吞吐量是指在一段時間內完成的工作量。對於語言模型,供應商通常以生成的 token 表示,即模型處理的文字單位。
然而,服務即使生成更多 token,亦可能帶來較差體驗。較長輪候時間或較慢的個別回應,可能提高整體利用率,卻令用戶受挫。
因此,效能證據需要加入回應限制。買家應知道答案多久開始出現,以及其後能否穩定持續。
他們亦需要知道甚麼才算有用輸出。額外文字不會自動代表額外價值;不準確的答案可能消耗大量運算資源,卻未能完成任務。
對於代理,這種關係會更複雜。成功的工作流程包括工具呼叫、等待時間,以及可能失敗的嘗試。只計算生成文字,會遺漏部分活動。
因此,審慎的解讀應採用方法論角度。NVIDIA 的平台比較值得檢視,但其標題所述的倍數提升,不能證明無關部署的結果。
跨世代結果亦結合了許多改變。運算能力、網絡、軟件成熟度及數值格式,都可能影響結果。
沒有受控比較,讀者便無法把全部改進歸因於記憶體效率。這項限制不會否定結果,但會限制結果可支持的結論。
計算邊界帶來另一個不確定來源。把上下文移出加速器記憶體的系統,仍會消耗支援資源。這些資源需要電力、空間、管理及足夠效能。
買家在評估效率時應計入這些依賴。否則,單一組件內的改進可能掩蓋其他地方增加的工作。
壓力下的營運行為同樣值得關注。典型效能或許吸引,但罕見的突發負載可能造成長時間延遲。當大量請求同時恢復時,共享資源尤其可能變得重要。
現實的評估亦應包括中斷情況。工具失敗、放棄的工作階段及應用程式重新啟動,均會影響快取資訊能保留多少效用。
安全性帶來更多限制。重用上下文需要在用戶與工作負載之間提供可靠隔離。共享資源不應令效能優化變成非預期的資訊洩露。
持久性要求亦應保持明確。暫時的執行上下文與具權威性的業務記錄用途不同。適合可丟棄狀態的設計,或許不適合需要可靠保留的記錄。
最後,品質必須留在量度邊界之內。壓縮或縮減上下文應按任務結果評估,而非視為免費節省。
對企業買家而言,這表示需要提出一個比「基準測試是否夠快」更嚴格的問題。他們需要知道,量度中的系統是否與其應用程式足夠相近,從而可為決策提供參考。
NVIDIA 全堆疊協同設計為跨組件追求效率提供一致的理據。餘下的不確定性在於,這些增益在特定部署中的幅度、可重複性及營運成本。
留意可重現性、上下文行為及買家採用情況
下一批證據應把平台聲稱連結至在現實需求下可重複的服務。
第一個值得留意的訊號是可重現的效能證據。在未來數月,有用的披露應說明模型版本、軟件配置、回應要求及系統邊界。
獨立測試會進一步強化論據。其價值在於顯示優勢能否在供應商挑選的環境以外持續存在。
若證據能在提升回應迅速的吞吐量時維持品質,便可支持系統論點。若結果依賴狹窄設定,則意味好處更為有限。
第二個訊號是實際代理活動中的上下文行為。買家需要有關等待、恢復及重用的證據,而不只是持續不中斷地生成文字。
有意義的示範會展示應用程式暫停以等待外部工具後再返回時的情況,亦會揭示許多請求競逐共享資源時的行為。
可靠的恢復機制會強化透過層級移動非活躍資訊的論點;不可預測的延遲則會顯示該方法仍需改進的地方。
第三個訊號是有營運細節支持的採用情況。客戶描述應說明哪些限制有所改變,以及由此產生的服務如何改善。
具名部署固然有用,但其配置與驗收準則比背書本身更重要。買家需要足夠資訊來判斷相關性。
來自不同應用類型的證據尤其具參考價值。文件分析、編程及互動式協助,對記憶體與排程提出不同要求。
因此,預測是有條件的,而非宣傳性的。若可重複結果把資源管理連結至有用輸出,系統層面評估將獲得更有力支持。
若增益在現實並行量、上下文長度或品質要求下減弱,容量規劃便會保留更大權重。兩種結果都能協助客戶作出更佳決策。
對開發者而言,直接含意是在假定擴充硬件是唯一答案前,先觀察應用程式行為。量度應識別有用工作在何處等待。
對企業團隊而言,含意是讓採購與服務要求保持一致。採購應處理已證實的限制,並包括消除該限制所需的支援資源。
知識工作者在比較助手時亦可採取同樣紀律。處理複雜任務時的回應速度,比單獨展示快速生成文字更重要。
在下次基礎設施檢討前,請團隊找出影響最重要 AI 工作流程的限制。模型是否難以容納所需內容、正在等待資料,還是保留了閒置的上下文?然後要求一項能維持任務品質及現實回應預期的比較。評估中應包括支援記憶體、儲存及營運投入。把 NVIDIA 全堆疊協同設計視為可測試的系統主張,並以同一工作負載評估競爭方案。有用的結果是能可靠完成有意義工作的服務。哪一項改變可為你的應用程式帶來這個結果?又有甚麼證據會說服你部署它?



