脈絡拆解: AWS re:Invent 2024 Monday Night Live Keynote With Peter Desantis

tl;dr 重點摘要

• AWS 發布 Trainium2 Ultra Server - 這是 AWS 迄今最強大的 AI 基礎設施，具備 64 個 Trainium2 晶片透過 Neuron Link 技術協同運作，提供比目前任何 EC2 AI 伺服器高 5 倍的運算能力和 10 倍的記憶體容量，專為兆參數級 AI 模型設計。（我人在 AWS re:Invent Las Vegas 現場，週一剛好有參加到 Neuron Link 的一場 Code Talk 議程。）
• AWS 為 Amazon Bedrock 推出了低延遲推論優化，提供了包括 Llama2 和 Claude 3.5 Haiku 等熱門模型的優化版本，可比標準版本快上 60%，目前已開放預覽。（真的是都不用睡覺）
• AWS 發表 TNP Ten Network - AWS 最新的 AI 優化網路架構，可提供數十 PB 的網路容量，延遲低於 10 微秒，採用幹線連接器和 Firefly 光纖插頭等創新設計，使安裝速度提升 54% 並改善可靠性。

知識圖譜

AWS 領導力與創新基礎

• 請歡迎 AWS 公用運算部門資深副總裁 Peter DeSantis。
• [音樂]
• [音樂]
• 謝謝。歡迎參加 re:Invent 2024。
• [掌聲]
• 感謝各位參加另一場週一夜現場，或是我喜歡稱之為「主題演講前夜」。
• 我們有很棒的樂團和啤酒，不過我要道歉。
• 我發現我們沒有準備 IPA。
• 我明年一定會為 IPA 愛好者改進這點。
• 抱歉，這是我的疏失。
• 好的，今晚我們要做的跟平常一樣，我們要深入探討一些技術創新。
• 就像任何一個好的主題演講前夜，我們可能會拆開一份禮物，也許一份。
• 讓我們拭目以待。
• 但我們要從最重要的事情開始，這也是我們在週一夜現場喜歡做的事，就是看看「如何」做到，而這個「如何」很重要，因為「如何」是我們實現雲端運算最重要特性的方式。
• 這些不只是你可以推出的功能而已。
• 這些是你需要設計進服務中的東西。
• 這正是我們所做的。
• 這些是我們建構方式的體現。

細節中的領導力

• 今晚我想跟大家解釋一下，為什麼我認為 AWS 在提供這些能力方面特別出色。
• 在準備這部分演講時，我決定嘗試使用AI 助理。
• 我受到我的團隊以及整個亞馬遜各個團隊使用 AI 助理來做事情的啟發，比如寫程式碼、創作內容，我想這會是個有趣的實驗機會。
• 所以我告訴我的 AI 助理我想如何開始這個演講，以及我想如何視覺化呈現，然後得到了一些想法。
• 我得到的第一個想法是冰山，因為我想談的是表面之下的東西，但我不太喜歡冰山的比喻，因為冰山你只能看到小小的一角，而下面只有冰而已。
• 第二個比喻好多了。
• 它是太空飛行，AI 助理說我應該解釋雖然我們只看到短暫的發射，但背後有龐大的工程師、操作員和設計師團隊，這個比喻更有意義。
• 但還是沒有完全符合我想要的。

樹根的比喻

• 所以在與我的 AI 助理多來回討論後，我們決定我要談談樹。
• 現在這些樹代表了我們每年討論的重大差異化技術投資。
• 像是我們在客製化晶片上的長期投資，這能為 AWS 客戶提供最高效能和最低成本的基礎架構選項。
• 還有我們在AWS 客製化虛擬機監視器上的投資，這使得安全的無伺服器運算成為可能，或是我們在資料庫技術上的深度投資，這讓我們能提供差異化的資料庫功能和效能。
• 但在今晚談論這些樹之前，我想談談根，那些在樹下支撐和滋養樹木的關鍵結構。
• 讓我們從主根開始。
• 並不是所有的樹都有主根，但有主根的樹能獨特地取得深層地下的水分，使它們即使在惡劣環境下也能茁壯成長。
• 而且AWS 和亞馬遜最獨特的事情之一就是我們的領導者花considerable時間在細節上，而投入這些細節很重要，因為當你深入這些細節時，你就知道客戶和服務真正發生了什麼，這使你能夠快速做出決定，可能在問題發生之前就修復或預防它們。
• 這在其他地方也會發生，但通常這些資訊必須經過組織的多個層級才能向上傳遞，而這永遠不夠快。
• 想想看，當事情不順利時告訴你的老闆是多麼不愉快。
• 這不是任何人最喜歡做的事，而且通常不會夠快發生。
• 說要保持在細節中很容易。
• 困難的部分是建立你需要的機制來確保你能大規模做到這點。
• 這正是我們所做的。
• 一個很好的例子是每週三，我們舉行AWS 全公司的運營會議，所有團隊聚在一起討論問題、分享學習心得，並相互學習。
• 這是讓我們的領導者，包括我在內，保持在細節中的關鍵機制。
• 深入細節也在其他方面幫助我們。
• 其中一個方面是讓我們更容易做出必須做出的困難長期決定。
• 一個很好的例子是我們決定開始投資客製化晶片。
• 現在，這看起來像是一個顯而易見的決定。
• 但 12 年前這一點都不明顯。
• 深入細節後，我們知道如果沒有像 Nitro 這樣的東西，我們永遠無法為 AWS 實現我們需要的效能和安全性。
• 所以我們決定與Annapurna團隊合作，這後來成為我們業務最重要的技術推動力之一。
• 如果不是因為我們對挑戰的深入理解，我們很可能會決定等待。
• 但幸運的是，我們沒有等待。
• 而 AWS 的故事因為這個決定而完全不同。
• 今晚，我們將分享這個故事的下一章。
• 現在，雖然我喜歡主根的比喻，但深根並不是支撐最巨大樹木的東西。
• 相反，樹木依賴水平根系統。
• 亞馬遜雨林就是這些水平根系統的一個令人著迷的例子。
• 這些地上根系統支撐著世界上一些最大的樹木在不穩定的土壤系統中生長，支柱根可以從樹基部延伸數百英尺，它們實際上可以與附近的樹木互相連接，為這些雨林巨人創造支撐的基礎。
• 這讓我想到 AWS 的另一個獨特特徵我們能夠在整個技術堆疊中進行創新。
• 從資料中心電力到網路、晶片、虛擬機監視器、資料庫內部到高階軟體，幾乎沒有其他公司在這麼多關鍵組件上有如此深入的投資。
• 本週，我們將向你展示這種廣泛的創新如何使我們能為你們，我們的客戶，創造非常獨特和差異化的功能。
• 但這些支柱根系統只是樹木互相連接的令人驚嘆方式之一。
• 也許最令人驚嘆和意想不到的是地下木質網路。
• 我們常常認為蘑菇就是這些從地面長出來的真菌，但蘑菇實際上是生長在地下真菌的果實。
• 這是一個生活在樹根中的巨大生物，樹木與這種真菌有共生關係，它們用它來相互溝通並分享信息和資源。
• 這使得森林比任何單獨的樹都更強大。

AWS 文化和機制

• 這讓我想到我認為是AWS 最重要和最獨特的事情。
• 這種文化支撐著我們所做的一切。
• 當我在 1998 年作為一名年輕工程師加入 AWS 或亞馬遜時，我對我們的領導層在公司發展如此早期就如此重視建立文化感到驚訝。
• 我們的高層領導花時間建立機制，使我們能夠發展成今天的公司。
• 我們花時間寫下我們的領導原則。
• 我們花時間建立標竿提升計劃來保持誠實，並為我們想要招募的人保持高標準。
• 我們建立了像我之前展示的每週運營會議這樣的機制，以確保我們在擴展時不僅僅依賴良好的意圖。
• 現在回想起來，很容易看出我對這些投資的緊迫性有多麼錯誤。
• 文化這種東西，要麼你有，要麼你沒有。
• 如果你沒有，那就祝你好運了。
• 而我們的文化是獨特的，它幫助我們在擴展的同時保持對安全性、運營績效、成本和創新的堅定關注。
• 本著擴展創新的精神，我要嘗試一些新的東西。
• 今晚我想讓你們聽聽其他推動這些創新的 AWS 領導者談談我們今晚要討論的一些創新。
• 所以請和我一起歡迎 AWS 運算和網路部門的副總裁兼長期領導者 Dave Brown 上台。
• [音樂]
• 謝謝 Peter。

AWS 客製晶片和基礎架構

• 很高興能在這裡。
• 18 年前我在南非開普敦加入了一個只有 14 人的小團隊，開始了我的 AWS 旅程，我們當時正在建構後來成為EC2、彈性雲端運算的服務。
• 我們的使命很有野心，要設計最終將為雲端提供動力的基礎協調層。
• 當時我們並不知道，這只是運算領域一場更大轉變的開始。
• 從那時起，我們一直在重新發明基礎架構的每個層面，為客戶提供最大的彈性、效能和效率。
• 而且這趟旅程的重要部分源自於我們的客製晶片開發。

Graviton 的演進與效能

• 當我們在2018年首次推出Graviton時，不是為了要有最快的晶片。
• 更多是為了向市場發出信號，給開發者真正的硬體來試用，並在資料中心引發圍繞 ARM 的產業協作。
• 接著我們將目標定得更高，我們的第一個專門打造的處理器Graviton2，是從零開始完全重新設計。
• 我們特別專注於擴展工作負載，因為那是我們的客戶當時看到並且正在突破極限的地方。
• Web 伺服器和容器化微服務、快取叢集、分散式資料分析。
• 而且這就是 ARM 真正進入資料中心的時刻。
• 而透過Graviton3，我們擴展了觸及範圍，同時提供了大幅的全面性能提升，我們專注於需要超強運算能力的特殊工作負載。
• 成果相當驚人。
• 從機器學習推論到科學模型、影片轉碼和加密運算，我們為許多計算密集型工作負載提供了超過兩倍的效能。
• 而今天，Graviton4代表了我們在雲端建構處理器所學到的一切的集大成。
• 這是我們迄今最強大的晶片。
• 而且透過多插槽支援和原始 vCPU 數量的三倍提升，這對最需求最高的企業工作負載來說是個遊戲規則改變者，像是大型資料庫和複雜分析。
• 隨著Graviton每一代的推出，客戶只需要簡單切換到最新的執行個體類型，就立即能看到更好的效能。
• 現在，讓我們來看看我們如何為真實世界的工作負載優化Graviton的效能。
• 現代的 CPU 就像一個精密的組裝流水線，前端負責擷取和解碼指令，後端則執行這些指令。
• 當我們評估效能時，我們會觀察不同工作負載如何對 CPU 微架構造成壓力。
• 現在工作負載是否對前端停滯敏感，這受到像是分支數量、分支目標或指令等因素影響。
• 或者工作負載可能對效能敏感，受到後端停滯影響，這與L1、L2 和 L3 快取中的資料以及指令視窗大小有關。
• 傳統上，微基準測試被用來測試處理器的架構。
• 以這個基準測試為例。
• 它不斷地打擊 L3 快取，造成大量的後端停滯。
• 用工程師的話來說，這意味著CPU 流水線正坐在那裡空轉，等待不斷被踢出 L3 快取的資料。
• 多年來，業界一直執著於優化這樣的基準測試。
• 但是這就像是用跑 100 公尺短跑來訓練馬拉松。
• 沒錯，兩者都是在跑步，但你基本上是在為不同的挑戰做訓練，而真實世界的工作負載的行為與這些整齊乾淨的基準測試完全不同。
• 它們雜亂、不可預測，而且說實話，它們更有趣。
• 讓我們來看看當我們將這個微基準測試與真實世界的應用程式並排，像是Cassandra、Groovy 和 NGINX這些我們的客戶每天都在運行的工作負載會發生什麼事。
• 現在，雖然微基準測試都是關於後端停滯，但在這些真實世界的工作負載中，它們的瓶頸出現在完全不同的因素上。
• 分支預測失誤更多。 L1 和 L2 快取中有大量的指令失誤。 有 TLB 失誤，而且與微基準測試不同，前端才是造成所有停滯的原因。
• 這導致前端停滯比較高，而不是像我們在微基準測試中看到的後端停滯。
• 這就是為什麼在 AWS 我們如此關注真實世界工作負載的效能。
• 當我們設計處理器時，我們不是在試圖贏得基準測試比賽。 我們在追求讓你的實際應用程式卓越運行。
• 這些就是專注於真實工作負載的成果。
• 用Graviton3，傳統基準測試顯示比 Graviton2 提升了 30%。
• 不錯吧？
• 但等等。
• 當我們測試 NGINX 時，我們看到驚人的 60% 效能提升。
• 為什麼？
• 因為我們大幅減少了分支預測失誤，這是那些標準基準測試幾乎不在意的事情。
• 而用Graviton4，我們看到了相同的模式再次出現。
• 微基準測試顯示 25% 的提升，但真實世界的 MySQL 工作負載呢？ 它們看到了 40% 的效能提升。
• 想想這對運行大型資料庫的客戶意味著什麼。
• 這就是為什麼客戶喜歡Graviton4。
• 這些不只是投影片上的數字。
• 這些是真實客戶看到的真實改進，進而讓他們的客戶受益。
• 在 AWS，我們不只是在談論Graviton的好處。
• 我們正透過遷移我們的服務親身體驗它。
• 我們看到了顯著的價格效能改進。
• 像是Aurora、DynamoDB 和 Redshift等服務。
• 它們都因為在Graviton上運行而看到顯著的好處。
• 而在亞馬遜 Prime Day，世界上最大的購物活動之一，我們有超過 25 萬個 Graviton CPU 支撐著整個運作。
• 最近，我們達到了一個重要里程碑。
• 在過去兩年中，我們資料中心超過 50% 的新 CPU 容量都是在 AWS Graviton 上。
• 想想看。
• 這比所有其他處理器類型加起來還要多的Graviton處理器。

Nitro 系統安全性

• 但Graviton不是我們第一個在晶片層級創新的地方。
• 很早就知道，如果我們要為持續增長的 EC2 執行個體提供世界級的效能和安全性，我們需要在整個技術堆疊中進行創新。
• 而這個故事就是AWS Nitro 系統。
• AWS Nitro 系統是對伺服器架構的完全重新想像，而且透過Nitro徹底改變了我們建構和保護雲端的方式。
• 我們移除了其他雲端供應商至今仍在處理的傳統虛擬化技術。
• 我們也從Nitro架構獲得了靈活性，讓我們能將幾乎任何電腦轉換成EC2執行個體。
• 你想在雲端執行 Apple Mac？
• 好，Nitro做到了。
• 你需要在裸機EC2執行個體上直接存取底層硬體？
• Nitro也能處理。
• 但讓我們專注在這趟旅程的起點。
• 安全性。
• Nitro不只是改善了安全性，它徹底革新了我們對硬體供應鏈完整性的整個處理方式。
• 現在，雲端的安全性需要供應鏈完整性。
• 現在，雲端的安全性需要絕對確定性。
• 在 AWS，我們知道我們需要知道每一個硬體組件都在按照我們預期的方式執行我們預期的軟體。
• 這不僅僅是簡單地更新整個機群的軟體和韌體。
• 你需要密碼學證明，我們稱之為認證，來告訴我們每個系統上運行的是什麼。
• 而在我們的規模下，這是一個巨大的挑戰。
• 想想看。
• 我們在即時證明我們全球基礎設施中數百萬個組件的完整性。
• 讓我們把啟動序列的過程想像成一系列精心編排的步驟。
• 一切始於唯讀記憶體或 ROM，它啟動晶片的大部分基本部件，然後處理器載入下一層韌體。
• 接著是開機載入程式，它將控制權交給作業系統，最後到你的應用程式。
• 但這裡有個關鍵洞察：這些步驟中的每一步都代表一個潛在的弱點，一個可能執行未經授權程式碼的地方。
• 更根本的是，整個鏈條都依賴於一個信任根源。
• 所以真正的問題是如何驗證第一個環節。
• 為此，我們必須回到最開始。
• 製造車間，一台伺服器的旅程很長，從初始製造和組裝，經過運輸路線到我們的資料中心，最後安裝。
• 在每個步驟，我們都必須有信心沒有任何東西被破壞。
• 這不是事後發現漏洞的問題。 這是關於建立一個不間斷的監管和驗證鏈。
• 從組件製造的那一刻起，直到它們實際在真實客戶工作負載中運行。
• 讓我們深入了解我們其中一個基於Graviton4工作負載的啟動過程。
• 我們硬體安全性和信任根源的基礎就在Nitro晶片本身。
• 在每個 Nitro 晶片的製造過程中，都會產生並儲存一個獨特的密鑰。
• 你可以把它想像成晶片的獨特指紋，而且永遠不會離開矽晶。
• 這個密鑰成為公鑰私鑰對的基礎。
• 私鑰永久鎖在晶片內，而公鑰成為我們安全製造記錄的一部分。
• 這就是我們監管鏈的開始。
• Nitro晶片中的私鑰成為一個可測量啟動過程的錨點。
• 在啟動的每個階段，我們都會創建並簽署一個新的私鑰，銷毀前一個私鑰。
• 這就像是傳遞一個安全接力棒。
• 每次交接都必須完美，否則比賽就會停止。
• 這個簽名鏈讓我們能夠驗證從晶片的生產質量到韌體版本再到其身份的一切。
• 在通過這個完整認證過程之前，系統對 AWS 其餘部分的存取是受限的，任何失敗都意味著立即隔離和調查。
• 但有了Graviton，我們把安全邊界推得更遠。
• 基於Nitro安全基礎，我們將認證擴展到 Graviton4 處理器本身。
• 這實際上在關鍵系統組件之間創建了一個互鎖的信任網絡。
• 所以當兩個Graviton4處理器需要協同工作時。
• 它們首先會密碼學地驗證彼此的身份並建立加密通信。
• 同樣的事情也發生在Graviton4和Nitro之間，金鑰交換與主機身份綁定。
• 想想這意味著什麼。
• 系統中的每個關鍵連接，從 CPU 到 CPU 的通信到 PCIe 流量，都受到從製造開始就有的硬體安全保護，有了Nitro和Graviton4的協同工作，我們創建了一個持續的認證系統。
• 這不僅僅是安全性的漸進式改進。
• Nitro 硬體安全和 Graviton4 增強功能的組合創造了我們迄今最安全的運算產品之一。
• 對你來說，這意味著你的工作負載運行在從製造那一刻起到每一秒運作都經過密碼學驗證的硬體上。
• 這是在傳統伺服器和資料中心中完全不可能達到的安全性。

儲存基礎架構創新

• 但Nitro還能解決什麼其他挑戰？
• 要了解這點，我們需要看看儲存的動態變化。
• 硬碟容量的演進一直在持續。
• 每隔幾年，硬碟製造商就找到新方法在他們的碟片上放入更多資料。
• 如果我們回顧 AWS 早期，大約在2006年，我們使用的硬碟容量以百 GB 計算。
• 而今天，我們部署的硬碟容量達 20TB 甚至更大。
• 同時，由於設計、製造過程和材料的創新，過去幾十年每TB儲存的成本大幅下降。
• 因此，為確保我們的儲存系統始終以最高效率運作，我們需要確保我們隨時準備好迎接下一代硬碟容量和儲存創新。
• 現在，為了更好地理解這帶來的複雜性，讓我們仔細看看典型儲存系統的設計示例。
• 當我們思考像S3 和 EBS這樣的儲存服務時，它們由三個關鍵組件組成。
• 首先，你有前端叢集。
• 這些是處理 API 流量、認證請求和管理客戶介面的網路伺服器。
• 在它背後是我們稱為索引或映射服務的東西。
• 你可以把它想像成操作的大腦。
• 它追蹤每一個資料片段以及它們確切的儲存位置。
• 當客戶想要讀取他們的資料時，這個服務會告訴我們確切要去哪裡找到它。
• 最後，我們有儲存媒體層。
• 這是你實際資料所在的地方。
• 讓我們放大看看那個儲存伺服器。
• 傳統上，我們的儲存伺服器是用我們稱為頭節點架構建造的。
• 頭節點本身基本上就是一個標準的運算伺服器。
• 它有 CPU、記憶體、網路功能，並且運行專門的軟體來管理儲存的所有方面，包括關鍵功能如資料持久性和硬碟健康監控，以及協調所有 I/O 操作，連接到這個頭節點的是我們親切地稱為JBOD的東西。
• 這就是 Just a Bunch Of Disks（一堆硬碟）的簡稱。
• 這就字面上的意思 - 一個裝滿硬碟的機箱，全部都透過SATA 和 PCIe連接直接連到頭節點。
• 但這個設計有個問題：運算和儲存的比例在設計時就固定了。
• 一旦我們建造和部署這些伺服器，我們就被鎖定在特定的 CPU、記憶體和儲存容量比例。
• 現在，隨著硬碟容量這些年來急劇增長，這個固定比例變得越來越難有效管理。
• 所以最終結果是，我們一直在透過增加硬碟大小和數量來增加儲存系統容量的旅程中。
• 我們從相對適度的配置開始，也許是每個伺服器 12 或 24 個硬碟。
• 隨著硬碟技術進步，我們更擅長管理更大的硬碟池。
• 我們不斷推高這些數字每台主機 36 個硬碟，然後是 72 個，一直在尋找密度和可管理性之間的最佳平衡點。
• 然後我們創造了BODGE。
• BODGE是我們最雄心勃勃的儲存密度工程專案，一台巨大的儲存伺服器在單一主機中包含 288 個硬碟。
• 讓我們想想這個數字。
• 288 個硬碟。 用今天的 20 TB 硬碟，這就是單一伺服器接近 6 PB 的原始儲存容量。
• 這比 AWS 早期某些資料中心的總容量還要大。
• 這是我們試圖真正推動儲存密度可能極限的嘗試。
• 雖然這是一個令人印象深刻的工程成就，但它教會我們一些關於密度極限的關鍵教訓。
• BODGE教給我們的第一個教訓是關於物理限制，這些確實是很重的限制。
• 每個 BODGE 機架重達驚人的 4,500 磅。
• 那超過兩噸。
• 這在我們的資料中心造成了一些真正的挑戰。
• 我們必須加固地板，仔細規劃部署位置，使用特殊設備才能移動這些東西。
• 把 288 個轉動的硬碟放在一起，不只增加了重量，還創造了我喜歡稱之為振動管弦樂團的情況。把硬碟放在一起通常不是什麼大問題，但是當你有 288 個硬碟以 7200 RPM 的速度旋轉時，振動效應會變得足以實際影響硬碟的效能和可靠性。
• 然後還有軟體複雜性。
• 從單一主機管理 288 個硬碟把我們的軟體系統推到了極限。
• 想想你需要處理的所有不同故障模式。
• 資料放置演算法的複雜性，以及在如此大的硬碟池中維持一致效能的挑戰。
• 但也許最關鍵的教訓是關於故障影響範圍。
• 當 BODGE 伺服器故障時（伺服器確實會故障），影響是巨大的。 你突然要處理 6 PB 儲存可能無法使用的情況，即使有備援，這麼大量資料的恢復過程也需要大量時間和網路頻寬。
• 所以我們知道我們必須向BODGE說再見。
• 吸取了這些教訓，我們必須退一步思考。
• 如何在為客戶提供高效能的同時，減少操作複雜性並增加我們儲存基礎設施的靈活性？
• 為此，我們轉向我們的儲存服務尋求洞察。
• 像S3、EBS 和 EFS這樣的儲存服務都是建立在我們標準的儲存伺服器架構上，但它們有一些獨特的需求。
• 有些服務需要更多記憶體，有些需要較少運算能力。
• 但在儲存層本身，這些功能是相同的。
• 所以是運算和儲存的緊密耦合限制了我們嗎？
• 分離的概念 - 將運算和儲存分開 - 開始看起來非常有吸引力。
• 如果我們能找到方法保持服務所需的直接存取和效能，同時允許運算和儲存獨立擴展，我們可能能夠得到兩全其美。
• 這就是我們開始思考利用我們工具箱中已有的東西的時候。
• Nitro。
• 所以不是將這些硬碟連接到頭節點，我們通過將 Nitro 卡直接嵌入到這些 JBOD 機箱中來分離儲存。
• 把這些Nitro卡想像成給我們的硬碟自己的智慧和網路連接能力。
• 每個硬碟都是一個安全虛擬化、隔離的網路端點。
• 這個方法真正強大的地方在於我們保留了我們的硬碟和儲存服務原本擁有的直接、低層級存取能力。
• 同時我們完全突破了之前的物理限制。
• 而且Nitro處理所有的網路複雜性、加密和安全性。
• 因為Nitro是為高效能和低延遲設計的，我們即使透過網路存取也能發揮硬碟的原生效能。
• 這就是它在我們資料中心的實際樣子。
• 乍看之下，你可能認為這看起來像標準的JBOD機箱，但有一些關鍵差異。
• 我們談到的那些Nitro卡實際上是嵌入在這裡，和硬碟一起。
• 這個設計的美妙之處在於它的簡單性。
• 當你看進這些機架內部時，你會看到更像是網路交換器而不是傳統儲存伺服器的東西。
• 這也讓維護變得更簡單。
• 感謝我們的分離儲存架構，任何故障的硬碟都可以通過幾個 API 調用和熱插拔硬碟快速從服務中移除並替換。
• 容器讓我們的資料中心技術人員可以輕鬆維修這些單元，而不影響服務可用性。
• 所以硬碟故障不再是一個令人擔憂的問題。
• 但那些頭節點呢？
• 這就是事情變得真正有趣的地方。
• 在傳統架構中，頭節點故障是一個重大事件。 在你能修復或替換該伺服器之前，你會失去對數十或數百個硬碟的存取。
• 記得我們的BODGE例子嗎？
• 單一伺服器故障影響了 288 個硬碟。
• 而在分離儲存架構下，頭節點故障變得幾乎無關緊要，因為硬碟在網路上是獨立定址的。 我們可以簡單地啟動一個新的運算執行個體並重新連接所有硬碟。
• 這與我們用於標準EC2執行個體恢復的程序相同，通常只需要幾分鐘。
• 不需要資料移動，不需要複雜的重建過程。
• 只需重新連接並恢復操作。
• 這些故障情境突顯了一個關鍵點。
• 我們大大減少了故障影響範圍，同時實際上改善了恢復速度。
• 這只是將運算與儲存分離後可能實現的開始。
• 分離儲存的另一個強大好處是能夠獨立擴展運算和儲存在S3中。
• 當我們部署新的儲存容量時，通常會有一段高運算負載期，因為我們要讓資料在新硬碟間水合和重新平衡。
• 現在我們可以只為這個初始期間暫時向上和向外擴展運算資源，然後在正常操作時再縮減。
• 這種靈活性幫助我們更有效率地運作，最終為客戶提供更好的價值。
• 而有了分離儲存，我們成功擺脫了那些多年來限制我們儲存架構的固定比例。
• 通過分離運算和儲存，我們可以獨立擴展每個組件，同時保持高效能。
• 就像你在雲端環境中期望的那樣，我們大大減少了故障影響範圍。
• 現在，故障可以被限制，恢復更快，而且我們的服務比以往更有彈性。
• 而且我們看到了真實的運營效益，提高了靈活性。
• 我們的伺服器可以根據實際需求而不是硬體限制來調整它們的運算資源。
• 而且維護更簡單。
• 容量規劃更靈活，我們可以更快創新。
• 但也許最重要的是，這個架構為我們的未來做好準備。
• 隨著硬碟容量持續增長，分離儲存給予我們靈活性來調整和演進我們的基礎設施。
• 這開始是解決我們儲存密度挑戰的解決方案，但變成了更根本的東西。
• 一個新的基礎，幫助我們為你們，我們的客戶，建立更有效率、更可靠的儲存服務。
• 我就說到這裡，把時間交回給 Peter。
• [音樂]

AI 基礎設施創新

• 事實上，這包含兩種工作負載。
• 分別是AI 模型訓練和 AI 推理。
• AI 工作負載的一個特別有趣之處在於它們為我們的團隊提供了一個全新的發明機會。
• 今晚我們將看到一些這樣的創新，例如我們不斷突破自我，打造最高性能的晶片，並以創新技術將它們互相連接。
• 但我們也會探討如何將過去十年來推動的創新應用到這個新領域，為 AI 工作負載帶來 AWS 的高性能、可靠性和低成本。

AI 中的向上擴展與向外擴展

• 我們經常談論向外擴展的工作負載，如網路服務、大數據應用和分散式系統。
• 向外擴展的工作負載在添加額外資源時能夠高效運行。
• 我們已深入投資建立針對這些工作負載優化的基礎設施。
• 事實上，Dave 剛才已經向你介紹了一些這樣的創新。
• 但是AI 工作負載並非向外擴展的工作負載。 - 它們是向上擴展的工作負載。
• 讓我說明原因。
• 推動 AI 能力發展的其中一個因素是模型變得越來越大，而且規模驚人。
• 在 2022 年我談到這個話題時，我們對擁有數十億參數的模型感到興奮。
• 去年，我們對擁有數千億參數的模型感到興奮。 - 而不久的將來，前沿模型很可能擁有數兆個參數。
• 為什麼我們會看到這樣的成長？
• 在2020 年，研究人員發表了一篇具有開創性的論文，稱為縮放法則，它假設當你擴展某些要素時，模型能力會隨之提升，這些要素包括參數數量、數據集大小和計算量。
• 從那時起，我們看到了建立更大、更計算密集模型的推動力。
• 而這些模型確實變得更加強大。
• 你在日常生活中已經體驗到了這一點。
• 現在，如果你仔細觀察這些圖表，你會發現一些很有趣的事情。
• 這些是對數-對數圖表，也就是說圖表的 X 軸和 Y 軸都是對數刻度，而對數-對數圖表中的直線可能會產生誤導。
• 讓我們仔細看看計算圖表。
• 我們習慣於線性圖表，每當你增加一個 X，就會得到一個 Y。
• 這是一種線性關係。
• 但在對數-對數圖表中，直線代表乘法關係，例如當我們將 X 增加四倍時，Y 會增加兩倍。
• 而我們在這些縮放圖表中看到的結果令人震驚。
• 為了將損失(Y 軸上的度量)減半，我們需要使用一百萬倍的計算量。
• 一百萬倍。
• 現在，在這個 Y 軸測量上提升 50% 的模型，在許多其他基準測試上實際上會變得更加智能。
• 但是這種計算量和模型損失之間的關係解釋了為什麼業界投入數百億美元來建立更好的 AI 基礎設施。
• 但什麼是更好的 AI 基礎設施呢？讓我們來看看大型 AI 模型是如何訓練的。
• 在核心上，現代生成式 AI 應用是預測引擎。
• 你用一組標記(token)來提示它們，這些標記基本上是詞的片段，然後它們按順序一次預測一個標記。
• 從這個非常基礎的技能 - 預測下一個標記，一些令人驚嘆的特性就會浮現，比如推理、問題解決能力。
• 要建立這樣的預測模型，你需要用數兆個標記的數據來訓練模型，直到找到一組能夠在整個訓練數據上最小化預測誤差的模型權重。
• 而在所有這些標記上進行訓練的過程需要大量的計算資源，如果要在單一伺服器上訓練最大的模型，
• 即便是最強大的單一伺服器也需要數百年甚至數千年。
• 所以我們當然需要並行化，而最明顯的起點就是拆分訓練數據。
• 這看起來很直觀。
• 如果某件事在一台伺服器上需要一千年，那麼在一千台伺服器上運行應該只需要一年。
• 如果這是一個向外擴展的工作負載，這個說法是對的。
• 但可惜，事情並沒有這麼簡單。
• 我剛才描述的過程，也就是拆分數據，稱為數據並行。
• 就像生活中許多好東西一樣，數據並行也有一些附加條件。
• 如果你採用我描述的簡單分而治之方法，你實際上是在建立一堆獨立的模型，然後試圖在最後將它們組合起來。
• 這樣簡單是行不通的。
• 相反，在使用數據並行時，所有伺服器需要持續共享和組合它們的模型權重。
• 本質上是讓這個龐大的伺服器集群建立模型的一個共享版本。
• 這就是所謂的全局批次大小發揮作用的地方。
• 全局批次大小是在需要組合所有伺服器結果之前能夠處理的最大數據集。
• 而這個全局批次大小實際上只是你整體訓練數據中很小很小的一部分。
• 所以數據並行的實際運作方式是這樣的。
• 你先取得一塊不超過全局批次大小的數據。
• 接著你將這塊數據分成幾個相等的部分，分配給所有伺服器。
• 然後每台伺服器訓練它被分配的那部分數據，當完成時，它會將結果與集群中的其他所有伺服器組合在一起。
• 當每個伺服器都完成結果組合後，大家才能繼續處理下一批數據。
• 所以實際上，這個限制，也就是全局批次大小的限制，意味著你實際上只能將訓練集群擴展到最多幾千台伺服器。
• 如果你超過這個數量，每台伺服器實際獲得的數據量會變得非常小，以至於它花在協調結果上的時間比實際處理數據的時間還多。
• 所以如果你繼續增加伺服器，速度不會變快。
• 你只會增加成本。
• 因此理解數據並行的這些特性及其限制，突顯了 AI 基礎設施的兩個基本支柱。
• 首先，因為我們有來自全局批次大小的向外擴展限制，我們建立更大模型的途徑是建立更強大的伺服器。
• 這是基礎設施挑戰中的向上擴展部分。
• 其次，儘管在建立 AI 模型時存在向外擴展的限制，我們仍然能從建立這些非常大的集群中獲得很多價值。
• 而要做好這一點，我們需要利用我們多年來建立的向外擴展工具。
• 這包括高效的數據中心、快速擴展和優秀的網路功能。
• 讓我們先來看第一部分。
• 向上擴展的挑戰。
• 建立最強大的伺服器意味著什麼？
• 這意味著你想要一個一致的計算系統，在最小的空間內裝入盡可能多的計算能力和高速記憶體。
• 為什麼它必須要在最小的空間內呢？
• 因為將所有這些計算和記憶體放在一起意味著你可以使用大量的高頻寬、低延遲連接將所有東西連接起來。
• 延遲部分可能很容易理解，但是東西放得越近，你也能獲得更高的吞吐量。
• 原因是如果東西放得更近，你可以使用更短的導線來傳輸數據，這意味著你可以放入更多導線。
• 這也意味著你有更低的延遲，並且可以使用更有效率的協議來交換數據。
• 這聽起來很簡單，但實際上是一個非常有趣的挑戰。

Trainium Two 架構

• 去年，我們宣布了Trainium Two，我們下一代的Trainium晶片，今晚我要向你介紹我們如何使用Trainium Two來建立我們有史以來最強大的 AI 伺服器。
• 讓我們從系統最小的部分開始，也就是Trainium Two晶片。
• 在我們嘗試採用這個晶片並建立最大的 AI 伺服器的過程中，我會指出一些我們將遇到的工程限制。
• 晶片是在矽晶圓上使用極其精密的製造技術生產的。
• 這些製程一直在不斷改進。
• 所以如果你想在系統上獲得最多的計算和記憶體，一個很好的起點就是使用最先進的封裝或最先進的製造技術來建立最大的晶片。
• 這正是我們在Trainium Two上所做的。
• 但這裡我們實際上遇到了第一個工程限制。
• 晶片製造過程實際上有一個可以生產晶片的最大尺寸，這來自用於蝕刻矽晶圓的鏡頭。
• 這稱為光罩。
• 而且它將最大晶片尺寸限制在約 800 平方毫米，或 1.25 平方英寸。
• 現在你可能在想，我手中的東西看起來比 1.25 平方英寸大得多。
• 這是因為我手中拿的並不是晶片。
• 這是封裝。
• 當我們大多數人想到電腦晶片時，會想到主機板上散熱器下方的那個東西。
• 但那實際上是封裝。
• 晶片在封裝內部。
• 幾年前，封裝是一個相當簡單的東西。
• 它基本上是一種包覆單一晶片並將其連接到主機板的方式。
• 封裝使我們能夠從矽晶片的微小世界過渡到主機板上連接所有東西的較大導線。
• 但今天，封裝變得更加先進。
• 你可以將先進封裝理解為在單一封裝內連接多個晶片，使用一種稱為中介層的特殊裝置。
• 中介層本身實際上是一個小型晶片，而且它就像一個微型主機板，能提供約十倍於普通 PCB 主機板的頻寬來互連晶片。
• 在我們最近幾代Graviton處理器中，我們一直在使用先進封裝技術。
• 這裡你看到的是Graviton Three和Graviton Four，你可以看到這兩個晶片或封裝內都有多個晶片或晶粒。
• Graviton Four 封裝實際上有七個晶粒。
• 中間的大晶片是計算核心，周圍的較小晶片負責讓晶片存取記憶體和系統匯流排的其他部分。
• 通過分離計算核心，我們能夠以具成本效益的方式將 Graviton4 處理器的核心數量增加 50%。
• 這種方法在 Graviton 上非常有效，但在打造優秀的 AI 伺服器時，這只是基本要求。
• 這是Trainium Two封裝，也就是我手中拿的東西。
• 你可以看到我們在封裝中間並排放置了兩個 Trainium 晶片。
• 每個 Trainium Two 晶片旁邊都有兩個其他晶片。
• 這些晶片是HBM或高頻寬記憶體模組。
• HBM 是專用模組，包含多層堆疊的記憶體晶片，通過堆疊晶片，你可以在相同面積內放入更多記憶體。
• 這是可能的，因為記憶體晶片實際上使用較少的電力並產生較少的熱量。
• 好的，所以如果你看這個封裝，那確實是大量的計算和記憶體。
• 但你可能在想為什麼我們不能讓封裝變得更大？
• 就這樣繼續做下去。
• 這就是我們遇到第二個限制的地方。
• 要理解這一點，讓我們仔細看看。
• 現今封裝的實際限制大約是最大晶片尺寸的三倍，也就是你在這裡看到的大小。
• 如果你考慮這兩個晶片和 HBM。
• 在這個圖示中，我們移除了幾個 HBM 讓你看看中介層。
• 在下面你可以看到用於將晶片連接到中介層的所有微小凸點，但有一個更好的角度來看這個。
• 這是Annapurna團隊為我創建的一個非常酷的圖像。
• 他們沿著那條紫線仔細切割晶片做出橫截面，然後用顯微鏡從側面放大那個圖像。
• 你可以看到一些非常有趣的東西。
• 在左上方你看到 Trainium Two 計算晶片，旁邊是 HBM 模組。
• 一個非常酷的事情是你實際上可以看到 HBM 模組的層次，它們都坐落在一個薄薄的連續晶圓上。
• 這就是中介層，互連部分，晶片。
• 你還可以看到將晶片連接到互連器的微小連接。
• 你可以看到那些真的是非常微小的點。
• 晶片和中介層頂部之間的這些電氣連接小得驚人。每一個大約 100 微米。這比你見過的最細的鹽粒還要小。
• 所有這些連接都需要保持在原位，以確保晶片保持連接，這就是為什麼我們對封裝大小有限制，因為封裝必須保持足夠穩定以維持所有這些連接而且不要讓這些微小的尺寸誤導你，因為這些晶片有大量的電力和熱量在流動。
• 這些 Trainium 晶片中的一個可以在一秒內完成相當於人類數百萬年才能完成的計算。
• 要完成這些工作，這些晶片需要大量的供電。
• 在低電壓下移動所有這些電力，我們需要使用大型導線。
• 當然，“大"是一個相對的詞，但你可以看到封裝底部的這些導線。
• 晶片專家會稱這些為電源通孔。
• 我們需要使用大型導線的原因是為了避免所謂的電壓降。
• 半導體使用微小電荷的存在或缺失來儲存和處理資訊。
• 所以當晶片遇到電壓降或下降時，它們通常需要等待電力傳輸系統調整，而等待不是你希望晶片做的事情。
• 雖然晶片需要低電壓電力，但在較高電壓下傳輸電力更有效率，所以數據中心實際上會以多種電壓傳輸電力。
• 當它越來越接近晶片時，電壓會逐步降低。
• 最後一步是在電力進入封裝之前進行。
• 你可以通過查看我們的Trainium One主機板來看到這通常是如何完成的。
• 最後的電壓降低是通過盡可能靠近封裝放置的電壓調節器完成的。
• 我現在在板上標出它們來減少電壓降和優化 Trainium Two。
• 我們的 Trainium Two 團隊致力於將這些電壓調節器更靠近晶片。
• 這裡我們看到 Trainium Two 主機板，你會看到板子頂部沒有那些電壓調節器的蹤跡。
• 相反，電壓調節器實際上位於封裝的周邊下方。
• 這樣做相當具有挑戰性，因為電壓產生器會產生熱量。
• 所以你必須做一些創新的工程設計。
• 但通過將這些電壓調節器移近晶片，我們實際上可以使用更短的導線。
• 更短的導線意味著更少的電壓降。
• 這是 Trainium One 的視圖，你可以看到它在負載增加時的反應。
• 這是當你開始進行大量計算時發生的情況，你可以看到當負載突然增加時，電壓明顯下降。
• 雖然這很短暫，但電壓下降意味著晶片無法最佳化運算，而這種極端的變化實際上可能對晶片造成損害，可能縮短其使用壽命。
• 現在讓我們看看在 Trainium Two 上施加相同負載的情況。
• 注意這裡沒有明顯的電壓降，這是因為那些更短的導線。這意味著晶片不會降速，也意味著更好的效能。
• 好了，關於晶片的部分講得夠多了。
• 讓我們看看伺服器。
• 這是一個帶有兩台 Trainium Two 伺服器的機架，一個在上面一個在下面。
• 它們是大型伺服器，每台 Trainium Two 伺服器由八個加速器托盤組成，每個托盤包含兩個 Trainium Two 加速器板，每個都有自己專用的 Nitro 卡。
• 就像 NVIDIA 系統上的 GPU 一樣，Trainium 伺服器是加速器。
• 它們設計用於執行建立 AI 模型所需的數學和運算。
• 然而，它們不支援運行操作系統或程式所需的普通指令。
• 為此，你需要一個頭節點，這實際上是我們伺服器的工程限制。
• 我們可以放入伺服器的 Trainium 加速器數量實際上受限於頭節點有效管理和供給這些節點的能力。
• 所以在我們已經做到的基礎上增加更多加速器實際上只會增加成本而不會增加額外的性能。
• 這不是我們想要做的。
• 最後，你需要一個交換機來將所有加速器和頭節點連接到網路。
• 那麼一台 Trainium Two 伺服器有多強大呢？
• Trainium Two 伺服器是 AWS 最強大的 AI 伺服器，提供 20 太拍次的運算能力。這是 Trainium One 的七倍，比我們目前最大的 AI 伺服器多 25%。
• Trainium Two 伺服器還擁有 1.5TB 的高速 HBM 記憶體。這是我們目前最大 AI 伺服器的兩倍半。
• 這是一台向上擴展的伺服器，但擁有最強大的 AI 伺服器只有在你能快速將它交到客戶手中時才有意義。
• 幾年前，當新的晶片或伺服器問世時，你會看到一條類似這樣的採用曲線。
• 在伺服器生命週期的最初幾個月。
• 一些早期採用者可能會採用它。
• 通常是最大的資料庫和最苛刻的工作負載，而當這些早期採用者將他們的新工作負載移到硬體上時，許多早期的製造挑戰可以得到解決。
• 但 AI 的情況並非如此。由於更強大的伺服器對建立更好的模型的價值，客戶想要獲得最好的 AI 基礎設施，而且他們希望在第一天就能使用。
• 預料到這種前所未有的快速增長，我們在這裡也進行了創新。
• 讓我們再看看剛才看過的 Trainium Two 托盤。
• 現在，有趣的是你看不到什麼。
• 那就是大量的纜線。
• 這是因為團隊竭盡全力減少纜線數量而不是使用纜線。
• 所有這些元件都通過下方主機板上的導線軌跡互連。
• 為什麼他們要這麼做？
• 因為每個纜線連接都是可能出現製造缺陷的機會。
• 而製造缺陷會拖慢速度。
• Trainium Two 伺服器最酷的一點是它專門設計用於支援自動化製造和組裝。
• 這種高度自動化使我們能夠從第一天就快速擴展。
• 所以Trainium Two 不僅是我們最強大的 AI 伺服器，它還特別設計成比我們擁有過的任何其他 AI 伺服器都能更快擴展。
• 但這還不是全部。
• 一台強大的 AI 伺服器不僅僅是將原始計算和記憶體打包在小空間內。
• 它是一個專門用於優化 AI 工作負載的工具，這就是Trainium Two架構發揮作用的地方。
• 關於 Trainium 要理解的第一件事是，它使用了與傳統 CPU 或 GPU 完全不同的架構，稱為脈動陣列。
• 讓我快速向你展示它有何不同。
• 這裡我們展示了幾個執行指令的標準 CPU 核心。
• 雖然 CPU 有不同類型，但它們都有一些共同特徵。
• 首先，每個 CPU 核心都是一個完全獨立的處理器。
• 這就是為什麼你可以在現代 CPU 上同時運行多個進程。
• 這裡要注意的另一件事是，每個 CPU 核心在返回記憶體讀取或寫入數據之前只做少量工作。
• 這使 CPU 非常靈活，但也意味著性能最終受限於記憶體頻寬。
• 最後，雖然近年來 CPU 的核心數量大幅增加，但今天最大的 CPU 最多可能只有幾百個核心。
• GPU 是完全不同的東西。
• 現代 GPU 有數百或數千個運算核心，它們被組織成並行處理單元，GPU 能夠在相同空間內放入更多核心，讓多個核心在不同數據上執行完全相同的操作。
• 這意味著每個 GPU 核心並不完全獨立。
• 它實際上與其他核心綁定。
• 但這也意味著每個 GPU 核心可以用比 CPU 上完全獨立核心更少的晶體管來構建。
• GPU 架構大大加速了許多工作負載，從圖形處理開始，但最顯著的是 AI。
• GPU 無疑是一種革命性的硬體架構，但我們選擇了一種不同的方法，脈動陣列架構是一種獨特的硬體架構，因為它允許你創建長且互連的計算管道，而 CPU 或 GPU 則不行。
• 每個計算指令都需要讀取記憶體，做它的工作，然後寫回記憶體，而使用脈動陣列，我們可以通過直接將結果從一個處理單元傳遞給下一個來避免計算步驟之間的記憶體訪問。
• 這減少了記憶體頻寬壓力，並允許我們優化計算資源。
• 而對於 Trainium，我們實際上為 AI 工作負載設計了脈動陣列。
• 所以我們沒有像之前展示的那樣有一個線性的處理單元鏈。
• 而是有一個看起來更像這樣的東西。
• 我們的布局專門設計用於容納 AI 程式碼底層的常見矩陣或張量運算，這種架構使 Trainium 在最佳利用 AI 伺服器可用記憶體和頻寬方面比傳統硬體架構具有優勢。
• 神經網路核心介面或NICKI，是一種新語言，使你能夠開發和部署充分利用底層 Trainium 硬體的程式碼，讓你能夠實驗新方法來更具成本效益地建立 AI 應用。
• 我們很高興讓更多人實驗 Trainium。
• 所以上個月，我們宣布了Built on Trainium計劃，為研究人員提供 Trainium 硬體的使用權限來開發新技術。
• 來自加州大學柏克萊分校、卡內基梅隆大學、德克薩斯大學奧斯汀分校和牛津大學等大學的研究人員都很興奮能使用 Trainium 及其新穎的硬體功能來進行 AI 創新研究。
• 好的，所以我們用新穎的硬體架構打造了最強大的 AI 伺服器，這種架構針對 AI 工作負載進行了優化，而且我們準備好比以往任何時候都能更快擴展。
• 但是對於驅動最新前沿模型的最苛刻的 AI 工作負載呢？
• 對它們來說，最強大永遠都不夠。
• 這就是Neuron Links進入故事的地方。
• Neuron Link 是我們專有的 Trainium 互連技術。Neuron Link 使我們能夠將多台 Trainium Two 伺服器組合成一個邏輯伺服器，這些伺服器之間有每秒兩太位元組的頻寬，延遲為一微秒。
• 與傳統的高速網路協議網路不同，Neuron Link 伺服器可以直接存取彼此的記憶體，使我們能夠創造特別的東西，我們稱之為Ultra Server。
• 現在，我一直想把硬體帶上舞台，但每年都被勸阻了。
• 它會擋住螢幕。
• 順便說一下。
• 我很抱歉它擋住了螢幕，但今年，為了向你展示什麼是 Ultra Server，我們把一台 Ultra Server 帶上了舞台。
• 這是一台 Ultra Server，64 個 Trainium Two 晶片一起工作，提供比任何當前 EC2 AI 伺服器多五倍的計算能力，以及十倍的記憶體。
• 這就是你需要的那種伺服器。
• 如果你要建立一個具有數兆參數的 AI 模型。
• 非常酷。
• 現在我猜在座至少有一個人正在考慮建立一個具有數兆參數的 AI 模型。
• 但對於你們其他人來說，也會有一些東西。
• 讓我們看看每個人都在大量做的事情，那就是 AI 推理。
• 大型模型推理本身就是一個非常有趣且要求很高的工作負載。而實際上它是兩個工作負載。
• 第一個工作負載是輸入編碼，在這裡提示詞和其他模型輸入被處理，為產生標記做準備。
• 這個過程被稱為預填充，預填充需要大量計算資源來將輸入轉換成傳遞給下一個過程的數據結構。
• 一旦預填充完成，計算出的數據結構就會被傳遞給第二個推理工作負載，進行標記生成。
• 標記生成的一個有趣特點是，模型按順序一次生成一個標記，這對 AI 基礎設施提出了一套非常不同的要求。
• 每次生成標記時，整個模型都必須從記憶體讀取，但只使用少量計算，因此，標記生成對記憶體匯流排要求很高，但只需要很少的計算，這幾乎與預填充工作負載完全相反。
• 那麼這些工作負載的差異對你和 AI 基礎設施意味著什麼？
• 讓我們從你開始，不久前，像聊天機器人這樣的許多工作負載主要關注預填充性能，這是因為當預填充發生時，用戶通常在等待並盯著螢幕或旋轉圖標。
• 但一旦開始生成標記，你只需要比人類閱讀速度更快地生成它們。
• 而這並不是很快。
• 但越來越多的模型被用於代理工作流程中，在這裡你需要生成整個回應才能進入工作流程的下一步。
• 所以現在客戶既關心快速預填充，也關心真正快速的標記生成。
• 這就帶來了 AI 推理基礎設施需求方面正在發生的有趣事情。
• 對真正快速推理的渴望意味著 AI 推理工作負載現在也在尋找最強大的 AI 伺服器。
• 現在，好消息是，我們談到的這兩種不同工作負載是互補的。
• 預填充需要更多計算，標記生成需要更多記憶體頻寬。
• 所以在同一台強大的 AI 伺服器上運行它們可以幫助我們實現出色的性能和效率。
• 因此我們問自己，如何為推理將 Trainium Two 的優勢帶給 AWS 客戶？
• 我很高興宣布一個新的Amazon Bedrock 延遲優化選項，它允許你訪問我們最新的 AI 硬體和其他軟體優化，以在各種主流模型上獲得最佳推理性能。
• [掌聲]
• 延遲優化推理現在已開始預覽特定模型，其中一個模型是廣受歡迎的 Llama，我們很高興地宣布經過延遲優化的 Llama 405B 和較小的 Llama 2 70B 模型現在在任何供應商中都能在 AWS 上提供最佳性能。
• [掌聲]
• 現在這是Llama 405B的性能，這是最大也是最受歡迎的 Llama 模型。
• 我們在看處理請求和生成回應的總時間，所以它包括預填充工作流程和標記生成工作流程。
• 這裡數值越低越好，你可以看到 Bedrock 延遲優化版本比其他版本低得多。
• 但如果你使用其他模型呢？
• 我很高興宣布，通過與Anthropic的合作，我們正在推出新的且廣受歡迎的Claude 3.5模型的延遲優化版本。
• 根據請求的不同，延遲優化的 Haiku 3.5 運行速度比我們標準的 Haiku 3.5 快 60%，並且在任何地方都提供最快的 Haiku 3.5 推理而且。
• [掌聲]
• 和 Llama 一樣，Haiku 3.5 也在利用 Trainium Two 來實現這種性能。
• 但你不需要只相信我的話。
• 我很高興邀請我之前提到的縮放法則論文的其中一位合著者上台。

Anthropic 合作夥伴關係與雷尼爾計畫

• 請歡迎 Anthropic 的共同創辦人兼首席運算長 Tom Brown，分享他們如何在 AWS 上使用 Trainium 進行創新。
• [音樂]
• [音樂]
• 謝謝，Peter。
• 在 Anthropic，我們打造值得信賴的 AI。
• 每天全球數百萬人在工作中都仰賴 Claude。
• Claude 能寫程式碼、編輯文件，並使用工具完成任務。
• 說實話，我即將要講的這份簡報內容，有一半是 Claude 寫的。透過我們與 AWS 的合作關係，無論大小企業都能在他們已經信任的安全雲端平台上使用 Claude。
• 接下來我要更深入探討我們的合作方式。

Claude 效能優化

• 首先，讓我們談談 Peter 剛才提到的 Claude 3 P5 Haiku。
• 這是最新且最快速的模型之一。
• 儘管體積小，但它的表現相當驚人，有時甚至能匹配我們最大的模型 Opus 的性能。而成本卻只有 Opus 的 15 分之一。
• 如 Peter 提到的，我們一起合作打造了這個針對延遲優化的模式，讓客戶能在 Trainium Two 上更快速地運行 Haiku。
• 這意味著，從今天開始，你可以讓 Haiku 運行速度提升 60%。
• 你不需要做任何更改。只要在 API 上切換開關，你的請求就會被導向新的 Trainium Two 伺服器。
• 就是這麼簡單。
• [掌聲]
• 這樣的速度對於即時互動來說非常重要，我身為一名程式設計師。
• 想像在自動補全時，你需要在按鍵的短暫間隔內完成建議的標籤。60% 的速度提升在這裡帶來巨大的差異。
• 這可能是建議出現與否的關鍵差異。
• 那麼我們是如何讓它變得這麼快的呢？
• 首先，看看這個裝置。
• 它就是個野獸。
• 看看那台機器。
• 正如 Peter 告訴你的，裡面每個晶片都有驚人的規格，在那些收縮陣列中有超過一個 petaflop 的運算能力。
• 充足的記憶體頻寬，快速的互連。
• 它有很棒的規格，但正如每個工程師都知道的，光有規格還不足以獲得性能。
• 我們需要讓這些飢餓的收縮陣列始終保持運作。這意味著要對工作進行排序，確保它們永遠不會因為等待來自記憶體、互連或其他地方的輸入而被阻塞。
• 這就像玩俄羅斯方塊，你堆疊得越緊密，模型就變得越便宜也越快。
• 那麼我們如何解決這個俄羅斯方塊遊戲呢？
• Anthropic 的性能工程團隊已經與 Amazon 和 Annapurna 針對這個挑戰密切合作超過一年。
• 我們發現編譯器可以做很多事，但它並不完美，而在我們的規模下，追求完美是值得的。
• 對 Anthropic 來說，單一個性能優化就能釋放足夠的運算能力來服務一百萬新客戶。
• 這意味著值得降到更低的層級，像是使用 NIKI 並盡可能接近原始硬體來編寫核心程式。
• 這就像把程式中最重要的部分從 Python 轉換成 C 語言，而我們發現 Trainium 的設計非常適合這種低階編程。
• 可能很多人不知道，對於其他 AI 晶片來說，實際上沒有辦法知道你的核心程式正在運行哪些指令。
• 這意味著你必須靠猜測，就像蒙著眼睛玩俄羅斯方塊。
• Trainium 是我見過的第一個能夠記錄系統中每一條指令執行時間的晶片。
• 讓我展示給你看。
• 這是我們在 Anthropic 開發的一個真實的低階 Trainium 核心程式範例。
• 你可以在這裡精確地看到收縮陣列何時運行，何時被阻塞。
• 我們還可以看到它們被阻塞的確切原因，它們在等待什麼。
• 你可以拿掉蒙眼布了。
• 這讓編寫低階核心程式變得更快、更容易。
• 而且依我看來，變得更有趣了。

雷尼爾計畫公告

• 好的，說到有趣的事情，我有個消息要宣布。
• 你看，到目前為止我們一直專注於推理，但它之所以叫做 Trainium 是有原因的。
• 我很興奮地宣布，下一代的 Claude 將在雷尼爾計畫上訓練，這是一個擁有數十萬個 Trainium Two 晶片的新 Amazon 叢集。
• [掌聲]
• 數十萬個晶片意味著數百個密集的 exaflops，是我們曾經使用過的任何叢集的五倍以上。
• 那麼雷尼爾計畫對客戶意味著什麼？
• 好吧，世界已經看到我們用上一個叢集能做到什麼。
• 今年早些時候，Anthropic 推出了 Claude 3 Opus，世界上最智能的模型。四個月後，我們推出了 Claude 3 P5 Sonnet，比 Opus 更智能。成本卻只有五分之一。
• 在過去一個月，我們推出了 3.5 Haiku 和升級版的 3.5 Sonnet，能像人類一樣使用電腦。
• 雷尼爾計畫將進一步加快我們的發展，為我們的研究和下一代擴展提供動力。
• 這意味著客戶將以更低的價格獲得更高的智能，以及更快的速度。
• 更智能的代理，可以信任它們處理更大更重要的項目。
• 有了 Trainium Two 和雷尼爾計畫，我們不只是在打造更快的 AI，我們正在打造可擴展的值得信賴的 AI。
• 謝謝。
• [音樂]
• 謝謝你，Tom。
• 與 Anthropic 一起創新。
• 過去這一年是一段令人興奮的旅程，我們對未來的可能性感到振奮。
• 好的，我先前提到要打造最佳的 AI 基礎設施，你需要打造最強大的伺服器。
• 這是問題的擴展部分，但這只是故事的一半。
• 如果你想訓練最大的模型，你還需要建立最大的叢集，就像雷尼爾計畫。
• 這帶我們到故事的另一半。
• 擴展的故事。
• 這就是 AWS 在創新高性能、可擴展基礎設施方面的悠久歷史派上用場的地方。
• 這種擴展創新的一個很好例子就是建立彈性的、針對 AI 優化的網路。
• 現在，一個優秀的 AI 網路與優秀的雲端網路有許多共同點。
• 雖然一切都被大幅提升。
• 如果這是在拉斯維加斯的拳擊賽，這甚至不會是一場勢均力敵的比賽。
• 當然，雲端網路需要大量容量來確保網路永遠不會妨礙客戶。
• 事實上，James Hamilton 在我們第一次晚間主題演講中談到過這點，但是 AI 網路需要更多容量。
• 回想一下，每台 Trainium Two Ultra 伺服器都有將近 13TB 的網路頻寬，而且在訓練期間，每台伺服器都需要同時與其他所有伺服器通訊。
• 所以網路需要非常龐大，以確保永遠不會減慢這些伺服器的速度。
• 雲端網路需要快速擴展以適應增長。我們每天都在全球數據中心增加數千台伺服器，但如前所述，AI 的擴展速度更快。
• 當你花費數十億美元建立 AI 基礎設施時，你希望它能立即安裝完成，而雲端網路需要可靠。
• 它們一直都在提供服務，提供比最先進的本地網路更好的可用性。
• 我們的全球數據中心網路擁有五個九的可用性，但在這裡，AI 工作負載的要求更高。
• 如果 AI 網路經歷哪怕是暫時性的故障，訓練過程可能會在整個叢集範圍內延遲，導致閒置容量和較長的訓練時間。
• 那麼，你如何在雲端網路的創新基礎上打造一個優秀的 AI 網路呢？

TNP TEN 網路架構

• 這是我們最新一代的 AI 網路架構圖，我們稱之為 TNP TEN 網路。
• 這是一個為我們的 UltraServer Two 叢集提供動力的網路架構。
• 而且我們在 Trainium 和 NVIDIA 的叢集上都使用這個網路。
• 我們稱它為 TNP TEN，是因為它能夠以低於十微秒的延遲，為數千台伺服器提供數十個 petabyte 的網路容量。
• TNP TEN 網路具有高度並行性和密集互連的特性，而且具有彈性。
• 我們可以將它縮小到只有幾個機架的規模，也可以擴展到跨越數個實體數據中心園區的叢集。
• 這裡你看到的只是 TEN PE TEN 的單一機架。
• 你現在可能注意到這些交換器是美麗的綠色。
• 綠色其實是我最喜歡的顏色。
• 我比較喜歡英國賽車綠，但這也是個不錯的顏色，我從未在我們的數據中心看過綠色的交換器。
• 所以我問團隊為什麼選這個綠色。
• 這個綠色叫做「新綠」，是 2017 年 Pantone 年度顏色。
• 顯然我們的一個供應商有一些多餘的油漆，給了我們一個很好的優惠。
• 我喜歡這個故事，因為它反映了我們的設計理念。
• 在對客戶重要的事情上投資，在不重要的事情上（比如油漆）省錢。
• 現在，你可能還注意到這個機架有很多網路線。
• 不是綠色的部分是網路配線或配線面板，要建立這樣密集的網路架構，你需要以非常精確的模式將交換器互連。
• 這就是配線面板的作用。
• 這些配線面板多年來一直為我們提供良好服務。
• 但如你所見，TNP TEN 網路的情況變得相當混亂，因為線路複雜度已經顯著增加。
• 而且如前所述，我們安裝的速度越來越快。
• 所以這是團隊創新的絕佳機會。
• 他們的創新之一是開發了專有的主幹連接器。你可以把它想像成一個超級線纜，將 16 條獨立的光纖線整合成一個堅固的連接器。
• 這項技術之所以能改變遊戲規則，是因為所有複雜的組裝工作都在工廠完成，而不是在數據中心現場進行，這大大簡化了安裝過程，並且實際上消除了連接錯誤的風險。
• 雖然這聽起來可能不起眼，但它的影響卻很重大。
• 使用主幹連接器將我們的 AI 機架安裝時間縮短了 54%，更不用說讓整體外觀更整潔了。
• 那些綠色的交換器現在真的很搶眼，但團隊並沒有就此停止創新。
• 這是另一個很棒的創新。
• 他們稱之為 Firefly 光纖插頭，這個巧妙的低成本裝置作為一個微型訊號反射器，讓我們能夠在機架抵達數據中心現場之前，全面測試和驗證網路連接。
• 這意味著當我們的伺服器到達時，我們不會浪費時間除錯、除錯線路。
• 這很重要，因為在 AI 叢集的世界裡，時間就是金錢。
• 但這還不是全部。
• Firefly 插頭還有雙重用途，可以作為保護密封，防止灰塵顆粒進入光纖連接，這聽起來可能很小事，但是 即使是微小的灰塵顆粒也會顯著降低完整性並造成網路性能問題。
• 所以這個簡單的裝置也提升了網路性能。
• 因此，透過一個優雅的解決方案，我們解決了兩個關鍵挑戰，就像一石二鳥一樣，正是這樣的創新幫助我們讓 TNP TEN 網路成為我們有史以來擴展最快的網路。
• 你可以在這張圖表上看到我們在不同網路架構中安裝的連接數量。
• TNP TEN 網路的增長速度即使對我們來說也是前所未有的。在過去 12 個月裡，我們安裝了超過 300 萬個連接，而這還是在我們開始考慮 Trainium Two 的擴展之前。
• 這讓我們來到最後一個挑戰：提供更高的網路可靠性。
• AI 網路中最大的故障來源是光纖連接。
• 光纖連接是在我們一直在看的這些線纜上發送和接收光信號的微型雷射模組，AWS 多年來一直在設計和運營我們自己的定制光學元件，由於我們的運營嚴謹性和龐大規模，我們能夠持續降低故障率。
• 這是規模帶來的令人印象深刻的進展。
• 但無論我們如何降低這些故障，我們永遠無法完全消除故障。
• 所以我們需要考慮如何減少故障的影響。
• 每個網路交換器都需要數據來告訴它們如何路由封包。
• 這些基本上是網路的地圖，在 AI 網路中，這個地圖可能需要考慮數十萬條路徑。
• 每當光纖連接發生故障時，地圖就需要更新。
• 那麼我們如何快速可靠地做到這一點？
• 最簡單的方法是集中管理地圖，一個大腦。
• 中央優化網路聽起來很吸引人，但當你的網路龐大時，中央控制會成為瓶頸。偵測故障很困難，更新交換器可能會非常慢，而且中央控制器是一個單點故障。
• 這就是為什麼大型網路通常會去中心化，使用像 BGP 和 OSPF 這樣的協議。
• 交換器與鄰居共享健康狀態更新，並協作產生適合它們的網路地圖。
• 這些方法很穩健但不完美。
• 在大型網路中，當連接發生故障時，網路交換器可能需要相當長的時間來協作並為網路找到新的最佳地圖。
• 而在 AI 網路中，那就是你無法工作的時間。
• 所以當面臨兩個次優選擇時，你通常需要開闢一條新路。
• 因此，在我們的 TNP TEN 網路中，我們決定建立一個全新的網路路由協議。
• 我們稱這個協議為 可擴展意圖驅動路由，或稱 CIDR。
• 是的，對在場的網路人員來說，這可能是個雙關語。
• CIDR 給你兩全其美的好處。一個簡單的理解方式是，你讓中央規劃者工作，將網路提煉成一個結構，可以推送到網路中的所有交換器，這樣當它們看到故障時就能快速做出自主決定。
• 所以 CIDR 給我們中央規劃、控制和優化，同時具備去中心化的速度和彈性。
• 結果是 CIDR 能在一秒內響應故障。即使在我們最大的 Neptune 網路上，這也比我們在其他網路架構上使用的替代方案快十倍。
• 當其他網路可能還在重新計算路由時，TNP TEN 網路已經回到工作狀態了。
• 好了，今晚我們談了很多核心創新。
• Dave 談到了橫跨我們的投資，像是 Nitro 和 Graviton 以及儲存，到我們如何用 Trainium Two 打造最大、最強大的 AI 伺服器，再到 AI 如何從我們多年的雲端擴展創新中受益。
• 希望你們今晚離開時能夠理解我們如何在整個技術堆疊上進行創新，為你們打造真正與眾不同的產品。
• 我們的客戶。
• 說到這裡，我想說晚安。
• 謝謝，祝你們在 re:Invent 玩得愉快。
• [掌聲]