六位AWS工程師如何重構Bedrock,向微軟發起挑戰

環球市場播報
09/09
戴夫・布朗在 AWS re:Invent 2025 大會介紹 「地幔計劃(Project Mantle)

  作者:凱瑟琳・珀洛夫、凱文・麥克勞克林

  2025 年初,亞馬遜雲內部氣氛緊張。用於運行 AI 大模型的新服務 Bedrock 漏洞頻發。知情人士透露,客戶反覆收到報錯信息,有時需要等待數周才能拿到所需算力。

  兩名直接了解內情的人士稱,在各類問題集中爆發之際,資深工程負責人安東尼・利戈裏牽頭團隊,制定 Bedrock 重構方案 —— 也就是地幔計劃(Project Mantle),旨在解決限流與報錯問題,讓這項服務具備擴容能力,服務更多用戶。利戈裏聯合另外五位資深工程師,藉助 AWS 自研 AI 編程工具 Kiro 打造 Mantle。

  Mantle 於去年 12 月正式上線。數月之後,AWS 在 Bedrock 的模型矩陣中加入 OpenAI 模型(平台原本已接入 Anthropic 的 Claude 等模型),業務隨即快速升溫。

  諮詢公司 Caylent 首席技術官蘭德爾・亨特表示,現在已經有一部分客戶將雲預算從微軟 Azure 轉移到 AWS。雖然 AWS 在雲市場份額和營收規模上大於 Azure,但此前微軟雲是唯一可以提供 OpenAI 模型的平台,這讓它領先其他雲廠商。

  他稱:「客戶現在可以在 Bedrock 獲得穩定可靠的性能,而在 Azure,性能表現難以預估。」 亨特說,他服務的金融客戶在 AWS 上的開銷自 5 月以來增長了四倍。在他看來,AWS 這項 AI 服務性能優於微軟等競品。

  亞馬遜 7 月披露,2026 上半年 Bedrock 新增客戶數量已經超過該服務上線頭兩年總和;第二季度客戶在 Bedrock 上的花費,超過此前所有季度的總和。亞馬遜沒有單獨披露 Bedrock 營收,但財報顯示 AWS 二季度增速提升 9 個百分點至 37%;微軟 Azure 增速 42%,按月提升 2 個百分點。

  微軟在聲明中表示:「隨着 AI 應用普及,工作負載從模型開發轉向大規模推理與智能體應用,微軟持續迭代 AI 技術棧,滿足客戶不斷變化的需求與持續增長的 AI 算力需求。」

  Bedrock 早期的困境說明:即便 AWS 是全球市場份額最高的雲廠商,AI 巨大的算力需求也給它帶來重重難題。

  AWS 發言人在聲明中表示:「為跟上 Bedrock 激增的需求,我們從頭重寫推理引擎,兼顧性能與安全。這套方案已經獲得客戶廣泛認可。Bedrock 是 AWS 史上增長最快、規模達數十億美元的業務,已有數十萬客戶使用。」

  技術難題

  2022 年底 ChatGPT 發布拉開 AI 競賽序幕,時隔近一年,AWS 在 2023 年秋季推出 Bedrock。亞馬遜此前已經擁有 SageMaker 等 AI 工具,但在 AI 浪潮初期起步不順,給微軟創造機會。一名項目參與者稱,AWS 工程師每周工作 60 小時,打造這項服務,讓客戶能夠把雲應用接入大語言模型。

  AWS 推出這項新服務,部分原因是客戶無法在原有系統上運行頭部 AI 模型。和普通軟件不同,大模型使用的是 AI 企業嚴格保密的專有權重,模型廠商不允許客戶直接訪問權重。

  但倉促開發上線的 Bedrock,在後續兩名項目參與者看來,產品有種 「拼湊感」。一位內部人士和另一名項目成員表示,原有架構無法充分利用 AI 芯片算力,導致客戶頻繁報錯,限制 Bedrock 大規模擴容。

  AWS 發言人回應:「我們持續迭代服務,力求盡善盡美。但在我們這種體量下,偶爾會出現難以預見的問題,我們會識別、同步客戶並儘快解決。」

  與此同時,客戶算力配額問題越來越突出。每個用戶擁有基礎算力額度,一旦用量上升就會被限流,需要等待 AWS 釋放更多算力。一名前員工稱,部分客戶等待時長最長可達三周。

  一名產品團隊成員透露,2025 全年不斷有客戶投訴,亞馬遜限制他們調用 Anthropic 模型。AWS 管理層一度擔心 AI 代碼初創公司 Lovable 會因為 Bedrock 調用 Claude 困難而遷出平台。

  一名看到這份內部文檔的人士稱,2025 年初,AWS 銷售團隊傳閱一份內部報告,指出 Bedrock 的技術缺陷正在阻礙獲客。同期 The Information 報道,高層將 Bedrock 算力危機稱作一場 「災難」。

  亨特表示,客戶實測發現:2024 年,Bedrock 上運行 Anthropic 模型的吞吐(token / 秒)最高比直接對接 Anthropic 慢 63%。企業直連模型廠商,是通過 API 調用,模型本身依然託管在雲服務器;Anthropic 除 AWS 外,還在谷歌雲提供模型直連 API。

  Bedrock 的問題甚至引發亞馬遜其他業務線高管不滿。兩名聽過相關談話的人士稱,時任亞馬遜電商高級副總裁戴夫・特雷德韋爾在 2025 年初向 AWS 管理層表示,Bedrock 持續報錯、算力緊張,讓他想直接改用 OpenAI 原生模型(OpenAI 原生模型主要託管在微軟 Azure)。一名接近亞馬遜的人士對特雷德韋爾這番說法提出異議,特雷德韋爾現已轉崗至 AWS。

  Mantle 的解決方案

  隨後,利戈裏提出打造 Bedrock 新版本的構想。在去年 12 月 AWS 年度 re:Invent 客戶大會上,時任雲服務器業務負責人戴夫・布朗推出 Mantle—— 支撐 Bedrock 運行的全新技術層。他介紹,Mantle 的目標是讓 Bedrock 可以持續擴容,滿足未來預期需求。

  布朗在大會主旨演講中說:「隨着模型迭代、使用量上漲,我們意識到推理需要一套全新架構。」(布朗近期離開 AWS,加入 Meta)

  布朗同時指出初代 Bedrock 架構缺陷:它沿用傳統 Web 服務的設計思路搭建。

  但驅動應用的大模型運行過程,也就是推理,遠比傳統雲業務複雜。傳統雲業務主要是客戶存儲、調取數據分析;推理需要隨時調度足夠服務器承接波動巨大的負載。2025 年,客戶開始用 AI 處理更復雜任務,這一矛盾愈發明顯。

  布朗在 re:Invent 上稱:「推理的運行邏輯,和我們過去二十年持續優化的傳統計算模式完全不同。」

  Mantle 專門適配複雜 AI 任務尖峯負載:算力瞬間衝高,隨後迅速回落。早期 AI 任務相對簡單,舊架構尚可支撐,新的 AI 智能體長任務,則需要全新的算力分配機制,AWS 發言人如此說明。

  為解決大規模場景下的算力尖峯問題,Mantle 新增功能:客戶可對 Bedrock 內不同任務設定優先級,AWS 可以把更多算力分配給客戶的高優先級任務。Mantle 還做了負載隔離,發言人打比方:就像演唱會場館設定多個獨立入口,單個客戶的高負載只會佔用自身配額,不會擠壓其他客戶資源。

  AWS 還強化 Mantle 與已有服務 Journal 的兼容性。Journal 可以保存 AI 智能體的任務進度,長任務中途中斷後無需從頭重新運行,以此適配越來越多的長時 AI 任務。

  參與 Mantle 研發的 AWS 前副總裁喬・馬格拉莫羅夫,在今年 1 月 AWS 播客節目中表示:「通過 Mantle,我們認識到推理本質上不完全是 Web 服務,更像一套調度系統。」(馬格拉莫羅夫上月跟隨布朗一同加入 Meta)

  API 原生兼容

  Mantle 實現對 OpenAI、Anthropic 原生 API 直接兼容。初代 Bedrock 要求客戶編寫定製代碼,才能調用這些 AI 實驗室的模型接口。

  2026 年初 Mantle 全面落地。一名前員工說,客戶申請擴容的等待時間,從 2025 年初的三周,在當年年底縮短至兩天。亞馬遜 CEO 安迪・賈西在 2026 致股東信中,將 Mantle 稱為 「大獲成功的 Bedrock 服務的技術基石」。

  亞馬遜稱,2025 年後期,Bedrock 主要跑在自研 AI 訓練芯片 Trainium 之上。在英偉達芯片持續供給受限的背景下,這為 AWS 新增算力來源。

  當然,客戶使用該服務偶爾仍會遇到延遲。一家藉助 Mantle 在 Bedrock 調用 Claude 的企業經理表示,過去數月曾間歇性遭遇服務中斷,最長一次持續約 11 小時。

  AI 諮詢公司 Loka 機器學習負責人博揚・亞基莫夫斯基稱,已有六家客戶轉至 Bedrock 上運行 OpenAI 模型,不再直連 OpenAI 或者使用 Azure。

  亞基莫夫斯基說:「遷移有不少好處,推理速度更快、整體吞吐量更高;成本不變,其他參數也完全一致。」

免責聲明:投資有風險,本文並非投資建議,以上內容不應被視為任何金融產品的購買或出售要約、建議或邀請,作者或其他用戶的任何相關討論、評論或帖子也不應被視為此類內容。本文僅供一般參考,不考慮您的個人投資目標、財務狀況或需求。TTM對信息的準確性和完整性不承擔任何責任或保證,投資者應自行研究並在投資前尋求專業建議。

熱議股票

  1. 1
     
     
     
     
  2. 2
     
     
     
     
  3. 3
     
     
     
     
  4. 4
     
     
     
     
  5. 5
     
     
     
     
  6. 6
     
     
     
     
  7. 7
     
     
     
     
  8. 8
     
     
     
     
  9. 9
     
     
     
     
  10. 10