(圖說：AWS re:Invent 2025 Keynote with Peter DeSantis and Dave Brown。圖片來源：AWS。)
AWS Utility Computing 資深副總裁 Peter DeSantis 與 Dave Brown 在 re:Invent 2025 登台發表主題演講，深入探討驅動 AI 時代的基礎設施根基。他們並未追逐最新的 AI 炒作，而是提出了一個有力的論點：我們過去二十年所仰賴的核心雲端屬性——安全性、可用性、彈性、敏捷性與成本——在今天比以往任何時候都更加重要。發布內容涵蓋 Graviton5（單一封裝 192 核心，L3 快取提升 5 倍）、Lambda Managed Instances（橋接 EC2 與 Lambda 的鴻溝）、S3 Vectors 正式可用（在 20 億向量上實現次 100 毫秒查詢）。在 AI 加速方面，Trainium3 UltraServer 每百萬瓦輸出 5 倍 tokens，而 PyTorch 原生支援意味著將 GPU 程式碼移植到 Trainium 僅需修改一行程式碼。
✳️ tl;dr 重點摘要
一個主題「Infrastructure Fundamentals for the AI Era」貫穿全場，分為六大段落：
- 核心雲端屬性：安全性、可用性、彈性、敏捷性與成本仍然是根基。這些屬性引導了 AWS 過去 20 年的每一個決策，在 AI 時代更加關鍵。
- Nitro 與 Graviton 演進：從消除虛擬化抖動的客製化晶片（Nitro）到提供 192 核心與 5 倍 L3 快取的 Graviton5。M9g 執行個體效能比 M8g 提升最高 25%。客座講者：Payam Mirrashidi（Apple）分享 Swift + Graviton 達成 40% 效能提升。
- 無伺服器擴展：Lambda Managed Instances 橋接 EC2 效能與 Lambda 簡便性之間的鴻溝。你的 Lambda 函數運行在你選擇的 EC2 執行個體上，而 Lambda 負責管理佈建、修補、擴展。
- 推論與 Bedrock 架構：Project Mantle 推論引擎為 Bedrock 提供動力，支援服務層級（priority、standard、flexible）、逐客戶佇列公平性、Journal 容錯機制，以及機密運算。
- 向量搜尋與 S3 Vectors：Nova Multimodal Embeddings 將文字、圖像、影片、音訊統一到共享的向量空間。S3 Vectors GA 在 20 億向量上實現次 100 毫秒查詢。4 個月內建立超過 25 萬個向量索引。客座講者：Jae Lee（TwelveLabs）談影片智慧。
- Trainium3 與 AI 加速：Trainium3 UltraServer 搭載 144 顆晶片、360 PetaFLOPS、20TB HBM。每百萬瓦輸出 5 倍 tokens。NKI GA 與 Neuron Explorer 用於效能分析。PyTorch 原生支援。客座講者：Dean Leitersdorf（Decart）談即時視覺智慧。
內容大綱
✳️ Structure 演講結構
Peter DeSantis 與 Dave Brown 的這場主題演講乍看之下像是一場深入硬體的技術演講，但實際上圍繞著一個主題和六大段落來組織。Peter 負責開場與結尾，Dave 負責 Graviton 與 Bedrock 段落。三位客座講者提供真實世界的客戶觀點。
一個主題「Infrastructure Fundamentals for the AI Era」貫穿全場，分為六大段落：
- 核心雲端屬性
- Nitro 與 Graviton 演進
- 無伺服器擴展
- 推論與 Bedrock 架構
- 向量搜尋與 S3 Vectors
- Trainium3 與 AI 加速
邏輯脈絡從根基到前沿。「核心雲端屬性」確立了基礎並未改變；「Nitro 與 Graviton」展示客製化晶片如何實現這些基礎；「無伺服器擴展」重新想像運算的光譜；「推論與 Bedrock」應對 AI 工作負載的新擴展挑戰；「向量搜尋」為資料所在之處帶來智慧；「Trainium3」推動 AI 的成本效能前沿。整體進程從通用運算到 AI 專用加速，反映了 AWS 基礎設施如何透過相同的核心原則來演進，同時服務傳統與 AI 工作負載。
✳️ Highlights 精華摘要
核心雲端屬性（Core Cloud Attributes）
- 安全性（Security）
- AI 工具同時被建構者和攻擊者使用，使得雲端安全比以往更加關鍵
- AWS 將安全性定位為每一項服務和 API 決策的首要優先事項
- 可用性（Availability）
- AI 應用程式的龐大規模和體量，需要一個經過過去十年最嚴苛工作負載考驗的雲端
- 彈性（Elasticity）
- 雲端為新創公司消除了容量規劃的問題；現在的目標是將同樣的 S3 級別彈性帶到 AI 工作負載
- 敏捷性（Agility）
- 廣度與深度兼具的建構模組方法是刻意的選擇，而非偶然
- 當限制被移除，建構者的思維從「我能不能建構這個」轉變為「接下來我要建構什麼」
- 建構模組的力量將透過自主式（agentic）開發被放大
- 成本（Cost）
- AI 的建構與運行成本高昂；AWS 正在深入投資降低成本，而不僅僅是擴大容量
Nitro 與 Graviton 演進（Nitro and Graviton Evolution）
- Nitro System
- 客製化晶片，將虛擬化從伺服器移至專用硬體
- 消除虛擬化抖動，實現優於裸機的效能
- 現已被收錄於 Patterson 與 Hennessy 的電腦架構教科書第七版
- 直接接觸晶片散熱（Direct-to-Silicon Cooling）
- Graviton 移除保護蓋和一層散熱介面材料（TIM）
- 降低熱阻，風扇功耗減少 33%
- 這只有在 AWS 掌控整個系統堆疊的情況下才有可能實現
- Graviton5（預覽版）
- 單一封裝 192 核心（無需一致性連結）
- L3 快取為前幾代的 5 倍以上
- 每個核心可獲得最高 2.6 倍的 L3 快取
- 消除了 Graviton4 雙 CPU 配置中存在的跨 CPU 互連延遲
- M9g 執行個體（預覽版）
- 效能比 M8g 提升最高 25%
- EC2 中目前最佳的價格效能
- 早期客戶成果：Airbnb 提升最高 25%、Atlassian 延遲降低 20%、Honeycomb.io 每核心提升 36%、SAP OLTP 提升 60%
- Apple 使用 Graviton（客座講者：Payam Mirrashidi）
- 每天使用 Swift on Graviton 處理數十億次請求
- 效能提升 40%，成本降低 30%
- iOS 26 的垃圾郵件偵測使用 Swift on Graviton 搭配同態加密
- 原生 Swift 工具鏈現已支援 Amazon Linux
無伺服器擴展（Serverless Expansion）
- Lambda 起源故事
- 源自 S3 團隊的洞察：將運算直接附加到儲存層，在物件抵達時進行處理
- 2014 年推出，將思維從「從伺服器開始」轉變為「從程式碼開始」
- Lambda Managed Instances
- Lambda 函數運行在你帳戶內的 EC2 執行個體上
- 你選擇執行個體類型；Lambda 負責管理佈建、修補、可用性與擴展
- 現有的 Lambda 函數無需修改程式碼即可繼續運行
- 為影片處理、ML 前處理、高吞吐量分析開啟大門
- 無伺服器從來就不是指沒有伺服器，而是指沒有伺服器管理
- EC2 與 Lambda 團隊整合
- 兩年前，Lambda 與 EC2 團隊被合併到同一個組織
- 運算現在被視為一個選擇的光譜，而非僵固的框架
推論與 Bedrock 架構（Inference and Bedrock Architecture）
- Project Mantle
- 驅動許多 Amazon Bedrock 模型的全新推論引擎
- 從零開始設計，基於大規模的真實客戶工作負載模式
- 推論流水線複雜度
- 四階段流水線：tokenization、prefill、decode、detokenization
- 同時受限於 CPU、GPU 運算、記憶體頻寬，且對延遲敏感
- 服務層級（Service Tiers）
- Priority：即時且延遲敏感的互動
- Standard：穩定且可預測的工作負載
- Flexible：效率比速度更重要的背景作業
- 透過佇列隔離實現公平性
- 每個客戶擁有自己的佇列；一個客戶的突發流量不會影響其他客戶
- Bedrock 學習典型的使用模式並預測容量需求
- Journal 容錯機制
- 高可靠性的交易日誌（同時驅動 DynamoDB 和 S3）
- 持續捕捉推論請求狀態；在發生故障時從中斷處精確恢復
- 支援將微調作為長時間運行的作業，在推論尖峰時暫停，之後恢復
- 機密運算（Confidential Computing）
- 資料始終加密；操作人員無法存取環境
- 密碼學保證，確保請求在經過驗證且受信任的環境中執行
- 深度 AWS 整合
- 支援從 Bedrock 呼叫 Lambda 函數的工具呼叫
- 支援 OpenAI Responses API 的長時間運行作業
- IAM 用於權限管理，CloudWatch 用於可觀測性
向量搜尋與 S3 Vectors（Vector Search and S3 Vectors）
- Nova Multimodal Embeddings
- 最先進的 embeddings 模型，支援文字、文件、圖像、影片與音訊
- 將所有模態轉換為共享的向量空間，具備業界領先的精確度
- 消除專用模型產生不相容 embeddings 的問題
- 跨 AWS 服務的向量搜尋
- 向量功能整合到現有的資料庫與分析服務中
- OpenSearch 演進為支援混合搜尋（關鍵字 + 語意）的向量驅動智慧引擎
- 無需學習全新的技術堆疊
- S3 Vectors GA
- 建立向量索引就像建立 S3 bucket 一樣簡單
- 無需佈建，支援任何規模，按使用量付費
- 預先計算的向量鄰域實現高效搜尋，無需將所有向量保存在記憶體中
- 在 20 億向量的生產環境中實現次 100 毫秒查詢時間
- 預覽版 4 個月內：建立超過 25 萬個向量索引、寫入超過 40 億個向量、執行超過 10 億次向量搜尋
- TwelveLabs（客座講者：Jae Lee）
- 基礎模型（Marengo 和 Pegasus）可跨視覺、聲音與時間理解影片
- S3 Vectors 儲存數十億個影片 embeddings，零資料遷移
- ArcXP（Washington Post 延伸服務）使用 TwelveLabs 分析與豐富歸檔影片內容
Trainium3 與 AI 加速（Trainium3 and AI Acceleration）
- Trainium3 UltraServer
- 144 顆 Trainium3 晶片分布在兩個機架中，組合成單一 AI 超級電腦
- Neuron 交換器提供全雙向頻寬，延遲極低
- 360 PetaFLOPS（FP8）、20TB HBM、700TB/s 記憶體頻寬
- 原始運算能力提升 4.4 倍，頻寬提升 3.9 倍（相比前一代）
- 首個在同一主機板上使用三種 AWS 客製化晶片（Trainium3、Graviton、Nitro）的系統
- 頂部可維修設計，支援機器人組裝與更快速的車隊部署
- Graviton 共置於同一滑軌上，消除對專用主控節點的需求
- 微架構創新
- 微縮放（micro scaling）實現更低精度同時保持準確度
- 更快的 softmax、tensor dereference、背景轉置
- 流量整形（traffic shaping）、memory add-right、memory hash spraying 實現高效資料流
- 這些最佳化不會出現在規格表上，但顯著改善真實工作負載的效能
- NKI（Neuron Kernel Interface）GA
- 結合矩陣運算的簡潔性與直接指令層級的硬體存取
- 熟悉的 Python 程式設計環境
- 完整開源 neuron NKI 堆疊
- Neuron Explorer
- Trainium 晶片上的專用分析硬體，在不影響效能的情況下分析生產環境程式碼
- 指令層級精確度的效能分析
- 自動偵測瓶頸並建議最佳化方案
- 效能：每百萬瓦 5 倍 tokens
- GPT-OSS 1200 億參數模型：Trainium3 相比 Trainium2 每百萬瓦輸出 5 倍 tokens
- 維持相同的使用者可見延遲
- 包含 NKI kernels 的程式碼將開源
- PyTorch 原生支援
- 將一行程式碼從「cuda」改為「neuron」即可在 Trainium 上運行
- 消除學習新軟體堆疊的需求
- 預計 2026 年初廣泛釋出
- Trainium3 為最嚴苛的 AI 工作負載提供最高 40% 的成本降低
- Decart（客座講者：Dean Leitersdorf）
- 即時視覺智慧：一個全新的 GenAI 基礎模型類別
- 舞台上的每一個像素都使用 Trainium3 即時生成
- Megakernel 在同一顆晶片上同時運行 LLM、影片模型和編碼器，零延遲
- 80% tensor core 使用率；預計達到比最先進 GPU 快 4 倍的效能（fps）
- 應用場景：Twitch 串流、虛擬試穿購物、體育賽事卡通渲染、自生成遊戲、機器人模擬
✳️ Watch the Video 觀看影片
內容來自 AWS re:Invent 2025。完整場次：AWS re:Invent 2025 - Keynote with Peter DeSantis and Dave Brown。
✳️ Knowledge Graph 知識圖譜
(更多關於 Knowledge Graph…)
總覽
基礎設施演進
運算光譜
✳️ Transcripts 逐字稿
AWS re:Invent 2025 - Keynote with Peter DeSantis and Dave Brown - YouTube https://www.youtube.com/watch?v=JeUpUK0nhC0
1️⃣ Core Cloud Attributes 核心雲端屬性
Welcome & Keynote Intro 歡迎與演講開場
- 請歡迎 AWS 公用運算資深副總裁 Peter DeSantis。
- 早安。
- 歡迎來到 re:Invent 2025 的倒數第二天。
- 感謝大家這週的參與。
- 這是很棒的一週。
- 我希望你們跟我們一樣玩得開心。
- 我想在座很多人今天早上可能以為會看到 Werner，我理解，我們把順序調換了。
- 你們這整週都很忙，所以我有備而來。
- 請大家把目光轉向旁邊的螢幕。
- 希望這樣感覺比較熟悉一點。
- 不認識我的人，我通常負責週一晚上的 keynote。
- 我問過能不能準備啤酒，但顯然早上的 keynote 不能喝啤酒。
- 說得也是，但我很抱歉。
- 喝個幾杯之後我會比較有趣。
- 好，如果我的過場沒有讓你滿足，今天下午的閉幕 keynote 可以看到真正的 Werner，就像他說的，他們會是你和派對之間的最後一道關卡。
Core Cloud Attributes 核心雲端屬性
- 我不會爆雷，但 Werner 告訴我他會談這次 AI 轉型對我們開發者意味著什麼。
- 這讓我開始思考，這次 AI 轉型對雲端又意味著什麼？
- 我覺得答案很明顯。
- 這一代由 AI 驅動的應用程式將會帶動基礎設施的大量創新，這對我們來說很令人興奮。
- 但我想先從那些大概不會改變的事情開始談起。
- 這些是我們從 AWS 創立之初就專注交付的東西，是我們真正在意的事情。
- 我認為這些東西甚至可能更加重要。
- 這些就是 AWS 雲端的核心屬性，交付這些屬性引導了我們做過和持續在做的每一項服務、每一個 API、每一個技術決策。
- 我們花了非常多時間思考這些事情，並且進行了深入、長期的投資來支撐這些屬性。
- 以安全性為例。
- 你們大概已經知道了，不只好人在用 AI 變得更有生產力。
- 壞人也在用同樣的工具來攻擊你們的產品、你們的客戶和你們的基礎設施。
- 所以現在比以往任何時候都更重要的是，你要知道你的雲端供應商把安全性放在第一優先。
- 緊接在安全性後面的，就是可用性，還有現在正在建構的應用程式所需的巨大規模。
- 需求量。
Elasticity & AI Workloads 彈性與 AI 工作負載
- 從安全性到資料庫、分析、網路的效能表現。
- 所以現在是建構在一個經過驗證、跑過過去十年最嚴苛工作負載的雲端上的最佳時機。
- 那彈性呢？
- 雲端最重要的事情之一，就是它消除了容量規劃。
- 不久之前，新創公司最先要做的事情之一就是規劃和配置他們的基礎設施。
- 這完全是在浪費時間。
- 更糟的是，「我需要多少容量？」這個問題根本沒有正確答案。
- 如果你規劃得太少，你會錯過你的重要時刻。
- 規劃得太多，你可能負擔不起撐到那個重要時刻。
- 而今天，容量規劃大概是你完全不需要做的事情了。
- 這是一件好事。
- 當你需要的時候，AWS 已經準備好為你擴展，但我們還沒做完。
- AI 工作負載在過去幾年帶來了前所未有的需求增長，我們把這看作一個機會，將我們過去二十年來持續開發的創新應用到這些新技術上。
- 我們的目標是讓你的 AI 工作負載獲得跟 S3 這類服務一樣的彈性，今天早上你會聽到更多關於我們如何做到這一點的內容。
Cost, Agility & Building Blocks 成本、敏捷性與建構元件
- 接下來談成本。
- AI 的前景令人興奮，它將改變我們生活的每個面向。
- 但任何把 AI 應用部署到正式環境的人都知道，AI 可不便宜。
- 建構這些高效能模型非常非常昂貴，而要跑大量的推論來讓這些模型改變我們的生活，成本更是高得多。你幾乎每天都看到數百億美元被投入資料中心、電力和容量來支撐這次 AI 轉型的新聞標題。
- AWS 也在大舉投資這些擴展。
- 但我們還在做另一件事。
- 我們在深入投資降低建構這些模型和運行這些工作負載的成本。
- 這週你們已經聽到一些關於 Trainium 的內容，但今天早上稍後，我們會分享更多關於我們如何打造 Trainium 來實質降低這些工作負載成本的資訊。
- 最後是敏捷性。
- 大約 20 年前我們推出 AWS 時，我認為對雲端成功貢獻最大的屬性就是敏捷性。
- 很快就變得很明顯，採用雲端的公司能比留在地端的公司動得更快。
- 他們能更快地創新。
- 他們能更快地為客戶交付價值。
- 他們能以更少的問題更快地成長。
- 最重要的是，他們能更快地轉向。
- 這就是敏捷性。
- 這就是雲端的魔力。
- 你可以快速啟動、優化、轉向。
- 聽起來是不是正好就是你在這次 AI 轉型中所需要的？
- AWS 有很多方式幫助你變得更敏捷，其中一種就是確保你有適合工作的正確工具。
- 無論你是一家正在發明新東西的新創公司，還是一家正在現代化舊系統的企業，我們提供你建構任何你想像得到的東西所需的建構元件，而這種廣度和深度的做法。
- 不是偶然的。
- 這是我們年復一年刻意做出的選擇，持續投資新服務、新功能和新的建構方式。
- 因為我們相信，當我們移除限制、給你每一個可能的建構元件時，真正的魔法才會發生。
- 那時候你就可以不再問「我能不能建構這個」，而是開始問「接下來我要建構什麼？」
- 而真正令人興奮的是，這些建構元件的威力只會透過自主式開發（Agentic development）被進一步放大。
- 所以在 AI 世界中重要的事情，跟我們過去 20 年一直在專注的事情完全相同，但這些能力不會憑空出現。
- 你不會某天醒來就說，我想要更好的安全性或更低的成本。
- 這些屬性來自於長期非常深入的承諾和投資。
- 讓我給你們看我最喜歡的例子。
2️⃣ Nitro & Graviton Evolution Nitro 與 Graviton 演進
Nitro System Evolution Nitro 系統演進
- 讓我先鋪陳一下背景。
- 那是 2010 年，我們推出 EC2 幾年之後。
- 到那個時候，很明顯客戶很喜歡 EC2，他們想在上面跑各式各樣的工作負載。
- 大多數情況下，他們可以做到。
- 我們的效能表現完全沒問題。
- 但對於少數最嚴苛的工作負載，我們面臨了一個挑戰。
- 雖然我們的系統大部分時候都能交付很好的效能，但我們會看到這些令人沮喪的離群延遲，或者我們稱之為抖動（jitter）的現象，效能會突然下降，只有幾百微秒，但足以影響這些應用程式。
- 這些偏差來自虛擬化層。
- 虛擬化是 EC2 的關鍵推手之一，它運作得非常好。
- 但當時的普遍看法是，虛擬化對於要求不高的工作負載沒問題，但它永遠無法達到裸機伺服器的效能。
- 但這跟我們對 EC2 的願景不相容，我們想要跑所有的工作負載。
- 所以我們非常專注於解決抖動問題。
- 基本上，我們的目標是把抖動趕到它該待的地方。
- 每週接著每週，我們的工程師深入分析資料，處理這些離群延遲。
- 我們透過優化取得了令人印象深刻的進展，坦白說達到了許多人認為不可能的成果。
- 但最終很明顯，我們沒有一條通往裸機效能的路徑。
- 總是會有一些虛擬化的代價。
- 所以當然，你必須改變什麼是可能的。
- 這就是 Nitro 系統登場的地方。
- Nitro 是我們 AWS 自行設計的客製化晶片。
- 它把虛擬化從伺服器移到專用硬體上，這讓我們能完全消除抖動問題，實際上達到了完全相同的，事實上，比裸機更好的效能。
- Nitro 還改善了安全性、提供更高的效能，並讓我們能支援多種執行個體類型。
- Nitro 系統是我們所做的深度投資的絕佳範例，在這個案例中，我們實際上自己打造晶片來實現我剛才談到的那些關鍵產品屬性。
Book Giveaway & Graviton Intro 贈書活動與 Graviton 介紹
- 對於那些週一晚上有來聽我演講的人，你們大概在想我要開始深入講 Nitro 的運作原理了，但今天早上我有更好的東西。
- 這是我大學時期最喜歡的教科書之一。
- 這是一本非常棒的書，它無疑是我們領域中幾位大師所撰寫的電腦科學經典之作。
- 這是我大學時期那本書的實物照片，我到現在還留著。
- 這是第二版，到現在已經有點過時了。
- 這個產業已經改變了很多。
- 事實上，這本教科書的第七版最近剛出版。
- 而這個版本實際上有一個章節介紹了 Nitro 系統。
- 這有多酷？
- 你現在可以在這本電腦科學教科書裡學到 Nitro 和 Graviton。
- 為了慶祝，我們今天早上要送出一些這本書。
- 我等一下會在螢幕上放一個 QR code。
- 如果你掃描它，就可以獲得一本。
- 現場前 1000 位可以把這本書帶回家，如果你夠幸運的話。
- 準備好了嗎？
- 開始。
- 好，如果你有幸搶到一本，keynote 結束後可以在 expo hall 領取。
- 但真的，即使你沒搶到，今天在座的每一位，包括線上的朋友們，都算賺到了，因為你們不用聽我上電腦科學課。
- 好的。
- Nitro 是我們過去 20 年來深度投資的絕佳範例。
- 它也是 AWS 開始自行打造晶片的原因，現在包括 Graviton，我們自製的 AWS 伺服器處理器，以及 Trainium，我們的 AI 晶片。
Graviton Processor Overview Graviton 處理器概述
- 所以今天早上開始，我們想跟你們多介紹一些 Graviton。
- 為此，請歡迎 Dave Brown 上台。
正如 Peter 剛才提到的，Nitro 改變了人們對雲端可能性的認知。
- 它證明了如果你能掌控矽晶片、硬體和系統架構，你就能獲得使用通用硬體根本無法達到的效能和效率提升。
- 隨著我們在 Nitro 系統中使用 ARM 的時間越來越長，一個自然而然的問題浮現了。
- 如果客製化晶片能如此顯著地改善網路和儲存，為什麼我們不能把同樣的做法應用到運算上？
- 所以我們退一步思考，如果我們專門為雲端工作負載設計一顆伺服器處理器，它會是什麼樣子？不是改裝的，不是挪用的，而是從零開始為雲端打造的。
- 這就是 Graviton 處理器的由來，一個全新的設計，目標是為客戶每天在雲端上跨產業運行的工作負載提供最佳性價比。
- 各家組織都在用 Graviton 獲得更好的效能和更低的成本。
- Adobe 減少了 37% 的碳排放。
- Epic Games 正在驅動大規模、低延遲的全球遊戲工作負載，而 Formula 1，我最喜歡的運動之一，模擬運算速度快了 40%。
- Pinterest 降低了 47% 的成本，SAP 的 SAP HANA Cloud 效能提升了 35%。
- 這些不是展示 demo。
- 這些是正式生產環境的系統，用 Graviton 跑得更快、更乾淨、更便宜。
- 我們在軟體合作夥伴那裡也看到同樣的熱情。
- 他們在調整編譯器、重寫執行環境、優化函式庫，並在各自的平台上建構對 Graviton 的原生支援。
- 他們之所以全力投入，是因為他們看到明確的效能優勢、成本優勢，以及一個強健的長期架構。
- 圍繞 Graviton 的產業協作持續成長和成熟。要在 EC2 中交付最佳性價比，需要在每一層都下功夫。
- 一切從在矽晶片中打造出色的效能開始，但也來自於我們如何建構和運營圍繞這些晶片的系統。
Direct-to-Silicon Cooling 直接矽晶散熱
- 因為我們同時設計處理器和伺服器，所以我們可以在整個堆疊上進行優化，這也包括客戶通常不會想到的一個環節：散熱。
- 這是大多數處理器使用的傳統散熱方式。
- 你有矽晶片，然後是散熱介面材料（TIM），然後是保護蓋，然後是更多的 TIM，然後是散熱片。
- 這種方式可靠且容易製造，幾十年來一直是業界標準設計。
- 但讓我們再深入一點，因為這裡的物理學很有趣。
- 散熱是很直接的物理學。
- 散熱路徑中的每一層都會減緩熱量移動，所以更多的阻力會導致更高的接面溫度，而更高的溫度會增加漏電流，更高的漏電流又會增加功耗。
- 這是一個效率損失會非常快速累積的領域。
- 傳統 CPU 使用這種設計，因為它們必須支援許多系統、許多外觀規格和許多散熱方案，而那個蓋子提供了一個穩定的介面。
- 但由於我們掌控了 Graviton 的整個系統，我們有機會用不同的方式來思考。
- 所以我們沒有遵循傳統模式，而是設計了一種直接矽晶散熱方案。
- 我們移除了蓋子和一層 TIM，這降低了阻力，讓熱量能更有效率地移動。
- 這需要精密製造和精心挑選的材料，但成果是顯著的。
- 我們的風扇功耗降低了 33%，而且記住，我們之所以能做到這一點，是因為我們掌控了整個堆疊。
- 現在，改善系統效率只是交付出色效能的一部分。
- 矽晶片本身必須一代比一代更好，而晶片開發既是迭代式的也是長期的。
- 每一代 Graviton 都擴展了我們能服務的工作負載範圍，而每當新的工作負載類型出現，我們就能了解下一組瓶頸在哪裡，這些學習直接回饋到下一代的設計中。
- 這是一個持續改善的循環。
Silicon Iteration & Cache Trade-offs 矽晶迭代與快取權衡
- 每一代 Graviton 處理器都建立在前一代的基礎上，持續推動架構向前發展。
- 去年我談到了針對真實世界應用效能來優化 Graviton，在 Graviton3 上，我們發現 L2 快取未命中（cache miss）對真實世界工作負載的效能有顯著影響。
- 快取是 CPU 效能最重要的預測指標之一。
- 所以它成為了我們的重點優化領域。
- 當一個核心需要資料時，它會先檢查快取。
- 快取容量小但速度極快，設計用來存放經常存取的資料。
- 當快取中找不到所需資料時，處理器就必須一路到主記憶體去取，而那慢得多。
- 現代 CPU 架構使用三層快取階層：L1、L2 和 L3。
- L1 最快，L2 更大但稍慢，L3 更大且由各核心共享。
- 如果三層快取都未命中，就必須去存取 DRAM，這可能要花上 100 奈秒。
- 以 CPU 週期來說，那是非常非常長的時間，這就是為什麼我們喜歡大快取。
- 你能把越多資料放在靠近核心的地方，就需要越少的慢速記憶體存取。
- 所以在 Graviton4 上，我們把每個核心的 L2 快取從 1MB 加倍到 2MB，這是 Graviton4 能比 Graviton3 提供高達 30% 更佳效能的貢獻因素之一。
- 正如你所預期的，加倍 L2 快取顯著減少了 L2 快取未命中，但設計 CPU 總是需要取捨，所以在 Graviton4 中我們同時也增加了 50% 的核心數，而 L3 快取只增加了大約 12%。
- 對於當時我們想要服務的垂直擴展工作負載來說，那是正確的平衡。
- 但更多核心共享相對較少增長的 L3 快取，使得每個核心分到的 L3 快取比以前更少。
- 這就是為什麼我們看到 L3 快取未命中增加了。
Coherent Links & Graviton5 同調連結與 Graviton5
- 這些就是你在設計矽晶片時不斷要評估的取捨。
- 而且，我們做了一個重大的架構變更，在兩顆 CPU 之間加入了同調連結（coherent link）。
- 這讓我們能為資料庫和大型分析工作負載提供高達 192 個 vCPU。
- 但連結處理器會引入新的延遲路徑。
- 當它需要存取另一顆 CPU 上的記憶體時，請求必須跨越那條互連，這會增加延遲、額外的協定開銷，有時甚至還有排隊等待。
- 在某些情境下，這可能要花上三倍的時間。
- 所以我們問自己，是否能在單一封裝中提供 192 個核心，同時擁有對記憶體的統一快速存取和更多快取。
- 今天我們很興奮地介紹 Graviton5。
- Graviton5 在單一封裝中提供 192 個核心，並且提供超過前幾代五倍的 L3 快取。
- 這意味著每個核心現在可以獲得高達 2.6 倍的 L3 快取，帶來更好的整體效能和更好的一致性。
Graviton5 Highlights Graviton5 亮點
- 這一切都體現在我們預覽的 M9g 執行個體上，由 Graviton5 驅動。
- M9g 比 M8g 提供高達 25% 的效能提升，並提供目前 EC2 中最佳的性價比。
- 我們已經從一些早期客戶那裡看到了令人驚艷的成果。
- Airbnb 看到了高達 25% 的效能提升。
- Atlassian 看到了 20% 的延遲降低。
- Honeycomb.io 看到了每核心 36% 的效能提升，而 SAP 在其 SAP HANA Cloud 的 OLTP 查詢上看到了驚人的 60% 效能提升。
- 這些是顯著的真實世界改善，代表了重大的世代進步。
Apple Infrastructure Overview Apple 基礎設施概述
- 現在我想邀請一位在塑造開發者如何在 AWS 上建構方面有重大影響力的嘉賓上台。
- 請和我一起歡迎 Apple 雲端系統與平台副總裁 Payam Mirrashidi。
謝謝，Dave。
- 嗨，我是 Apple 的 Payam Mirrashidi。
- 我們的動力來自於一個信念：我們打造的產品和服務應該幫助人們釋放他們的創造力和潛能。
- 我們建構了地球上規模最大的一些網路服務，其中許多都跑在 AWS 上。
- 我的團隊負責 App Store、Apple Music、Apple TV 和 Podcasts 等服務。
- 這些是數十億人每天都在使用的服務，也就是我喜歡稱為好玩的東西。
- 我們也建構了橫跨 AWS 和我們自己資料中心的底層雲端基礎設施。
- 讓這一切成為可能。
- 哇。
- 一張投影片上就有這麼多科技力量，而且不只是你在 F1 電影裡看到的那種，而是為全球數十億用戶驅動體驗的那種。
- 這就是為什麼我們一直在尋找方法來優化我們開發和交付服務的方式。
- 你們很多人正在一個混合的世界中摸索，平衡自己的基礎設施和 AWS 的力量。
- 讓我告訴你，在 Apple，我們完全理解。
- 我們面臨著跟你們一樣的壓力和挑戰。
- 我們是一個大規模的營運。
- 我們在處理同樣的問題：可擴展性、效能和可靠性。
- 而我們正在用 AWS 來解決這些問題。
- 跟你們很多人一樣，我的開發者旅程是從用 C 語言寫程式開始的，然後在 2002 年，我以工程師身份加入 Apple，參與了最初的 iTunes Store，那時候是一個 Java 開發團隊。
- 我們是一個有著大夢想的小團隊，必須改變全世界消費音樂的方式。
- 這些年來，我們大部分都堅持用 Java，當需要更高效能時，就用 C++。
- 但開發起來嘛，很繁瑣，在正式環境中大規模支援更是困難。
- 隨著我們的服務擴展，我們也面臨了新的程式開發挑戰。
- 我們手上的工具不一定總是能勝任。
- 大約在同一時間，Apple 自己的作業系統團隊正在開發 Swift，最初是作為在 iPhone 和 Mac 上開發你們熟悉和喜愛的應用程式的首選語言。
Swift Adoption & Performance Gains Swift 採用與效能提升
- Swift 的效能、現代設計和內建的安全特性揭示了它在伺服器端開發的潛力。
- 我知道引入一個新語言，尤其是在伺服器端，可能會讓人存疑，但用 Swift，一個開發者通常就能同時處理客戶端和伺服器端。
- 你可以把客戶端邏輯包成函式庫，在伺服器端執行，維護單一程式碼庫。
- 在客戶端和伺服器端擁有相同邏輯的威力是巨大的，我想你們也會發現這對你們的團隊非常有價值。
- 今天。
- Apple 用 Swift 來驅動從 Apple Silicon 一路到螢幕上渲染的每個像素的所有東西。
- 它易於學習，從嵌入式系統到大型架構都能優美地擴展，非常適合建構分散式服務或複雜的系統軟體。
- Apple 每天用直接跑在 AWS Graviton 上以 Swift 建構的應用程式處理數十億筆請求。
- 透過用 Swift 改寫核心服務並將工作負載遷移到 Graviton，我們看到了 40% 的效能提升和 30% 的成本降低。
- 從 x86 的轉換非常順暢，歸功於 Graviton，幾乎可以直接替換 Java。
- Apple 十多年前就遷移到 ARM 來驅動我們的裝置，現在我們在遷移到基於 ARM 的 Graviton 時也看到了同樣的價值。
- 為了從基礎設施中獲得更多，更高的吞吐量意味著更少的執行個體、更低的成本和更小的佔用空間。
- 對我們的客戶和對地球都是雙贏。
- 一個很好的例子是我們在 iOS 26 中的垃圾訊息偵測功能。
- 我們使用跑在 Graviton 上的 Swift 來擴展這項服務背後的運算密集操作，幫助我們偵測可疑電話號碼，同時為數億用戶維護隱私。
- 事實上，跑在你手機上的訊息 app 和跑在伺服器上的垃圾訊息偵測功能用的是同一個語言，無縫地擴展。
- 這個功能使用同態加密（homomorphic encryption）建構，使用了一個我們開源的 Swift 函式庫，能在伺服器完全不解密資料的情況下進行私密且安全的運算。
- 這讓我們能處理大量資料，以驚人的速度保護數十億用戶。
- 在氛圍式程式開發（vibe coding）和 AI 開發的時代。
- 我們選擇的語言至關重要，它的可讀性和安全性讓它成為你 AI 工具箱中的絕佳選擇。
- 這個月正好是我們開源 Swift 的十週年，我們把這個令人驚艷的語言分享給了全世界，回響非常熱烈。
- 今天 Swift 可以在 Linux、Windows、Android 等平台上使用。
- 它被一個充滿活力的社群所擁抱，全球數百萬開發者正在用它建構從裝置到資料中心的各種應用。
- 是時候考慮在你的下一個專案中使用 Swift 了。
- 到 Swift.org 看看這個快速、富有表達力且安全的語言。
- 跑在 AWS 和 Graviton 的新一代基礎設施上。
- 如果你還沒聽說的話，現在有了原生的 Swift 工具鏈可以在 Amazon Linux 上使用，這是第一個由 AWS 和 Swift on Server 社群提供官方套件的發行版。
- 感謝你們的願景和合作關係。
- 我也想感謝 Dave 今天邀請我來。
- 我們迫不及待想看到你們用 Swift 在 AWS Graviton 上創造出什麼。
3️⃣ Serverless Expansion 無伺服器擴展
From S3 to Lambda Concept 從 S3 到 Lambda 概念
- 謝謝。
也謝謝你，Payam。
- 你和 Apple 團隊在 Graviton 上使用 Swift 所做的工作真的非常非常令人印象深刻。
- 雲端帶來的最大轉變之一，就是企業能夠多快地行動。
- 開發者不再等待硬體，而是能在幾分鐘甚至幾秒鐘內啟動資源。
- 那種速度，能夠實驗、迭代、快速失敗並希望快速成功的能力，現在是不可或缺的。
- 在過去 20 年裡，我們做的不只是給你更快的電腦。
- 我們給了客戶更快的建構元件和工具，移除了那些無差異化的繁重工作，讓你可以把工作負載、時間和精力集中在真正能讓你的業務與眾不同的地方。
- 我想帶大家回到 2013 年，那個時刻，AWS 內部一個非常小的工程師團隊問了一個在當時聽起來幾乎不可能的問題。
- 如果開發者只需要把程式碼交給 AWS 然後它就執行了呢？
- 不需要伺服器，不需要配置，不需要容量規劃，不需要擴展？
- 而且想出這個點子的工程師，他們甚至不在 EC2 團隊裡，因為 EC2 團隊，包括我自己，當時完全專注在伺服器、執行個體類型、Auto Scaling 群組、負載平衡器上，當然還有把抖動趕到它該待的地方。
- 當你專注在伺服器上時，你不會自然而然地問出：「如果根本不需要伺服器呢？」這個問題。
- 但那就是突破點。
- 重點不是讓伺服器更簡單，而是把伺服器從體驗中完全移除。
- 你看，當時 S3 團隊在處理數百萬的縮圖、大頭照、產品照片、社群媒體圖片，全部湧入整個 S3 機群的儲存桶中。
- 每當一張新圖片到達，就有大量的工作要做。
- 它需要被調整大小、裁剪、加浮水印。
- 任何應用程式需要的處理。
- 為了做到這些，客戶必須跑一整個 EC2 執行個體機群，他們要從 S3 拉出圖片、處理它，然後把結果推回去。
Lambda Launch & Early Impact Lambda 發布與早期影響
- 那些伺服器、擴展邏輯、編排，全部都由客戶管理，而這是每次 S3 中有新物件到達時就會觸發的大量無差異化繁重工作。
- S3 團隊有一個優雅的洞察。
- 如果他們把一小段運算直接附加到儲存層，就能在新物件落地的那一刻執行一個小函式。
- 不需要機群，不需要搬移資料，不需要編排。
- 上傳一張圖片。
- 運算執行。
- 縮圖出現。
- 那個簡單的想法，把運算帶到資料旁邊，成為了某個更大東西的種子。
- 隨著概念演進，我們意識到這不只是關於那些縮圖。
- 這是一種全新的應用程式模型。
- 客戶不只想在新圖片到達時執行邏輯。
- 他們想要回應資料庫事件、日誌系統、IoT 訊息、API 呼叫，任何系統可能產生的事件。
- 當我們在 2014 年推出 Lambda 時，它改變了整個局面。第一次，開發者不是從伺服器開始。
- 他們從程式碼開始。
- Lambda 處理執行、擴展、可用性和機群。
- 你只在程式碼執行時才付費。
- Lambda 不只是一個新服務，它是一種新的思維模式。
- 客戶立刻擁抱了它，新創公司動得更快了。
- 企業把卡住多年的工作負載現代化了。
Lambda Managed Instances
- 事件驅動架構、即時處理、資料管線，全新的模式紛紛出現。
- 十年後的今天，Lambda 仍然是從想法到正式環境最快的方式。
- 客戶喜歡它，因為它移除了大量的營運負擔。
- 當然，隨著使用量增長，人們把 Lambda 推向了新的領域。
- 所以我們持續擴展它。
- 更多執行環境、容器支援、VPC 網路、可預測的效能選項、SnapStart 和 Function URL，全部都沒有增加任何營運負擔。
- 但隨著使用量進一步增長，客戶繼續把 Lambda 推向新的領域，他們想要存取最新的 EC2 技術。
- 他們想要在非常非常大的規模下有可預測的效能。
- 他們想要更多的網路吞吐量。
- 他們想要亞毫秒的延遲，而且他們不想為了得到這些東西而犧牲 Lambda 的任何簡潔性。
- 這形成了一個轉折點。
- 大約兩年前，我們第一次把 Lambda 和 EC2 團隊整合到同一個組織下。
- 當我們這樣做之後，這兩個團隊，一個根植於伺服器，一個根植於無伺服器，開始一起審視整個運算領域。
- 我們開始把運算不再視為僵化的框框，EC2、容器和無伺服器，而是一個選擇的光譜。
- 這自然引導我們到一個更深層的問題：什麼是無伺服器？
- 是沒有伺服器？
- 是沒有維運？
- 是不要讓我去想基礎設施？
- 是只要執行我的程式碼？
- 客戶清楚地告訴我們：我們喜歡 Lambda 因為不用管理基礎設施，但我們想要掌控效能。
- 而且我們確實想要存取我們所需要的硬體。
- 所以我們問自己另一個大膽的問題。
- 我們能不能保留客戶喜愛無伺服器的一切？
- 無伺服器的。
- 簡潔性、自動擴展、營運模式，同時給他們 EC2 的效能選擇？
- 而這週，我們很高興用 Lambda Managed Instances 來回答這個問題。
- Lambda Managed Instances 優雅地彌合了無伺服器的簡潔性和基礎設施掌控之間的差距。
- 使用 Managed Instances，你的 Lambda 函式跑在你帳戶內的 EC2 執行個體上，而 Lambda 管理配置、修補、可用性和擴展。
- 你選擇執行個體類型，你選擇硬體。
- Lambda 處理其餘的一切。
- 這是無伺服器運算的下一步演進。
- 而最棒的部分？
- 你現有的 Lambda 函式繼續照常運作。
- 不需要重新架構，不需要改程式碼，不增加營運負擔。
- 你獲得 EC2 的效能特性，搭配 Lambda 的開發者體驗。
- 我們認為這為過去一直在 Lambda 之外的工作負載打開了大門。
- 影片處理、ML 前處理、高吞吐量分析。
- 我相信還有很多很多。
- Lambda Managed Instances 不是背離無伺服器，而是無伺服器的擴展。
- 它為客戶帶來更多選擇、更多效能、更多能力，而不增加任何營運負擔。
- 你看，無伺服器從來就不是指沒有伺服器。
- 它一直都是指沒有伺服器管理。
- 它是關於移除繁重工作，讓開發者能完全專注在他們的程式碼和業務邏輯上。
- 而有了 Managed Instances，我們正在推動這個願景向前，給建構者 EC2 的力量和 Lambda 的簡潔性，讓他們比以往任何時候都動得更快。
4️⃣ Inference & Bedrock Architecture 推論與 Bedrock 架構
Inference Pipeline & Project Mantle 推論管線與 Project Mantle
- 過去一年，我們看到客戶運行的工作負載類型出現了重大轉變。
- 推論（Inference）顯然已經成為核心，而它的行為模式與我們過去二十多年來一直在優化的傳統運算模式截然不同。
- 當我們深入研究這些工作負載時，很明顯地發現，客戶在雲端仰賴的彈性並不會自動延伸到推論上。
- 因此我們一直在思考，如何在推論領域也提供客戶期待從 AWS 獲得的同等靈活性、回應速度和效率。
- 即使在需求可能瞬間暴增、而出錯代價極其高昂的世界裡。
- 要理解為什麼推論是如此困難的問題，你必須看看單一推論請求內部到底發生了什麼。
- 這不只是文字進、文字出那麼簡單。
- 它是一個四階段的管線。
- 分詞（Tokenization）、預填充（Prefill）、解碼（Decode）、反分詞（Detokenization）。
- 每個階段對系統造成的壓力都不一樣。
- 分詞將輸入拆解成模型能理解的 token。
- 預填充處理完整的提示詞，並建立模型在解碼階段會用到的鍵值快取（Key-Value Cache）。
- 解碼階段依據那個鍵值快取，一次生成一個 token 的回應，然後反分詞將這些 token 轉回我們能理解的語言。
- 在任何時刻，你同時運行的工作負載可能是 CPU 密集型、GPU 運算密集型、記憶體頻寬密集型，而且還對延遲高度敏感。
- 有些請求很小。
- 有些則涉及龐大的文件。
- 有些必須立即回傳，有些則可以慢慢來，而且單一請求的資源需求在通過這條管線的過程中會劇烈變化。
- 現在想像在全球規模下做這些事。
- 數千個客戶、數百萬個請求、數十種模型，每種模型有不同的形狀、大小和緊急程度。
- 這是一個完全不同的擴展挑戰。
- 要做好這件事，你需要一個能即時適應的架構。
- 如果你從零開始建構一個推論服務，你可能會從我們都熟悉的架構開始：一個負載均衡器加上一組加速器叢集。
- 這個模式對很多應用都運作得很好。
- 對傳統網路服務來說，這是一個經過驗證且有效的模式。
- 當我們建構 Bedrock 時，我們也從這些經過驗證的模式開始。
- 它們確實服務得很好。
- 但隨著模型演進和使用量成長，很明顯推論需要一個不同的架構。
- 所以我們回歸基本面，問自己：如果我們今天要設計一個推論服務，帶著我們現在從大規模運行真實客戶工作負載中學到的一切，它會是什麼樣子？
- 這就是 Project Mantle 的由來，一個新的推論引擎，現在驅動著許多 Amazon Bedrock 模型。
- 最大的洞察之一是，並非所有推論請求都有相同的緊急程度。
- 所以與其讓 AWS 來猜測，我們希望讓客戶告訴我們。
- 因此我們推出了 Bedrock 服務層級（Service Tiers），讓客戶將請求分配到三個通道之一：優先級（Priority），用於即時、對延遲敏感的互動；標準級（Standard），用於穩定且可預測的工作負載；彈性級（Flexible），用於效率比速度更重要的背景作業。
- 這讓客戶可以針對自己在意的面向做最佳化，也讓我們能更智慧地分配資源。
- 結果就是優先級工作負載能獲得一致的低延遲，同時其他所有工作負載也能維持最佳化的效能。
Fairness & Fault Tolerance 公平性與容錯
- 我們用 Mantle 解決的第二個重大挑戰是公平性。
- 在共享系統中，一個客戶的突發流量不應該降低其他客戶的效能。
- Bedrock 透過給每個客戶獨立的佇列來解決這個問題。
- 你的效能取決於你自己的使用量，而不是別人的。
- 如果另一個客戶突然暴增，影響的是他們的佇列，不是你的。
- 而且因為 Bedrock 會學習你的典型使用模式，它會預測你可能需要多少容量，並確保在你需要時就已經準備好了。
- 佇列隔離加上自適應容量共享的組合，讓客戶即使在高負載下也能獲得更可預測的效能。
- 當你把這些全部組合起來：優先級排序、公平性、更智慧的批次處理、更好的排程，你會得到顯著的提升。
- 延遲變得更一致，吞吐量增加，使用率提高，整體系統變得更有韌性。
- 但要讓這個架構完全可靠，特別是對於長時間運行的請求，我們還需要一個組件：一個記錄整個叢集上正在進行工作的持久化紀錄。
- 我們稱之為 Journal。
- Journal 目前已經驅動著 DynamoDB 和 S3 等服務。
- 它是一個高度可靠且持久的交易日誌。
- 推論請求可能運行很長時間，如果出了問題，無論是硬體故障、網路問題，或只是一次重試，你都不想從頭重新開始整個請求，那會浪費運算資源並增加延遲。
- 有了 Journal，Bedrock 會持續擷取每個請求的狀態。
- 如果出了什麼問題，你可以從中斷的地方精確恢復。
- 這讓系統的容錯能力大幅提升。
- 它也實現了以前不可能的進階排程策略。
- 其中一個進階排程策略就是微調（Fine-Tuning）。
- 微調是超級運算密集的，可能需要好幾個小時。
- 傳統系統需要獨立的訓練環境、獨立的排程器，而這些通常閒置著等待負載。
- 在 Bedrock 中，微調變成只是一個長時間運行的作業。如果即時流量突然湧入，微調作業就暫停。
- 當流量消退，它就從中斷的地方恢復。
- 這讓客戶可以直接在 Bedrock 內使用極其高效的微調，不需要管理訓練叢集，也不用擔心浪費運算資源。
Confidential Computing & AWS Integration 機密運算與 AWS 整合
- 在重新設計推論引擎的同時，我們也提高了安全性和隱私的標準。
- 就像 Nitro 透過建立安全、隔離的運算環境來改變 EC2 一樣，Bedrock 整合了機密運算（Confidential Computing）來保護推論過程中的模型權重和客戶資料。
- 資料始終是加密的，營運人員無法存取環境，客戶可以獲得密碼學上的保證，確認他們的請求是在經過驗證且可信賴的環境中運行的。
- 對於有嚴格隱私和合規需求的組織來說，這是一個巨大的進步。
- 因為我們有一個強健、一致、可靠的基礎，我們可以將它與 AWS 的其他服務深度整合。
- 我們新增了工具呼叫（Tool Calling）支援，讓你的模型可以直接從 Bedrock 呼叫 Lambda 函數來取得即時資料。
- 我們新增了對 OpenAI 的 Responses API 的支援，用於長時間運行的作業，並且整合了 IAM 做權限管理和 CloudWatch 做可觀測性。
- 這些都是企業運行最重要工作負載所依賴的東西。
- 這不只是模型託管。
- 這是一個全託管、可用於正式環境的生成式 AI 平台，我們在 Bedrock 中建構的一切都反映了我們近二十年來大規模營運服務所學到的經驗。
- 推論是一種新型態的運算。
- 它有自己的擴展模式、自己的限制條件、自己的需求。
- 而 Bedrock 為我們和你們客戶提供了可靠、高效且安全地運行這些工作負載的基礎。
- 在每一個 API 背後，都有一個精密的引擎在處理排程、公平性、韌性和效能，讓客戶可以專注在建構上。
- 這就是我們在 AWS 做的事。
- 我們承擔困難的問題，解決它們，然後給客戶他們需要的工具去創造未來。
5️⃣ Vector Search & S3 Vectors 向量搜尋與 S3 Vectors
Vector Search Across AWS Services 跨 AWS 服務的向量搜尋
- 接下來，讓我把舞台交回給 Peter。
好的。
- 謝謝 Dave。
- 我知道 Dave 已經談過加速創新了，但我們就是喜歡創新。
- 所以我要再多聊一些。
- 我們加速創新的方式之一，就是讓你在我們廣泛的服務中都能使用重要的新功能。
- 我認為一個很好的例子就是我們在整個 AWS 啟用向量搜尋（Vector Search）方面所做的工作。
- 這是 Smokey 的照片，或者說 SmugMug，他喜歡被這樣叫。
- 你可以看到這不只是 Smokey 的照片，當我們看著它時，我們不只看到像素，我們看到了外觀特徵。
- 蝙蝠耳、大舌頭。
- 我們也看到了那個表情，彷彿在說：我知道我做了什麼，我不在乎。
- 你的大腦同時處理所有這些概念和想法，理解它們之間的關係，然後將它們連結到其他事物。
- 也許你在想你的狗，或者也許你在想昨晚晚餐時坐在你旁邊那個吃得很狼狽的人。
- 這些關聯有時候很強烈且明顯，有時候很微妙。
- 這就是人類做的事。
- 而向量讓電腦可以用同樣的方式運作。
- 理解向量最簡單的方式是，它是一個將資料放置在數學空間中的點。
- 在我們這個人造的範例中，我有三個維度。
- 一個代表顏色，另一個代表大小，還有一個代表形狀。
- 你可以看到，現在你可以把圖片或想法放在這三個軸上。
- 每個東西被放在哪個確切位置其實不是最有趣的。
- 有趣的是一個向量相對於其他向量的位置。
- 非常不同的物件，比如聖誕裝飾品和蘋果，或是網球和萊姆，可能會靠在一起。
- 而這些關聯正是向量搜尋中有趣的地方。
- 當然，我們這裡的例子不會揭示什麼特別有趣的東西，因為這是一個非常簡單的人造範例。
- 在真實世界中，向量遠不止三個維度。
- 事實上，今天一個豐富的向量編碼空間可能有 3000 個維度。
- 你可以看到我們很難在這裡把它畫出來。
- 而且每個維度不是像大小或顏色這麼簡單的東西。
- 它實際上是一個完全未定義的概念，本身是由 AI 生成的，一種叫做嵌入模型（Embedding Model）的特殊 AI。
- 你用大量的資料來訓練一個嵌入模型，模型本身會開始識別模式。
- 它學習不同類型的狗耳朵和不同的形狀。
- 有了足夠的資料，它學會在那個數學空間中將這些物件聚集在一起。
- 有時候是顯而易見的方式，有時候則令人驚訝。
- 所以，舉例來說，你可能在想，那我們拿這些向量做什麼？
- 嗯，如我所說，向量最有趣的地方就是當你在資料庫中搜尋它們的時候。
- 這就是為什麼，不像傳統資料庫只是儲存行和列，向量資料庫是專門為了找到與這些向量最近的匹配而建構的。
- 你對查詢進行編碼，然後它在資料庫中找到其他接近的向量物件。
- 所以在我們的範例中，所有法國鬥牛犬可能聚集在一個地方，所有其他狗可能聚集在附近。
- 還有貓。
- 我不確定貓聚集在哪裡。
- 誰在乎呢？
- 但也許那些喜歡破壞玩具的貓就在法國鬥牛犬旁邊。
- 好，讓我們看看向量在真實世界中能做什麼。
- 想想你的公司現在擁有的所有資料。
- 你的組織知識並沒有被整理成可以插入資料庫的行和列。
- 它埋藏在 PDF 裡。
- 它被擷取和記錄在視訊會議中。
- 也許有些人拍了白板的照片寫了下來。
- 它散落在數十個系統的文件中。
- 挑戰可能不是你沒有你需要的資料。
- 問題是你找不到你需要的資料。
- 現在你可能在想，建立一個向量資料庫可能是找到那些資料的好方法。
- 這是對的。
- 但不幸的是有一個挑戰。
- 現有的嵌入模型高度專門化，只能處理特定類型的資料，比如圖片或文字。
- 所以如果你想從你可能擁有的大量非結構化資料中獲益，這意味著你可能需要組合多個模型。
- 但問題是你其實無法組合模型，因為你無法跨不同嵌入模型搜尋向量，因為我們談到的那些抽象維度可能持有完全不同的概念。
- 這正是我們用新的 Nova Multimodal Embeddings 模型要解決的挑戰。
- 這是一個最先進的嵌入模型，支援文字、文件、圖片、影片和音訊。
- 它將所有這些概念轉換到一個共享的向量空間，建立對你資料的統一理解。
- 更好的是，Nova Multimodal Embeddings 模型以業界領先的精確度做到這一切。
- 但擁有一個出色的嵌入模型只是我們幫助你在資料上使用向量搜尋的一部分。
- 真正的魔法發生在向量搜尋功能能夠在你所有資料所在的地方使用的時候。
- 想想你的團隊今天是怎麼工作的，他們已經深度投入在特定的資料庫和分析平台上。
- 當向量功能直接內建到這些服務中時，會有幾個好處。
- 首先，他們不需要花時間和精力去學習一個全新的向量資料庫。
- 你也不需要為全新的東西付費。
- 所以你得到了敏捷性和成本節省。
- 這就是為什麼在 AWS，我們處理向量的方式和我們處理所有事情的方式一樣：兼具廣度和深度。
- 你不需要學習一個全新的技術堆疊或管理複雜的資料管線。
- 我們已經在我們的服務中整合了向量功能。
- 讓我們來看看 OpenSearch。
- Amazon OpenSearch 長期以來一直是搜尋和分析的骨幹，它以精確匹配功能聞名。
- 但你不再只是需要精確匹配功能了。
- 你想用自然語言提問並獲得智慧的回應。
- 但這不代表你想放棄精確匹配搜尋的能力。
- 所以今天，OpenSearch 已經演進成一個向量驅動的智慧引擎。
- 有了 OpenSearch，你不必在傳統關鍵字搜尋和語意搜尋之間做選擇。
- 混合搜尋（Hybrid Search）給你關鍵字的精確度，而語意搜尋讓你得到更好的結果。
- 你可能覺得 OpenSearch 是我們新增向量功能相當理所當然的地方，我同意。
- 事實上，我們已經在大部分的資料庫和分析服務中新增了向量搜尋功能。
- 但我們也問了一個問題：如果我們把向量搜尋的力量帶到我們最大的資料服務上，會意味著什麼？
- 透過 S3 Vectors，我們將 S3 的成本、結構和規模帶到了向量儲存。
- 這確實讓一些人感到驚訝，即使是那些對向量很熟悉的人，因為這並不容易。
- 很棒的是，你可以用建立 S3 儲存桶（Bucket）完全相同的方式建立向量索引，這讓你能建構任何大小的向量資料庫。
- 擁有在 S3 中儲存資料的簡單性，不需要預先配置，任何規模都能運作。
- 你只需為實際使用的部分付費。
- 就是這麼簡單。
- 本週稍早，Matt 宣布了 S3 Vectors 的正式發布（GA），其中包含了查詢效能和規模方面的重大改進。
- 事實證明，在大規模向量資料庫的高維空間中搜尋最接近的向量是非常困難的。
- 要找到最近鄰居，精確的最近鄰居。
- 你基本上必須將資料庫中的每一個向量與搜尋向量進行比較，這需要在所有維度上進行大量數學運算。
- 即使在較小的資料庫中，所有東西都保存在記憶體裡，這通常也太昂貴了。
- 所以你通常會採用一種叫做近似最近鄰演算法（Approximate Nearest Neighbor Algorithm）的方法。
- 目前這些演算法有很多創新。
- 它們非常有趣。
- 它們不保證找到絕對最接近的向量，但表現相當好。
- 而且擴展性好得多。
- 但我們在 S3 面臨的挑戰是，我們並沒有把所有這些向量儲存在記憶體中。
- 我們用 S3 更經濟的儲存方式來存放它們。
- 那麼，我們如何在向量資料庫增長到數十億個向量且需要在 S3 上運行的情況下，提供真正低延遲的搜尋呢？
- S3 團隊開發的方法是為每個向量資料庫預先計算一批向量鄰域（Vector Neighborhoods）。
- 理解向量鄰域的好方法是把它想成一群向量聚集的地方，也許是法國鬥牛犬，或是會破壞玩具的貓，這些鄰域是提前離線計算的，所以不會影響你的查詢效能。
- 每當一個新的向量被插入 S3，這個向量就會根據它的位置被加入一個或多個向量鄰域。
- 當使用者要執行查詢時，會先做一個小很多的搜尋來找到附近的鄰域。
- 然後只有這些向量鄰域中的向量會從 S3 載入到快速記憶體中，團隊接著套用近似最近鄰演算法，這一切都可以很快完成，而且回傳非常好的結果。
- 這效果如何呢？
- 結果非常好。
- 我們在正式環境中，對擁有 20 億個向量的向量資料庫看到了低於 100 毫秒的查詢時間。
S3 Vectors Adoption Metrics S3 Vectors 採用指標
- 這就是 S3 Vectors 的規模和效能。
- 它將為客戶開啟各種新的使用案例。
- 對 S3 Vectors 的回響非常好，在我們放出預覽版的短短四個月內。
- 已經建立了超過 250,000 個向量索引，我們已經匯入超過 40 億個向量，並執行了超過 10 億次向量搜尋。
- 這樣的採用速度告訴我們，我們正在解決一個真正的客戶問題。
TwelveLabs Video Intelligence TwelveLabs 影片智慧
- 其中一個早期客戶正在使用 S3 Vectors 來像人類一樣理解影片。
- 請歡迎 TwelveLabs 的執行長暨共同創辦人 Jae Lee 上台。
謝謝邀請，Peter。
- 我非常興奮能在這裡。
- 太興奮了。
- 事實上，我想看完 Peter 過去所有的 keynote 來做準備。
- 但老實說，我一直忙著經營 TwelveLabs，需要幫忙。
- 所以我決定讓我們的模型替我看那些 keynote。
- 我索引了過去八年超過 12 小時的 keynote，請我們的模型分析它們，挑出關鍵洞察來進一步了解。
- 首先我問，Peter 最喜歡談什麼主題？
- 非常感謝，我很快就知道了這些是他的最愛。
- 然後我搜尋 Peter 談論這些主題的片段，我很容易就能從他的每場 keynote 中找到並觀看特定的片段。
- 原本只是一種有趣的研究方式，但其實完美展示了 TwelveLabs 每天在做的事：將數小時的影片轉化為結構化的智慧。
- 我們生活在一個大約 90% 的資料都是非結構化的世界，其中絕大部分來自影片。
- 但即使影片是最大的資料來源，它也是極其複雜的。
- 它結合了視覺、音訊、動態，最重要的是時間。
- 現在，把這些放到媒體、娛樂、執法以及各種企業中 PB 級的影片素材來看。
- 那是數百萬小時的影片。
- 你知道一百萬小時的影片相當於 114 年嗎？
- 如果你一直看下去，這個規模是絕對驚人的，而從中找到意義、找到重要的時刻就更難了。
- 在 TwelveLabs，我們正在建構能像人類一樣理解影片的基礎模型，不是把它當成一系列畫面或逐字稿，而是當成一個跨越視覺、聲音和時間的統一故事。
- 我們的模型 Marengo 和 Pegasus 是全球最大規模的多 PB 級影片 AI 工作負載之一，對數百萬小時的影片進行推論。
- Marengo 是我們的多模態嵌入模型，驅動精確的影片搜尋和檢索。
- 我們最新版本 Marengo 3 讓你能在龐大的檔案庫中找到重要的時刻，使用任意模態對任意模態的搜尋。
- Pegasus 是我們的影片語言模型，將影片轉化為洞察。
- 它進行深度分析，擅長生成文字，如摘要、字幕或後設資料，來驅動下游的影片工作流程。
- 我們喜歡說 TwelveLabs 是在 AWS 上誕生的。
- 從一開始，AWS 新創計畫和額度就從根本上改變了我們的發展軌跡。
- 那些額度不只幫助我們訓練模型，更給了我們將研究產品化的動力，在 AWS 上運行我們的技術堆疊縮短了我們從創新到部署的距離。
- 我們資料基礎設施的骨幹就在 Amazon S3 上。
- 當客戶向 TwelveLabs 平台上的某個模型 API 發送請求時，系統無縫地在 PB 級規模下匯入、索引和嵌入影片，而且資料從不離開 S3。
- 我們的模型能力有多強，就需要同樣強大的向量儲存。
- 為我們的 Marengo 模型解鎖創新的，正是整合 Amazon S3 Vectors 來大規模提供最佳化的影片智慧服務。
- 向量是我們工作的核心。
- 每個場景、音訊片段、文字和影片都被 Marengo 編碼成一個多維向量嵌入，捕捉跨越空間和時間的語意意義。
- 那具體是什麼樣子呢？
- 假設一個音訊影片就是數千個向量，但我們談的是客戶處理數百萬小時的影片。
- 那就是數十億個嵌入。
- 這些嵌入直接流入 S3 向量索引。
- 不需要資料搬遷，不需要重新架構基礎設施。
- 原本就在儲存源影片的同一個 S3 儲存桶，現在也儲存了讓影片可搜尋的嵌入，擁有同樣的持久性和可擴展性保證。
- 舉例來說，當使用者輸入一個自然語言查詢，比如「人們從遠處觀看太空梭發射」，這個查詢會被 Marengo 嵌入到同一個向量空間。
- S3 Vectors 接著在數十億個已儲存的嵌入中執行近似最近鄰搜尋，回傳包含後設資料的影片結果，像是影片 ID 和時間戳記，精確定位到匹配查詢的那個時刻。
- 從這裡開始，我們的客戶可以取用這些影片結果，用來驅動下游的影片工具和工作流程。
- 我們的客戶之一 ArcXP 就是一個完美的例子，它是華盛頓郵報（Washington Post）的延伸。
- 他們提供媒體管理平台，驅動全球各地的新聞組織。
- 建構在 S3 之上，ArcXP 讓編輯團隊不只能儲存和管理龐大的檔案庫，現在他們還能用這些內容來個人化他們創造的故事。
- 一個單一的影片或文章可以被轉化為針對不同受眾量身打造的多種版本。
- 他們利用 TwelveLabs 模型快速分析和豐富已存檔的影片內容，並發現相關片段來建構新的故事。
- 這就是無障礙對我們的意義，不只是 API，而是在 AWS 上的基礎設施，讓影片智慧在任何規模下都可行。
- 我們與 S3 的合作讓我們能直接在客戶的基礎設施上提供極其高效的產品服務。
- 考慮到我們處理的資料規模，這對我們客戶的單位經濟效益產生了有意義的影響，從而解鎖了新的可能性。
- 我一開始告訴你們，我用我們自己的模型來準備這次 keynote。
- 那不只是一個展示技巧。
- 數十年來，影片一直是一種只寫不讀的媒體，我們錄下一切。
- 每場比賽、每次會議、每個時刻。
- 但我們找不到它、無法從中學習、也無法在它之上建構。
- 今天，這一切改變了。
- 我們正在將全世界的影片轉化為真正可用的知識。
- 每個組織都有自己版本的「Peter 的 keynote」，那些被困在影片素材中的組織知識，如果你能問它一個問題，它可以教會你一些東西。
- 而現在你可以了。
- 我們迫不及待想看到你們用它建構出什麼。
- 謝謝。
謝謝 Jae。
- 看那些老影片真有趣。
- 好。
6️⃣ Trainium3 & AI Acceleration Trainium3 與 AI 加速
Trainium Overview & UltraServer Trainium 概述與 UltraServer
- 稍早，Dave 介紹了我們在 Graviton 方面降低成本和提升效能的工作。
- 而沒有什麼地方比支援 AI 工作負載讓我們投入更多基礎設施投資了，原因很容易理解。
- AI 工作負載正在爆炸性成長，而運行這些工作負載是昂貴的、耗電的，而且容量受限。
- 這就是我們建構 Trainium 的原因。
- Trainium 支援幾乎所有你能想像的 AI 工作負載。
- 我們的命名慣例不太理想，但如你所聽到的，Trainium 同時針對訓練和推論進行了最佳化。
- 如果你正在使用 Anthropic 的模型，無論是透過 Bedrock 還是他們的第一方服務，你很可能已經在受益於 Trainium 了。
- Trainium 支援完整的模型架構光譜，從密集型 Transformer 到混合專家模型（Mixture of Experts）再到狀態空間模型（State Space Models），它支援各種模態：文字、圖片、影片，你說得出來的都行。
- 簡單說，Trainium 能處理你今天想運行的每一個 AI 工作負載，以及任何你能想像得到要建構的東西。
- 而 Trainium 以出色的效能支援所有這些工作負載。
- 效能可以意味著很多事情。
- 它可以意味著建構最大的訓練叢集，像是 Project Rainier，或者它可以意味著處理一個推論請求，並以最快的速度、最佳的效率生成你的答案。
- 有很多方法可以最佳化效能，但 Trainium 給了建構者工具，讓他們能用自己的模型和應用程式提供出色的效能，而且 Trainium 以顯著更低的成本支援這些工作負載。
- 如你本週所聽到的，Trainium3 將為即使是最嚴苛的 AI 工作負載提供高達 40% 的成本降低。40% 的成本降低。
- 當你在基礎設施上花費數百億美元時，這是一件大事。
- 讓我多展示一些我們是如何做到的，好嗎？
- 這是我們第二代的 Trainium UltraServer。
- UltraServer 是我們將大量 Trainium 伺服器組合成一台 AI 超級電腦的地方。
- 這第二代比我們去年推出的第一代有了重大進步。
- 首先，它基於 Trainium3 晶片，而且數量很多。
- 跨兩個機架有 144 顆 Trainium3 晶片，組合成一台 UltraServer。
- 但我想讓你注意機架中間的那些裝置。
- 那些是 Neuron 交換器（Neuron Switches），用來互連這個機架中所有的 Trainium3 晶片，以建立那台巨大的 AI 超級電腦。
- 但這些不是普通的網路交換器。
- 這些交換器是專門設計的，以極低延遲直接為那些訓練晶片提供全對分頻寬（Full Bisectional Bandwidth）。
- 那這能提供什麼樣的效能呢？
- 在 AI 超級電腦中，關鍵的效能維度是運算和記憶體。
- 這台 UltraServer 兩者都很充沛：360 PetaFLOPS 的八位元精度浮點運算能力，以及 20TB 的高頻寬記憶體（HBM），記憶體頻寬達 700TB/秒。
- 這比去年的 Trainium UltraServer 高出 4.4 倍的原始運算效能和 3.9 倍的頻寬，這使它成為目前最強大的 AI 超級電腦之一，讓我們能運行或建構即使是最大規模的模型。
- 讓我們仔細看看。
- 這些只是帳面數據。
- 聽過我說的人都知道，你得看得比帳面數據更深入。
- 所以讓我們仔細看看 Trainium3 伺服器和晶片，了解它們如何能提供出色的效能和差異化的成本。
- 好，這是其中一個 Trainium 托架（Sled）。
- 你可以直接從 UltraServer 中把它抽出來。
- 一台 UltraServer 中有 36 個這樣的托架，透過所有那些 Neuron 交換器互連。
- 讓我指出幾個很酷的特點。
- 首先，這代表我們第一個在同一塊伺服器板上使用三種 AWS 自主設計晶片的系統。
- 你會看到四顆 Trainium3 加速器位於板子的遠端，緊鄰著的是一顆 Graviton 處理器。
- Graviton 為我們提供了保持這些加速器忙碌所需的高速 I/O。
- 透過將 Graviton 與 Trainium 共置在同一個托架上，我們避免了在機架中需要專用頭節點的需求。
- 這給了我們額外的空間來建構更大的 UltraServer。
- 此外，有了那顆 Graviton 伺服器，我們可以只對這一個托架進行維護，而不需要把其他托架從生產環境中撤下。
- 這有助於讓我們的容量保持在它該在的地方：生產環境中。
- 運行你的程式碼。
- 說到維護，你在這裡可以看到的另一個關鍵差異化特點是，這個托架上的所有東西都可以從頂部維修。
- 這在 AI 伺服器中是獨特的。
- 這個設計在幾個方面帶來了回報。
- 首先，它實現了伺服器的完全機器人組裝。
- 這讓我們能更快地將 Trainium 晶片部署到我們的機群中。
- 其次，當我們需要在生產環境中維修這些系統時，可以快速且高效地完成。
- 好，最後你會看到我們有兩張 Nitro 卡來提供非常高速的網路。
- Nitro 啟用了 EFA（Elastic Fabric Adapter），讓 Trainium 伺服器能與數千台其他 Trainium 伺服器共享記憶體，透過加密通道直接讀寫彼此的記憶體，並內建網路多路徑和容錯機制。
- 如果你想建構一個大規模的訓練叢集並訓練大型模型，這正是你需要的。
Microarchitectural Innovations & NKI 微架構創新與 NKI
- 當然，建構一個出色的系統只是故事的一部分。
- 你需要一顆出色的晶片。
- Dave 今天早上談過這個，但你不會某天早上醒來就突然決定想要一顆出色的晶片。
- 建構一顆出色的晶片是長期不懈執行的結果。
- 這就是我們在 Trainium 上一直在做的事。
- 我們多年來一直與我們的客戶合作，無論是內部還是外部客戶。
- 每次我們建構一顆新的晶片，我們都從客戶的使用方式中學習，而這些學習驅動著我們的下一代產品。
- 一個由客戶驅動創新的循環。
- 我們不專注於基準測試。
- 我們專注於真實的客戶工作負載，並找到創新的方式讓這些工作負載更有生產力。
- 那在 Trainium 上是什麼樣子呢？
- 我們在 Trainium 上新增了許多微架構（Microarchitectural）功能。
- 像這樣的最佳化不會出現在帳面規格上，但所有這些新的最佳化讓 Trainium 運行得更高效。
- 解決常見的機器學習問題。
- 以微縮放（Micro Scaling）為例，它讓你可以使用更低精度的浮點數，同時保持模型的準確度。
- 還有更大的參數、更快的 Softmax、張量解引用（Tensor Dereference）或背景轉置（Background Transpose）。
- 這些最佳化常見的 AI 運算問題，並釋放運算引擎去做其他工作。或者像流量整形（Traffic Shaping）、記憶體累加寫入（Memory Add Right Memory）、雜湊分散（Hash Spraying）。
- 這些讓你的記憶體和網路更高效，讓你的 Trainium 晶片持續被餵入資料。
- 因為雖然 AI 晶片可能在規格表上提供數百 FLOPS 的浮點運算能力，但只有在你能讓資料持續流入運算引擎時，那才有意義。
- 幾乎我們所知的每一個 AI 工作負載都會從這些新的晶片功能中的一個或很可能多個中受益。
- 這是一個好時機提到，這不只是關於擁有最好的晶片或最好的硬體。
- 你需要正確的工具來在那個硬體上建構，而這正是我們深入投資為客戶差異化 Trainium 的地方。對於那些想要榨取每一分效能、需要控制記憶體配置、管線深度等來最大化工作負載效能的客戶。
- 我們的解決方案從 NKI（Neuron Kernel Interface）開始。
- 它是一種語言，結合了矩陣運算的簡潔性與對所有 Trainium 硬體功能的直接指令級存取，全部在熟悉的 Python 程式設計環境中完成。
- 我們剛才看的那些功能都可以透過 NKI 存取。
- 以 Decart AI 為例。
- 那是今天早上把我變成 Werner 卡通版的那個很酷的應用程式背後的公司，那是在 Trainium3 上運行的。Decart AI 使用 NKI 來最佳化他們在 Trainium3 上的即時影片生成模型，並報告 Trainium3 上的效能比他們測試過的任何其他硬體平台都快得多。
- 他們告訴我們，使用 NKI 的最佳化過程快速且直覺。
- 他們等一下就會上台告訴你更多。
- 這帶出了今天關於 NKI 的更新。
- NKI 將在第一季正式發布（GA），我們非常期待把這個強大的工具交到更多客戶手中。
- 我們也會開源 Neuron NKI 堆疊的所有面向。
- 沒有什麼比編譯器突然給你驚喜更糟的了。
- 在你工作的時候。
- 所以對編譯器和程式碼堆疊擁有完全的可見性，將讓你更容易從硬體中獲得最大效能。
- 如果你曾經做過深度效能工程，你知道你最好的朋友是濃咖啡和一個出色的效能分析器（Profiler）。
- 效能分析器讓你詳細看到硬體上正在發生什麼。
- 瓶頸在哪裡？
- 我應該把注意力集中在哪裡？
- 這正是我們透過 Neuron Profiler 提供的。
- 但它的特別之處在於。
- Trainium 在晶片上有專用的硬體功能來分析你的程式碼而不影響效能，這意味著你可以分析在真實環境中運行的實際生產程式碼，而且可以獲得指令級的精確度。
- 這代表你擁有最佳化程式碼所需的全部資訊。
- 今天我很高興分享，我們又向前邁進了一步，推出了 Neuron Explorer。
- Neuron Explorer 將所有那些詳細的效能分析資料，以直覺的介面呈現，讓你容易理解正在發生什麼，並找到改進的機會。
- 事實上，Neuron Explorer 會自動偵測你的瓶頸並建議最佳化方案。
- 這讓你可以花更多時間修復問題，而不是花時間尋找問題。
- 好，我們已經看了很多關於我們如何投資讓 Trainium3 擁有出色效能，以及你可以用來實現這些效能的工具，但讓我們看看那些實際的效能數字。
- 這是 OpenAI 的開源 GPT-OSS 1200 億參數模型，分別在 Trainium2 UltraServer 和 Trainium3 UltraServer 上運行。
- 如我所提到的，Trainium3 UltraServer 比 Trainium2 UltraServer 有 4.4 倍更多的運算能力。
- 所以為了公平比較，我們將一切正規化為每兆瓦輸出 token 數。
- 看看這些提升：每兆瓦輸出 token 數提高 5 倍，同時維持相同的使用者可見延遲。
- 這應該能讓你理解為什麼我們對 Trainium3 如此興奮。
- 順帶一提，對於有興趣深入了解的人，我們將開源這些程式碼，包括相關的 NKI 核心，讓你可以從中學習和重複使用。
- 我已經介紹了很多關於我們如何建構 Trainium 來運行你能丟給它的任何 AI 工作負載，以及我們如何努力讓你能用 Trainium 獲得差異化的效能和更低的成本。
PyTorch Native Integration PyTorch 原生整合
- 但我們一直在做另一件非常重要的事，讓每個人都能輕鬆使用 Trainium，而不需要學習一個全新的晶片和一個全新的程式語言。
- 這就是為什麼我很興奮地分享，Trainium 正在成為 PyTorch 原生（PyTorch Native）。
- 這是什麼意思？
- 讓我展示給你看。
- 我們來移植一些程式碼。
- 好，這是在我們可靠的 NVIDIA GPU 上運行模型的程式碼。
- 現在，如果我們把簡單的一行從 CUDA 改成 Neuron，我們就準備好在 Trainium 上運行了。
- 就是這樣。
- 就這麼簡單。
- 現在每個人，研究人員、學生，甚至 Dave，都可以使用 Trainium 而不需要運行一個全新的軟體堆疊。
- 好，這種無縫整合得益於 PyTorch 團隊出色的工作，讓我們能支援不同的後端。
- 我們已經在一些客戶那裡讓這個功能運作了，預計在明年初廣泛發布。
- 當然，建構晶片最令人興奮的事就是把它們交到客戶手中。
- 對於 Trainium3，我們對客戶的早期回饋非常滿意，而我們與 Anthropic 的合作就是一個很好的例子，展示了我們與客戶深度協作如何幫助我們生產領先的 AI 加速器。但我們也對一些正在用 Trainium 做新穎且令人興奮的事情的創新新創公司感到興奮。
Decart: Real-Time Visual Intelligence Decart：即時視覺智慧
- 我想邀請一位已經在用 Trainium3 和 NKI 建構的客戶上台。
- 請和我一起歡迎 Decart 的執行長 Dean Leitersdorf。
謝謝 Peter。
很高興宣布我們一起在做的事。
- 今天我要給你們看一些全新的東西，一些世界上從未見過的東西。
- 這是一個全新的生成式 AI 基礎模型類別，叫做即時視覺智慧（Real-Time Live Visual Intelligence）。
- 看看我左右兩邊的螢幕。
- 我們現在都在 re:Invent 現場。
- 但如果我們想讓一切都 powered up 呢？
- 稍早 Peter 走上舞台時，他看起來像 Werner，那就是我們模型的藝術。
- Decart 基礎模型在 Trainium3 上即時運行。
- 你現在看到的每一個像素都是在這個舞台上即時生成的。
- 在 Decart，我們是一個效率優先的 AI 研究實驗室，我們正在為視覺智慧建構基礎模型。
- 視覺是我們看世界的方式。
- 它是我們溝通的方式。
- 它是人類互相理解的方式，也是機器人將來能理解我們世界的方式，在生成式模擬中訓練自己。
- 這就是影片模型和世界模型的意義所在。
- 而且它正在即時發生。
- 因為這是第一次，我們能將 LLM 的基礎模型和影片擴散模型同時運行，而且零延遲。
- Trainium3 對我們的工作負載來說是一個巨大的推動力，並且創造了這個即時視覺智慧的全新生成式 AI 類別。
- 在 Decart，我們有很多專有技術，讓我們能更快、更高效地訓練和推論模型，我們與 AWS 團隊緊密合作，將我們的模型堆疊、基礎設施移植到 Trainium 上，讓我們能用 Trainium 來建構和運行模型。
- 我們用 NKI 語言來最佳化這一切，就是 Peter 剛才談到的，它讓轉移比我們預期的快得多。
- 我說的是，我們正走在每秒幀數效能達到最先進 GPU 4 倍的路上。
- 80% 的 Tensor Core 使用率。
- 這些是我們在 AI 領域聞所未聞的指標。
- 我們能獲得這個效能的原因，是我們如何結合 Trainium 和我們的模型。
- 我們在 Decart 訓練的模型有三個組件。
- 一個做推理、理解世界的 LLM，一個理解像素、理解結構的影片模型，以及一個讓兩者連接並一起運行的編碼器。
- 通常我們必須依序運行這些，一個接一個。
- 但我們能建構一個 Trainium 巨型核心（Megakernel），是我們自己編寫的，讓三個同時在同一顆晶片上以零延遲運行，同時實現最大的 HBM 記憶體使用率、張量引擎使用率，全部同時進行，沒有延遲。
- 我們已經看到我們的模型如何改變我們的線上行為。
- 在 Twitch 上，有直播主用我們的模型為觀眾創造新穎、引人入勝的體驗。
- 在購物方面。想像你看到一盞很酷的燈，在購買之前，你就能看到它。
- 下次你看電影時，它會被放進那部電影裡，只為你。
- 我們正在努力確保每一個產品，在你線上購買之前，你都能在自己身上和家裡試用，看看你的感覺。
- 看看它的效果。
- 我最喜歡的體驗之一是籃球。
- 你正在看比賽，為了讓你的孩子保持專注，你讓他們看 Decart AI 卡通版，這是從比賽中即時生成的。
- 我們正在把 AI 帶入即時體育賽事、帶進競技場、帶進你的客廳。在遊戲方面，我們正在建立一個全新的基礎，遊戲在被遊玩的過程中自我生成。
- 坦白說，你剛才看到的一切、所有這些體驗，都不是我們想出來的。
- 是建構者。
- 是開發者拿了我們的 API。
- 你們比我們更了解你們的產業，你們能理解如何運用這些模型，為你們的客戶、為你們的產業創造價值。
- 如果我們展望幾年後的未來。
- 我真的相信要把這項技術帶到機器人和模擬領域。
- 機器人已經在使用像這樣的模型來設想無限的可能性、無限的結果，在道路上、在家中、在工廠、在製造業，未來我們將能在機器人踏上地面之前，完全在生成式模擬中訓練它們。
- 當它們踏上地面時，它們將使用即時視覺智慧來理解周圍的世界，理解人類的環境。
- 我非常高興能在這裡與 AWS 一起宣布這個全新的生成式 AI 類別：即時視覺智慧。
- 我們要把它帶到每一個產業、每一個市場、任何規模，由 Trainium3 驅動，使用 Decart 模型。
- 我們建構的一切都放在我們的 API 上。
- 每隔幾週，我們就在行動應用程式上發布，世界正在第一次轉變。
- 我們可以把想像中的東西，和我們眼前看到的現實連結起來。
- 即時的。
- 我真的迫不及待想看到你們用它建構出什麼。
- 謝謝大家。
Closing Remarks 結語
好的。
- 謝謝 Dean。
- 今天早上我們一開始就問了 AI 對我們的基礎設施意味著什麼。
- 在探索了這一切之後，我希望答案已經很清楚了。
- 基本面比以往任何時候都更重要。
- 安全性。
- 可用性。
- 彈性。
- 敏捷性。
- 成本。
- 這些不是前 AI 時代的遺物。
- 它們是未來應用程式將建構其上的基礎。
- 我們從 Nitro 到 Graviton 到 Lambda 所做的投資，不只是為了解決昨天的問題。
- 它們正是為了這一刻做準備。
- 今天你看到了那些準備的成果。
- Graviton5 在一個大容量快取中提供 192 個核心。
- Lambda 託管執行個體擴展了無伺服器的意義。向量成為你資料的連接組織。而 Trainium3 為你能想像的每一個 AI 工作負載帶來出色的效能和更低的成本。
- 但最讓我興奮的是什麼。
- AI 仍然是第一天。
- 會有我們誰都無法預測的曲折和轉變。
- 新的架構將會出現。
- 新的可能性將會展開，而 AWS 會在這裡，就像我們過去 20 年一樣。
- 移除限制，提供建構模塊，幫助你應對接下來的一切。
- 所以你接下來要建構什麼？
- 但首先記得，不要錯過 Werner 的閉幕 keynote。
- 謝謝大家，祝你們這週餘下的時間愉快。