AMD+Helios 讓 Cerebras 先拆流量

以前一顆晶片包到底，現在把推理拆成前段吞吐和後段生成兩條路。

我盯 Cerebras 很久了，老實說我一直卡在同一個問題：它老愛把故事講成「一顆晶片解決全部」。聽起來很爽，demo 也很漂亮，但真實推理流量根本不是這樣。有人只問一個短問題，有人丟超長上下文，還有人要低延遲、要吞吐、要成本，三個願望一次滿足。你如果硬把這些流量塞進同一條管線，最後通常不是跑得慢，是你根本不知道慢在哪。

這次 AMD Helios 的合作把我的注意力拉回來了。我看到的不是一則漂亮的合作稿，而是 Cerebras 終於把話講白：推理基礎設施本來就不是單一加速器的題目，而是流量分流題。這種感覺我在自己搭模型服務時也踩過，前面 ingest、retrieval、context packing、generation 全混在一起，表面上很整齊，實際上就是一團難調的爛攤子。

我這次拆解的來源是 Yahoo Finance 轉載 Zacks Research 的這篇：Can AMD Partnership Strengthen Cerebras' AI Infrastructure Leadership?。文內提到 Cerebras 會在資料中心部署 AMD Helios，並在 2026 下半年透過 Cerebras Cloud 推出聯合方案；它還給了兩個很有用的數字：整合後平台可達到最高 5 倍的 tokens-per-second-per-watt，Cerebras 也把 2026 core revenue guidance 調到 8.55 億到 8.65 億美元。

Cerebras 現在賣的不是晶片，是流量分工

AMD Helios 負責高吞吐的 prompt processing 和大上下文，Cerebras WSE 負責超低延遲的 token 生成。

翻譯一下就是，Cerebras 不再假裝一顆加速器能把推理全包。AMD 吃前段那坨寬而重的工作，Cerebras 吃後段那個要快吐 token 的工作。這比「我們更快」這種口號實在多了，因為它直接對準真實請求長什麼樣。

我以前做長上下文 assistant 的 serving pipeline，也撞過同一堵牆。第一個 token 慢很煩，但更煩的是前面那串事情：prompt ingest、檢索、上下文拼接、還有那些看起來沒做事、其實在卡整體延遲的小停頓。等我把流程拆開，才發現 latency 不是一個數字，而是一串決策。

實操上你可以這樣做：先不要畫一條「模型推理」的大直線，改成拆成 prompt processing、context handling、generation、post-processing 四段。每一段都問一次：這段最吃的是吞吐、延遲、記憶體，還是功耗？如果你現在還是「一個模型、一池 GPU、一個 queue」，你大概正在用錯方式買算力。

• 前段用高吞吐路徑處理 prompt ingest 和 context assembly。
• 後段用低延遲路徑處理 token generation 和互動式回覆。
• 每段分開量，不要把所有東西平均成一個 SLA。

這也是為什麼這個 AMD 合作不是裝飾品。Cerebras 不是多掛一個 logo 而已，它是在說：推理基礎設施要按工作負載長相來配。這種說法比「我們有最快的東西」更有用，因為買 AI 基礎設施的人現在買的不是最快，而是最不痛。

tokens-per-watt 才是這篇真正的重點

文內提到整合平台最高可達 Cerebras-only 方案的 5 倍 tokens-per-second-per-watt。這種數字我會認真看，因為它不是在比誰跑分好看，而是在講營運成本。

tokens per second 很重要，但 tokens per watt 更直白。它逼你把吞吐放回真實世界：機櫃真的在跑時，這些 token 到底要燒多少電。我看過太多團隊開心地秀峰值吞吐，卻把電力、散熱、機櫃利用率晾在一邊。等財務來算帳，才發現最好的系統其實是最不會燒預算的那個。

這裡的意思很簡單：Cerebras 和 AMD 想把 serving stack 做得更密、更省，不只是更大。每瓦能吐更多 token，你就有空間降價、拉毛利，或兩個一起做。現在 cloud AI pricing 壓力這麼大，這種指標比漂亮 demo 圖實在多了。

實操上，我會叫你把 latency 和 throughput 以外的指標也塞進同一張表：功耗、機櫃密度、持續利用率。只要 vendor 說不出 sustained load 下會怎樣，我就會把它當成只會報峰值的簡報機器。

• 同時追 tokens/sec、tokens/sec/watt、p95 latency。
• 測 sustained performance，不要只看短 burst。
• 把 power 和 cooling 算進 TCO。

AMD 這邊也不是路人。它的 Instinct 跟 rack-scale 方向，讓 Cerebras 能把推理前半段接起來。Cerebras 還是 wafer-scale 的招牌沒錯，但它終於不用假裝這個招牌可以包辦所有工作負載。

Disaggregated inference 其實就是承認工作負載已經分裂

文章一直用「disaggregated AI inference platform」這個詞，聽起來很硬，其實意思很簡單：推理不同階段做的事不一樣，所以不需要同一種 silicon。

我喜歡這個講法，因為它跟我在 production 裡看到的一模一樣。retrieval 很吃記憶體，prompt preprocessing 很突發，generation 很吃延遲，安全過濾和 routing 自己也能卡半天。你如果把這些全綁在同一套架構上，系統會很容易講，操作起來卻很煩。

這篇真正的意思是，Cerebras 在往「多架構協調者」移動，而不是只賣一台很猛的機器。這比單純賣硬體更大一點，但也更難，因為它得證明自己能跟別家好好整合，不是只靠純度取勝。

我之前優化一個 multi-model assistant 時也遇到同樣問題。第一個錯誤是以為 model 本身是瓶頸，結果通常不是。真正的問題是每個 request 都走同一條路，明明請求形狀差很多。等我們把短互動查詢跟長分析工作分流，整個系統就便宜又好調。

實操寫法很直接：先把流量按 request type 畫出來，再按請求形狀分配硬體，不要按組織習慣分。長上下文摘要器不該跟低延遲 coding assistant 擠同一個 queue。你要一條簡單規則，就用這句：互動式請求走最快路，批次大上下文走最肥的路。

• 按 context length、latency target、output length 分類流量。
• 按主要瓶頸分配硬體，不要按部門分配。
• 保留 fallback path，避免單一 pool 變成單點故障。

如果你想看 vendor 背景，Cerebras 官方站在這：Cerebras Systems。AMD 官方站在這：AMD。Cerebras Cloud 之後怎麼接這套聯合方案，也值得盯。

OpenAI 和 AWS 比 AMD logo 更重要

這篇不是只把 AMD 拿出來講，它也把 Cerebras 之前跟 OpenAI、Amazon Web Services 的合作一起放進來。這點我覺得更有意思，因為它顯示 Cerebras 在做的是 distribution 和 integration 的網路，不只是列一排合作夥伴。

文內提到 OpenAI 合約價值超過 200 億美元，AWS 合作也已經帶來商業動能。這些都不是小事。它們在告訴我，Cerebras 想進的是 inference supply chain，不是只當一個有趣的硬體供應商。

翻成白話就是，AMD 不是策略本身，它只是策略的一塊。Cerebras 想變成那個讓推理工作負載落地的地方，只要你需要速度、規模、還有很奇怪的硬體配對，它都想接。合作夥伴越多，這個故事就越像真的。

我看過很多 infra 公司都走過這條路。真正活得久的，最後都不再賣「我的技術比較強」，而是賣「我的技術能塞進你的系統」。這句話很難假裝，因為它只有在整合真的跑起來時才成立。

實操上，如果你自己在做平台，不要把 partnership 當行銷素材。把它當 distribution channel 和 validation path。好的 partner 會讓你說出一句話：這個東西不用重寫就能接進你的 stack。說不出來，那多半只是 logo 交換。

競爭者不是背景板，Cerebras 得真的跑得動

來源也提到 CoreWeave 和 Broadcom 都是實打實的競爭者。這很合理。CoreWeave 正在跟 NVIDIA 一起猛擴基礎設施，Broadcom 也在吃很大的 AI semiconductor bookings。這不是一個可以靠單一巧思慢慢晃過去的市場。

這代表 Cerebras 需要每一個能拿的優勢。更好的硬體故事有用，更好的系統故事也有用。市場現在買的是實際 revenue、實際承諾、實際容量。文內說 Cerebras 2026 年第一季營收年增 94% 到 1.934 億美元，cloud 和其他服務營收年增 178%。這種數字比較像是能支撐擴張的跡象，不像純炒作。

我不覺得這場競爭是在比誰的架構圖比較漂亮。它是在比誰能用大家吃得下的價格和延遲，穩定供應有用的 inference capacity。CoreWeave 賭的是規模，Broadcom 賭的是 custom accelerators 和 bookings，Cerebras 賭的是 workload specialization。AMD 讓這個賭注變得更廣。

實操上，如果你在評估 vendor，我會直接問：你到底是為了 scale、custom silicon、general-purpose compute，還是 workload specialization？如果對方一句話講不清楚，多半就是什麼都想做，結果什麼都不夠像樣。

• 把 vendor 強項對回你的實際 workload mix。
• 不要只看單一 benchmark 就下單。
• 看 revenue quality，不要只看 headline growth。

還有一個數字我會記著：文內說 Cerebras 把 2026 core revenue guidance 提到 8.55 億到 8.65 億美元。我不會把它當勝利宣言，我會把它當證據：這家公司正在把架構變成可重複的商業需求，這才是難的那段。

如果是我，我會怎麼抄這套方法

如果我今天要設計一個 AI serving stack，我不會抄它的品牌，我會抄它的邏輯：把 request path 拆成幾段，讓每段跑在最適合的硬體上，然後把整條 pipeline 當成系統來量。

很多團隊最常犯的錯，是以為 model 就是產品。不是。產品是 response path。使用者不在乎哪顆 accelerator 做的，他只在乎答案有沒有夠快、夠便宜、夠能吃上下文。

這篇合作真正指向的是一種很務實的未來：基礎設施會被拆成專長。不是什麼很空泛的願景，我講的是那種很煩但會真的上線的拆法：一套管 intake，一套管 memory-heavy prep，一套管 generation，一套管 orchestration。

實操上你可以先做一個 traffic audit。把 request class、context size、latency target、cost per request 全部量出來，再反推 serving topology。你如果已經在 production 裡，先把一個塞爆的 queue 拆成兩個。光這一步，你會學到的東西就比再看一週 benchmark slide 多。

可抄的模板

# Workload-optimized AI inference plan

## Goal
Build an inference stack that splits prompt processing, context handling, and token generation across the best-fit hardware.

## Request classes
- Interactive chat / copilots: low latency, short-to-medium context
- Coding assistants: low latency, moderate context, high token output
- Long-context analysis: high throughput, large context windows
- Batch generation: cost-sensitive, throughput-first

## Routing rules
1. Send prompt ingestion and large-context assembly to the high-throughput front-end tier.
2. Send token generation to the low-latency generation tier.
3. Keep safety, retrieval, and post-processing as separate services.
4. Route by request shape, not by default queue.

## Metrics to track
- p50 latency
- p95 latency
- tokens per second
- tokens per second per watt
- cost per 1,000 tokens
- sustained throughput over 1 hour
- queue depth by request class

## Evaluation checklist
- Does the stack handle long context without slowing interactive traffic?
- Can the system keep generation latency low under sustained load?
- Is power usage acceptable at full utilization?
- Can the platform fail over if one hardware pool is saturated?
- Do we have separate SLAs for each request class?

## Deployment shape
- Front-end inference tier: prompt processing, context packing, retrieval assembly
- Generation tier: token emission, low-latency response serving
- Control plane: routing, observability, failover, policy enforcement

## Copy-ready positioning note
We do not buy one accelerator to solve every inference problem.
We match hardware to workload shape, then measure the whole path as a system.

這份模板最好用的地方，是它逼你把話題從 hype 拉回營運。這些合作最後能不能成，看的就是這裡：前段忙不忙、後段快不快、整體有沒有真的省到錢。如果前段卡住、後段很閒，那你至少知道問題在哪，不用再被漂亮簡報騙一次。

我會信的也就這個：不是合作名詞本身，而是它底下那個很務實的承認。

來源致謝：原始材料來自 Yahoo Finance 轉載 Zacks Research 的文章 finance.yahoo.com/technology/ai/articles/amd-partnership-strengthen-cerebras-ai-150400219.html。上面的拆解、觀點整理和模板是我自己的延伸，不是原文改寫。