Google TorchTPU 加入 Amazon 挑戰 Nvidia 開發者優勢的行列

Google 於 10 月 20 日以開源軟件形式發布 Google TorchTPU，讓 PyTorch 開發者可更直接地在其晶片上運行，而非使用 Nvidia 硬件。用於建立及運行 AI 模型的開源框架 PyTorch，成為雙方共通的切入點。Google 此次發布緊隨 Amazon 宣布 TorchNeuron，令開發者的遷移成本成為競爭焦點。

兩家公司瞄準了團隊傾向沿用熟悉硬件的一個實際原因：更換硬件，可能意味著要更改軟件、除錯習慣及部署流程。Nvidia 的 CUDA 是用於編寫圖像處理器程式的軟件平台，支撐著大量現有工作流程。Google 與 Amazon 希望開發者在考慮其他晶片時，能保留更多既有工作流程。

這項分別影響深遠，但並不代表市場領導地位會自動轉移。更容易遷移，只是打開評估的大門。投入生產環境仍取決於模型品質、實際效能、可靠性及工程投入。這些發布改變了開發者比較硬件的起點，卻未能決定哪個平台最適合其工作負載。

Google TorchTPU 以 PyTorch 為起點

Google 在 PyTorch Conference 宣布發布，並將 TorchTPU 描述為其張量處理器（TPU）的原生軟件堆疊；TPU 是專門處理 AI 的處理器。Google 表示，開發者只需對程式碼作極少修改，便可使用現有的 PyTorch 介面。其原生 PyTorch 支援亦整合了常用的模型程式庫與部署工具。

眼前的改變，是更熟悉的程式設計途徑可直接通往 Google 硬件。

這點很重要，因為硬件替代方案所競爭的，是團隊已熟悉如何操作的一切。評估另一款處理器時，開發者必須考慮模型能否運行、故障如何呈現，以及既有測試是否仍然有效。保留原有框架，可減少評估期間引入陌生軟件的程度。

Google 表示，TorchTPU 與 Meta 的 PyTorch 團隊共同開發。這項合作十分重要，因為相容性必須遵循框架本身的行為，而非僅僅模仿其介面。當模型、程式庫及訓練流程變動時，開發者需要熟悉的操作仍能以可預測的方式運作。

「原生」一詞值得審慎理解。在此，它指的是後端，即把框架操作連接至特定硬件目標的軟件層。這不代表每個現有應用程式都能在每種處理器上同樣高效運行，也不會消除框架底層針對硬件的特定實作。

因此，這次發布改變了團隊最初面對的決策。過去，評估可能要先討論如何調整程式設計方式。Google 現時要求開發者從既有 PyTorch 模型開始，再從中研究餘下差異。

即使仍有後續工作，這已是有意義的改進。團隊可以更早發現不相容問題、透過熟悉工具比較行為，或在投入大量最佳化工作前，排除不適合的工作負載。其價值亦包括更清楚了解遷移是否值得進一步關注。

對初創企業而言，這降低了研究替代方案所需的承諾。一項可保留模型定義的試驗，比起僅為比較而維護另一套實作，更容易合理化。對大型企業而言，這在框架相容性與基礎設施接納度之間劃出更清晰界線。

兩類用戶都不應把易於起步誤解為部署已完成。這項公告為使用 TPU 硬件建立了新途徑。其商業重要性將取決於這條途徑有多常通向應用團隊可在無需特殊支援下維護的應用程式。

Google TorchTPU 亦改變了競爭賣點的表述。Google 不必要求每位開發者在考慮其處理器前先採用另一個框架。它可在 PyTorch 內接觸開發者，並就其後的使用體驗展開競爭。

客戶尚未遷移整個應用程式前，Nvidia 已面臨壓力

可信的替代方案，可在客戶完成遷移前影響硬件決策。

設想一個工程團隊正準備提出下一輪容量需求。如果另一個平台在評估前需要大幅重寫，團隊便幾乎沒有證據可帶到採購討論中。熟悉的軟件途徑，讓他們在作出承諾前有更佳機會比較選項。

這不代表 Nvidia 的銷售、利潤率或客戶留存會立即改變。這些公告沒有提供量化此類影響的依據。最初的壓力在於流程：客戶多了一個理由去測試，下個工作負載是否仍需要與上次相同的硬件。

這項分別有助說明開發者工具為何在晶片競爭中重要。硬件規格無法回答部署中的所有問題。一款紙面上吸引的處理器，仍須能順利融入客戶實際運行的軟件。

Google 與 Amazon 正嘗試縮短這條路徑。兩者的商業利益十分清晰：若評估自家處理器所需的前期工作較少，其處理器便更具相關性。只有當比較可在測試、最佳化及持續營運中保持可行時，開發者才會受惠。

因此，評估 Nvidia 的地位應涵蓋整個應用程式。客戶可能為某個獲支援模型選用替代方案，卻為另一工作負載保留 Nvidia 硬件。決策可因應不同應用程式而異，而非成為整間公司對單一供應商的宣言。

這限制了任何宣稱任一雲端服務供應商已打破 Nvidia 對開發者掌控的籠統說法。較站得住腳的解讀是，兩者都在挑戰一項假設：熟悉的 PyTorch 開發，理應自然導向 Nvidia 部署。

對現有客戶而言，回應不必涉及即時轉移。他們可要求供應商展示與其模型的相容性、記錄營運差異，並說明維護要求。這比比較晶片規格的標題數字，形成更具體的討論。

相同道理亦適用於基礎設施人手有限的小型團隊。對他們來說，關鍵問題不是另一款處理器能否運行 AI，而是評估該處理器是否會消耗足以犧牲產品開發的資源。

較容易的切入點會改變這項計算，即使最終答案仍是否定。發現應用程式嚴重依賴特定硬件行為，是有用證據；發現大部分應用程式可在可控修改下轉移，同樣如此。

Nvidia 面對的壓力，來自讓這些發現更容易出現。現有領導者仍可憑效能、可靠性或開發者體驗贏得比較。但更易接觸的替代方案，讓客戶至少有更佳機會先進行比較。

對應用程式用戶而言，任何好處仍是間接的。遷移只有在支援更佳服務、可持續的營運成本或其他可量度的產品改善時才會創造價值。更換應用程式底層的處理器，本身並非面向客戶的成果。

Amazon TorchNeuron 鎖定同一項軟件決策

Amazon 的對應方案令共同策略更明確。AWS 於 10 月 20 日宣布，面向其 Trainium2 及 Trainium3 處理器推出 TorchNeuron 公開測試版。AWS 表示，開發者可透過 .to('neuron') 選用新後端，同時保留標準 PyTorch 介面。

兩家雲端服務供應商都希望，框架選擇不再如此依賴硬件選擇。

兩者的相似之處不應掩蓋產品之間的差異。Google 正把 PyTorch 更直接連接到 TPU；Amazon 則把它連接至 Trainium。實作方式、受支援配置、營運環境及最佳化要求，仍需要分別評估。

AWS 描述了對即時執行的支援，即程式執行到操作時便立即運行。它亦支援 torch.compile，這是一項將模型部分內容編譯以供執行的 PyTorch 功能。這些能力涵蓋了同一框架內的實驗與效能工作。

因此，Amazon TorchNeuron 所競爭的不只是模型能否啟動。公司希望開發者能保留由實驗走向部署的熟悉流程。這點很重要，因為當每個階段都需要不同的開發方式時，遷移會變得更困難。

公開測試版的標籤亦很重要。買家應按文件所述的成熟度評估產品，而不應將發布視為已保證可普遍投入使用。獲支援的試用與關鍵生產服務，對穩定性及支援的期望並不相同。

與 Google 的比較，在開發者投入層面最具意義。兩家公司都在主張，團隊應可考慮其處理器，而無需先放棄熟悉的 PyTorch 實務。兩項公告均未能證明，最終體驗在不同供應商之間完全相同。

保留原始碼與保留營運安排之間亦有分別。應用程式可以保留模型定義，卻仍可能需要更改部署設定、基礎設施權限、監控及事故處理流程。這些仍是遷移決策的一部分。

這意味着競爭單位是可運作的應用程式，而非孤立的一行設定。對開發者友善的後端可降低進入門檻；門檻降低後，平台其餘部分仍必須支援該工作負載。

對已投入某個雲端環境的買家而言，額外的處理器選項可擴大內部比較。對正考慮遷移至雲端的團隊而言，評估範圍更大。他們必須考慮應用程式周邊服務，以及模型執行本身。

因此，Google 與 Amazon 雖有共同對手，卻不是可互換的替代方案。它們對 Nvidia 的共同挑戰關乎開發者存取方式；至於最終爭奪客戶，則取決於各自能滿足的具體工作負載及營運要求。

兩者同時聚焦 PyTorch，令這既是軟件故事，也是硬件故事。兩家公司都在投資開發者表達模型的那一層，正是在這裡，它們可先降低遷移成本，然後才要求客戶作出更大的基礎設施承諾。

更容易遷移不保證效能相同

最明確的保留來自 TorchTPU 的開發者本身。其 TorchTPU 設計原則指出，更改裝置目標應可讓模型運行；但他們亦警告，若要達到 TPU 的峰值效能，便需要投入更多注意力，因為既有模型選擇可能偏向 GPU 架構。

程式碼可攜性與效能可攜性是兩項不同主張。

程式碼可攜性是指應用程式只需作出有限改動，便能在另一個目標平台執行。效能可攜性則是指，它亦能在該平台上取得合適表現，而無需大幅重新調校。一次發佈可以大幅改善前者，卻仍讓後者保留不少實質工作。

這個落差是理解相關公告的核心。一個能正確執行的模型，只是為工程師提供起點；它並不能證明整個服務在真實需求下的運作效率，亦不能說明優化所需的投入有多少。

公平的比較必須保留應用程式的要求。如果模型已無法符合品質期望，輸出更快便不能算是改善。同樣地，一次成功的受控執行，也不能證明它能在使用者實際提交的各種輸入下穩定運作。

就訓練而言，即透過資料調整模型的過程，團隊需要比較的不只是執行是否完成。他們必須確認所得模型是否符合驗收準則，以及該工作流程是否仍具實際可重複執行的可行性。

就推論而言，即使用已訓練模型產生結果的過程，應用程式會帶來另一組限制。互動式產品優先考慮回應行為；背景處理則可容許不同取捨。某一工作負載的吸引結果，未必會自然轉移到另一種工作負載。

Google 另一項關於 TPU inference engines 的公告，說明了周邊軟件為何重要。公告介紹 vLLM 和 SGLang 的原生 PyTorch 後端——兩者均為模型服務工具——並配合針對硬件的優化。

這顯示工作不僅限於裝置選擇器。Google 表示，這些引擎保留了熟悉的框架元件，同時在底層加入 TPU 實作。該架構旨在維持開發者的熟悉感，而不假裝底層處理器具有完全相同的要求。

因此，較審慎的解讀仍具建設性。這些產品應按其能從具代表性的部署中移除多少專門工作來評估。若熟悉的原始碼掩蓋了大量新增的營運工作，其實際效益便會小於最初示範所暗示的程度。

Amazon 的 native Trainium backend 資料提供了一個具體例子。Cartesia 表示，其標準推論流程只需對 PyTorch 作出極少改動。其說法亦提到，團隊持續為對效能敏感的層開發自訂核心及小型硬件層級程式。

這項客戶經驗支持一個明確結論：較容易的初步遷移可以與針對性優化並存。它並不能證明每個語音應用程式都能毋須額外工作便完成遷移；持續優化亦不會否定保留大部分現有應用程式的價值。

語音服務讓這個分別變得具體。團隊需要的是完整互動流程中可接受的回應時間，而不只是一次成功的模型呼叫。他們亦必須了解故障會如何呈現，以及工程師能否在正常營運期間診斷問題。

解讀兩項公告的重點，是要問清楚工作移往了哪裏。新後端是否移除了工作、令工作變得更熟悉，還是把工作轉移到另一層？每種結果對人手安排和維護都有不同影響。

這亦是企業聲稱需要謹慎歸屬的地方。Google 和 Amazon 描述了廣泛相容性及對開發者的好處。這些說法反映產品意圖和所報告的能力，卻不能取代涵蓋買方自身應用程式的獨立結果。

平衡的評估容許顯著進展存在，而不會宣告評估已經完成。減少起步所需工作很有價值；能否透過優化和日常維護持續保有這項優勢，才是部署能否長久的關鍵。

開源擴大存取，同時雲端選擇仍受限制

開源軟件讓開發者更能掌握實作細節，但基礎設施決策仍有其自身限制。

TorchTPU 發佈讓其程式碼可供檢視和貢獻。這讓開發者能研究後端如何運作並追蹤變更，也讓相容性討論有機會納入更廣泛的 PyTorch 社群。

僅僅可取得，並不能證明維護回應會有多迅速。團隊仍需觀察問題處理、發佈做法、文件質素，以及對持續變動依賴項目的支援。這些都是隨着專案發展而需要評估的問題，而非推出時便可假定的優勢。

框架開放性與部署彈性之間的分別同樣重要。把模型維持在標準 PyTorch 中，可保留一層有用的熟悉感；但這並不會自動令每項周邊服務都能在不同基礎設施供應商之間移植。

以一個具說明性的文件搜尋應用程式為例，模型執行只是服務的一部分。它還需要文件擷取、存取控制、檢索、評估，以及可靠地交付答案的方法。遷移模型後，這些責任依然存在。

這個例子很重要，因為處理器討論可能掩蓋應用程式其餘部分。某個後端可能表現良好，但更大規模的部署仍然不便。相反，團隊或會接受額外的優化工作，因為周邊營運環境符合其需要。

因此，適當的比較也應包括維護整項服務的成本。工程工作包括理解故障、重現結果及更新依賴項目。熟悉的模型定義，是這個更廣泛計算中的有用資產。

當多個團隊參與評估時，維護證據尤其重要。除非基礎設施工程師、模型開發者和產品負責人共享背後的配置及驗收準則，否則他們可能會對同一結果作出不同解讀。

一個可搜尋的技術知識庫可協助保留不同實驗和發佈之間的這些決策。它為日後審視提供背景，包括團隊為何接受某項取捨，或拒絕看似有前景的結果。

重點在於實務，而非宣傳。當原先實驗以外的人也能理解評估，該評估便更有用。可重複的證據讓公司能重新檢視其硬件決策，而毋須從零散筆記和記憶中的對話重新開始。

Google TorchTPU 強化了將硬件選擇視為可重新檢視決策的理由。這不代表每種工作負載都應反覆遷移，而是指團隊多了一個理由，將持久的應用程式要求與從早期部署承襲的假設分開處理。

同樣的紀律可避免在不知不覺間以一種依賴取代另一種依賴。開發者應檢視哪些部分仍屬標準、哪些需要供應商特定工作，以及這些邊界如何影響日後變更。開源讓這項調查更易進行，但不會自動代為完成。

對企業買方而言，最理想的成果是一項有記錄的選擇。他們應知道某項工作負載為何適合特定平台，以及甚麼情況會足以支持重新考慮。新發佈帶來另一個蒐集這些證據的機會。

關注工作負載結果、維護與客戶採用情況

未來數月應會產生比另一輪有關開發者選擇權主張更有用的證據。最有力的訊號將顯示，容易入門是否能帶來可重複的部署，也應揭示相容性在哪裏結束、額外工程又從哪裏開始。

三項訊號將決定這些發佈帶來多少競爭份量。

第一，留意具明確應用程式要求的可重現工作負載比較。有用的結果應列明模型、軟件配置、品質期望及營運條件，讓人能理解某個平台為何表現良好。

這些比較應區分初步移植與經調校的部署。兩者都有用，但回答的是不同問題。初步移植衡量的是評估的可及性；經調校的部署則顯示額外投入能帶來甚麼，以及該投入是否合理。

涵蓋多樣應用程式的證據，將強化這些後端擴闊實際硬件選擇的論點。範圍狹窄的示範，則只支持較狹窄的結論。買方不應把結果延伸至產生該結果的條件以外。

第二，留意日常軟件變更下的維護情況。隨着模型函式庫及框架版本演進，後端必須維持可用。若日常更新一再需要特別介入或長時間延誤，推出時的相容性便顯得沒那麼重要。

這項訊號關乎採用的持續工作。開發者需要知道，他們能否遵循正常開發流程，而毋須反覆停下來遷就硬件整合。經過多次更新後的體驗，會令這項負擔更容易評估。

即使支援仍未完整，清楚記錄限制也會增強信心。它可協助團隊避開不適合的配置，並圍繞已知限制作出規劃。模糊的相容性聲稱，會令評估更難解讀，也令生產承諾更難辯護。

第三，留意那些說明初步試用後持續使用情況的客戶說法。有用的說法會指出應用程式、仍需進行的優化工作，以及持續保留該部署的營運理由。只有具名試點，仍未能回答這些問題。

最具說服力的例子會承認取捨。客戶可能為某些工作負載保留另一個平台，同時在其他地方擴大 TPU 或 Trainium 的使用。這類決策比廣泛宣稱某一架構已取代另一架構，提供更有用的證據。

這些訊號亦為 Nvidia 提供具體的競爭基準。它可透過客戶重視的完整開發者及營運體驗來捍衛其地位。Google 和 Amazon 必須證明，較容易的入門途徑能轉化為客戶在實驗後仍持續作出的選擇。

這些發佈值得關注，因為它們改變了評估條件。開發者現在有新的 PyTorch 原生途徑可研究 Google 和 Amazon 的處理器。仍未解決的是，這些途徑在多大範圍內能減少整體部署工作。

對考慮 Google TorchTPU 的開發者而言，應先從品質和營運要求已獲理解的工作負載開始。保留配置、記錄每項必要改動，並比較完整服務而非方便的示範。問清楚哪些工作消失、哪些工作仍然存在，以及試行後由誰維護結果。對買方而言，應要求提供另一名工程師能重現、另一個團隊能營運的證據。問題在於，熟悉的 PyTorch 開發現在是否為你的應用程式提供一個實際可行的額外硬件選擇。在讓既有假設或發佈承諾左右決策之前，應以這個問題引導評估。