云計算的牌桌上，AI 算力競賽已是刀刀到肉。當行業逐漸對“堆卡”祛魅，真正的較量早已轉移到看不見的戰場——架構是否精妙；是否緊密貼合業務需求；以及如何破解規模定律（Scaling Law）效應減弱的魔咒。

    在 8 月 14 日的飛天發布時刻，國內公有云一哥阿里云亮出底牌，發布通用計算、容器計算及存儲服務三項產品更新。這三大產品看似“分管”不同任務，實則巧妙地串聯出一條 AI 落地業務場景的完整路徑，每一步都為下一步鋪平道路，環環相扣，層層遞進。

    對于行業而言，阿里云此次發布的意義也不止于一次產品升級，其背后的產品升級邏輯也在引導行業重新思考——AI 時代，云基礎設施的本質到底是什么。

    場景化實例，

    定義極致性能與資源利用效率

    傳統 x86 服務器運行數據密集型業務時，常常卡在“算力不夠強、吞吐不夠快、內存不夠大”這三道硬限制上。

    此次飛天發布時刻，阿里云共發布三款企業級實例，把同一批 AMD 硬件做成三檔規格，用戶按需取用即可：

•     u2a：CPU 與內存比例適中，價格最低，適合日常網站或輕量推理等通用需求。

•     g9a：CPU 主頻更高，能大幅提升單進程任務數據的處理效率，適合在線型應用場景。

•     g9ae：采用物理核設計，算力更高，內存帶寬更大，I/O 能力更強，適合高并發的計算密集型任務。

    三款實例均搭配了 AMD 最新第五代 EPYC 處理器（Turin ）。阿里云和 AMD 雙方的合作最早可追溯到 Rome 時期，當時就與 AMD 合作進行芯片定制，到 Milan 時期開始規模商業化，性能提升 15%，Genoa 時期性能則提升 25%。

    到今天，服務于數據中心的 EPYC 系列處理器，采用業界領先的 chiplet 架構，已經演進到第五代，即 AMD EPYC 處理器都靈 (Turin)。Turin 采用了全新的“Zen 5”核心架構，Zen 5 架構每時鐘周期指令（IPC）比上一代提升 17%；結合 Turin 支持全鏈路 AVX512 的能力，為 AI 和高性能計算（HPC）提供高達 37% 的 IPC 提升。

    在 Turin 處理器基礎上，通過阿里云軟硬一體的 CIPU 架構驅動，此次發布的三款企業級實例實現了針對差異化場景的產品布局，讓不同業務直接落在最匹配的檔位，節省資源的同時也幫企業節省了算力預算。

    首先來看面向中小型企業的 u2a。

    “u”實例為通用算力型“universal”實例的簡稱，是一款為中小企業量身定制的云服務器。基于阿里云飛天云計算操作系統和云基礎設施處理器（CIPU），“u”實例讓中小企業像使用水、電和煤氣一樣，便捷獲取性能強勁、性價比出眾的云計算服務，無需投入精力自建或運維硬件設施。

    此次全新升級的 u2 系列中，阿里云推出了首個基于 AMD EPYC 處理器的“u”實例——u2a。該系列涵蓋兩款細分產品，提供了企業級獨享算力，目前仍處于定向邀測階段，預計于 8 月 30 日正式開啟商業化。

    u2a 采用自研雙單路服務器架構，單顆 CPU 故障不會影響另一顆，能夠顯著提升服務器的穩定性。性能上，u2a 實例性能基線較 u1 提升 20%，支持最高 15% 的算力突發能力；網絡基線帶寬為 16Gbps，支持突發至 25Gbps；最大規格可支持 64vCPU。

    面向通用場景，u2a 能滿足企業不同層級的數據處理需求，通過屏蔽代系差異和較 u1 提升 50% 的性價比，將企業級算力的門檻大幅降低，讓更多中小企業能享受到技術紅利。

    跟隨 u2a 一同發布的，還有第九代 ECS 性能旗艦產品，AMD 企業級實例 g9ae。

    對于大數據、搜推廣、視頻轉碼等數據密集型業務，g9ae 實例瞄準內存帶寬、I/O 帶寬不足的行業痛點，基于 Turin D 處理器，創新性地采用了物理核設計，摒棄了傳統的超線程虛擬化思路。這意味著每個 vCPU 都獨占 L3 緩存和內存通道，算力不再因通道帶寬不足而被壓制。

    阿里云之所以能首創物理核設計，離不開底層硬件的支持。

    事實上，Turin 包含 Turin-C（Turin Classic）、Turin-D（Turin Dense）兩款 CPU，都使用 Zen5 的微架構，其中 Turin-C 使用了 Zen5 CCD，而 Dense 是 Zen5c CCD。

    Zen5 和 Zen5c 微架構相同，指令集相同，IPC 提升相同，區別在于 Zen5c 的核心計算單元（CCD）通過芯粒（chiplet）架構支持更高的核心密度，從而支持阿里云實現首創的 “物理核設計”。

    “物理核”設計讓 g9ae 實例單 vCPU 算力提升高達 60%，在視頻轉碼等業務中性能提升高達 65%，并能極大降低核心交易系統的長尾時延，性能輸出更穩定。

    在 AMD 強大硬件的基礎上，阿里云自研操作系統又將其性能充分“兌現”了出來。阿里云彈性計算產品經理姬少晨介紹，g9ae 的極致性能還來源于軟硬件的深度融合。阿里云把自研的 Alibaba Cloud Linux 3 與 AMD 最新的 Turin 服務器做了“基因級”適配，涉及兩百多個內核補丁、改了近 2 萬行代碼，相當于把操作系統“重新編譯”了一遍，專門針對 AMD 的多核、內存通道、IO 路徑做優化。

    針對 MySQL 查詢場景，操作系統存儲引擎的預讀機制會把數據提前加載到 CPU 的高速緩存中，再借助 g9ae 的超大內存帶寬，查詢速度再提升 10%；針對搜推訓練場景，操作系統的網絡協議棧采用“零拷貝”技術，數據包從網卡到應用內存“一次到位”，單節點推理性能再提 15%。

    除極致性能外，端到端的數據安全能力也是 g9ae 的一大亮點。g9ae 開機即由 CIPU 可信根從 BIOS 到 kernel 再到操作系統開啟全鏈路度量，防止惡意植入；運行期間，AMD 機密計算給內存加硬鎖，數據可用不可見；在數據傳輸階段，首發 VPC 加密能力，實現了數據傳輸過程中的安全防護。

    然而，盡管 g9ae 性能強大，但真實業務場景產生的 AI 負載遠非單個計算實例所能承載。AI 工作負載遠比傳統 Web 應用復雜，它有狀態、角色多樣、且需“同生同死”。

    以一個 32B LLM 模型推理為例，模型啟動瞬間可能占用 65GB 顯存，接下來可能因并發請求膨脹到 200GB。推理服務在短時間內可能從 8 卡擴展到數百卡，再逐步縮回——這對于整個系統的調度、存儲及網絡通信效率都提出了更嚴苛的要求。

    單實例性能提升雖顯著，但 AI 負載的復雜性要求更全面的基礎設施支持。要破解這些難題，就需要上述企業級實例和容器、存儲服務協同作戰。

    容器激活“算力流通”，

    存儲激活“數據流通”

    容器作為云原生時代彈性計算的核心技術，在 AI 時代，它也逐漸從十年前“讓應用跑起來”的封裝工具，升級為未來算力的通用接口。

    這場變革中，Kubernetes 已經成為承載 AI 負載的事實標準，是當前最主流、最廣泛采用的 AI 基礎設施平臺。根據 CNCF 2024 年度用戶調研，已有 52% 的受訪終端用戶在 Kubernetes 上運行 AI/ML 工作負載。我們確實也看到，主流云廠商、大模型實驗室，以及新興的 AI 初創公司幾乎都選擇以 Kubernetes 作為 AI 應用的運行底座。

    這種情況下，企業面臨的問題就不再是“要不要上 Kubernetes”，而是“怎樣把 Kubernetes 用得更好”。

    在此次飛天發布時刻，阿里云正式對外宣布了 ACK 和 ACS 兩項容器服務的最新進展，核心就是向用戶提供一種把 Kubernetes 用得更好的方法論。

    其中，阿里云容器服務 ACK 在保障穩定性和提升 AI 部署效率兩個維度均有新突破。

    穩定性方面，ACK 通過高效管理運維異構資源以保障業務穩定性，并實現三項能力突破：

•     異構資源管理： 通過統一的 ACK 控制面，將 GPU、靈駿、遠程直接內存訪問（RDMA）、智算版并行文件系統（CPFS）等異構智算資源納入同一技術棧，用戶無需再為每類硬件單獨適配。

•     GPU 故障自愈： 平臺先為硬件或軟件異常建立標準化判別模型；一旦觸發規則，立即隔離故障 GPU，防止錯誤分配，隨后調用 IaaS 層接口嘗試修復，修復成功后自動解除隔離并重新調度任務，顯著降低人工干預。

•     在線實時 GPU AI Profiling：借助 eBPF 與 library injector，用戶在不改代碼、不重啟服務的情況下即可實時抓取 GPU 運行時數據——涵蓋 CUDA kernel（含 NCCL 通信算子）及 PyTorch 高層調用——按時間軸還原現場，在線定位瓶頸，官方數據顯示診斷效率提升 50% 以上。

    此外，為幫助企業以更低成本、更高效率、更強穩定性將大模型落地到生產環境，并讓模型能力真正高效、安全地賦能業務流程，ACK 此次也全新發布了云原生 AI 套件 Serving Stack。

    該套件包括 RoleBasedGroup 控制器（簡稱 RBG）和 Gateway Inference Extension（簡稱 GIE）兩大組件。

    RoleBasedGroup 控制器（簡稱 RBG）是該套件在 Kubernetes 集群中針對 LLM 推理工作負載的抽象層。

    RBG 支持主流 LLM 推理引擎，如 vLLM、SGLang、TRT-LLM 等，兼容各類推理性能優化架構，如 Dynamo、Mooncake 等。 RBG 能夠將分布式推理工作負載中的不同任務角色（如 Prefill worker、Decode worker、Router 等），靈活地抽象為獨立的 Role；并支持采集不同角色的關鍵監控指標（如 TTFT、TPOT、Token throughput、Request rate 等），聯動推理運行時可支持基于 SLO（如平均 TTFT/TPOT）的彈性伸縮。

    同時，RBG 還內置對 HPA、cronHPA、KPA、AHPA、KEDA 等 Kubernetes 生態中各類應用彈性伸縮架構的兼容，以適應不同場景需求；并結合 Fluid 的分布式緩存和數據預熱技術，能夠大幅提升 LLM 推理服務彈性伸縮的響應速度和效率。在 Deepseek R1 推理服務啟動速度測試中，Fluid 在 220 秒內將 671B 模型權重數據從遠程對象存儲讀取到 GPU 顯存中，達到 10GiB/s 以上的帶寬。這將 Deepseek R1 模型加載耗時減少了 90%。

    GIE 則是 ACK 基于 Kubernetes Gateway API 的推理擴展組件，支持灰度發布、過載檢測、請求排隊、熔斷限流。在 Qwen、Deepseek 等模型推理服務壓測中，長尾場景下的首包延遲提升 73%，緩存利用率提升 90%，前綴感知負載均衡優化帶來 40% 的響應速度提升。

    總的來看，在云原生 AI 套件 Serving Stack 中，RBG 負責 LLM 推理服務的部署，更新，升級等全生命周期管理，并根據業務指標動態調整實例規模，GIE 負責根據實時請求負載情況和模型處理能力智能路由流量。兩者一起打配合，讓大模型生產化部署做到低成本、高效率，同時具備強穩定性。

    容器計算服務 ACS 此次則新上線了 AMD 通用算力，并在以下五個維度實現技術突破：

•     性能： 在視頻編解碼、圖形渲染、大數據等計算密集型場景，AMD 實例端到端性能最高提升 55%。

•     規格：CPU 與內存最小粒度為 0.5vCPU、1GiB 步長，且 CPU 和內存配比可在 1:1～1:8 之間自由組合，更貼近實際負載，避免資源浪費。

•     彈性：AMD 實例可支持分鐘級萬個 Pod 彈出，并支持 AHPA 預測式伸縮；用戶可按需單獨使用 AMD，或采用 AMD 與其他異構芯片混合部署。

•     BestEffort 模式：新增可搶占式 AMD 實例，價格為常規實例的 20%；系統在資源緊張時自動驅逐這些實例，能夠滿足離線批處理、測試等對穩定性要求低、對成本極敏感的業務。

•     成本優化： 推出按日承諾付費計劃，用戶以“每日預計使用規模”提前鎖定折扣，進一步壓低長期算力價格。

    整體來看，ACS 以“容器算力”形態將通用算力切分得更碎、更便宜，ACK Pro 則在容器編排層讓 GPU 像水電一樣隨取隨用、故障自愈，兩條線合起來指向同一個結論：

    單純采購算力資源已經無法滿足 AI 負載的需求，貼合負載需求靈活地調度算力資源，已經成為 AI 算力發展的主線。

    然而，要讓 AI 真正落地業務場景，只實現算力的靈活調度還不夠，還需解決計算過程中產生數據的去向問題。

    AI 訓推產生的大量權重、日志、KV-Cache 均需長期留存；多輪對話、個性化推薦等場景又要求毫秒級找回歷史狀態；一旦存儲跟不上算力彈性，就會出現 GPU 空轉、成本飆升的尷尬局面。

    因此，靈活調度算力的下一步，就是靈活調度存儲。目前，Agentic AI 的趨勢已經把 AI 任務對靈活調度存儲的需求推到極致。

    在此次飛天發布會上，阿里云表格存儲 Tablestore 還宣布全面升級 AI 場景支持能力：

•     功能方面，Tablestore 升級多元索引能力，新增 JSON 格式，相對嵌套（Nested）數據類型性能更好，成本更低；并支持多列向量，降低數據冗余，加速關聯查詢；

•     數據模型方面，Tablestore 推出了全新開源的 AI Agent Memory 框架，瞄準對話記憶和知識管理兩大場景，預置了會話（session）、消息（message）、知識庫（knowledge）三大通用數據模型，讓開發者無需關注底層存儲細節，更加專注業務創新本身。

•     生態方面，Tablestore 可通過 OpenMemory MCP（模型上下文協議）一鍵部署 AI 記憶方案，并接入開源 Dify，提供高可用性向量存儲方案以及 Spring AI，承接記憶（Memory）和知識（Knowledge）引擎的存儲需求。

    在上述更新基礎上，Tablestore 又通過 DiskANN 等先進向量檢索算法，按需計費與自動彈性伸縮能力以及默認支持跨可用區部署三項升級，較傳統自建方案降低 30% 的整體存儲成本。

    小   結

    阿里云的這套連招，每一步都在試圖讓基礎設施匹配業務，而不是業務遷就基礎設施。

    過去，企業必須先“買下”一臺規格固定的機器，再去削足適履地改寫應用；如今，ACS 把算力切成 0.5 vCPU 的微小單元，ACK Pro 把 GPU 故障自愈、AI Profiling、分布式推理調度做成水電煤一樣的基礎服務。當算力可以按需膨脹、按秒計費、按故障自愈，業務邏輯第一次不必再為底層資源讓步。

    更進一步看，當容器層把“計算”抽象到極限，存儲層必須同步把“記憶”抽象到極限——Tablestore 以 PB 級彈性、毫秒級檢索、開源 Memory Framework，讓智能體的“長期記憶”也變成可插拔的公共服務。于是，應用只需描述“我要多少算力、我要記住什么”，而不必關心“我從哪里買機器、我把數據放哪”。

    阿里云此次發布會也越發凸顯了云計算的本質不只是算力資源，而是一種“服務”屬性。未來，算力與存儲也將繼續“服務化”，價格曲線與性能曲線或許會逐漸解耦，企業只為業務峰值買單。

    當資源不再成為瓶頸，真正的競爭將回到業務創新本身——誰的場景抽象得更準，誰的模型迭代得更快，誰就能在下一輪浪潮中勝出。