[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-amd-helios-lets-cerebras-widen-inference-throughput-zh":3,"article-related-amd-helios-lets-cerebras-widen-inference-throughput-zh":30,"series-industry-9445e60a-6239-47b5-8ee8-d91db2484f0a":73},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"9445e60a-6239-47b5-8ee8-d91db2484f0a","amd-helios-lets-cerebras-widen-inference-throughput-zh","AMD+Helios 讓 Cerebras 先拆流量","\u003Cp data-speakable=\"summary\">以前一顆\u003Ca href=\"\u002Fnews\u002Fmicrosoft-azure-amd-ai-hpc-2026-zh\">晶片\u003C\u002Fa>包到底，現在把推理拆成前段吞吐和後段生成兩條路。\u003C\u002Fp>\u003Cp>我盯 Cerebras 很久了，老實說我一直卡在同一個問題：它老愛把故事講成「一顆晶片解決全部」。聽起來很爽，demo 也很漂亮，但真實推理流量根本不是這樣。有人只問一個短問題，有人丟超長上下文，還有人要低延遲、要吞吐、要成本，三個願望一次滿足。你如果硬把這些流量塞進同一條管線，最後通常不是跑得慢，是你根本不知道慢在哪。\u003C\u002Fp>\u003Cp>這次 AMD Helios 的合作把我的注意力拉回來了。我看到的不是一則漂亮的合作稿，而是 Cerebras 終於把話講白：推理基礎設施本來就不是單一加速器的題目，而是流量分流題。這種感覺我在自己搭模型服務時也踩過，前面 ingest、retrieval、context packing、generation 全混在一起，表面上很整齊，實際上就是一團難調的爛攤子。\u003C\u002Fp>\u003Cp>我這次拆解的來源是 Yahoo Finance 轉載 Zacks Research 的這篇：\u003Ca href=\"https:\u002F\u002Ffinance.yahoo.com\u002Ftechnology\u002Fai\u002Farticles\u002Famd-partnership-strengthen-cerebras-ai-150400219.html\">Can AMD Partnership Strengthen Cerebras' AI Infrastructure Leadership?\u003C\u002Fa>。文內提到 Cerebras 會在資料中心部署 AMD Helios，並在 2026 下半年透過 Cerebras Cloud 推出聯合方案；它還給了兩個很有用的數字：整合後平台可達到最高 5 倍的 tokens-per-second-per-watt，Cerebras 也把 2026 core revenue guidance 調到 8.55 億到 8.65 億美元。\u003C\u002Fp>\u003Ch2>Cerebras 現在賣的不是晶片，是流量分工\u003C\u002Fh2>\u003Cblockquote>AMD Helios 負責高吞吐的 prompt processing 和大上下文，Cerebras WSE 負責超低延遲的 token 生成。\u003C\u002Fblockquote>\u003Cp>翻譯一下就是，Cerebras 不再假裝一顆加速器能把推理全包。AMD 吃前段那坨寬而重的工作，Cerebras 吃後段那個要快吐 token 的工作。這比「我們更快」這種口號實在多了，因為它直接對準真實請求長什麼樣。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784966609381-x09e.png\" alt=\"AMD+Helios 讓 Cerebras 先拆流量\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我以前做長上下文 assistant 的 serving pipeline，也撞過同一堵牆。第一個 token 慢很煩，但更煩的是前面那串事情：prompt ingest、檢索、上下文拼接、還有那些看起來沒做事、其實在卡整體延遲的小停頓。等我把流程拆開，才發現 latency 不是一個數字，而是一串決策。\u003C\u002Fp>\u003Cp>實操上你可以這樣做：先不要畫一條「模型推理」的大直線，改成拆成 prompt processing、context handling、generation、post-processing 四段。每一段都問一次：這段最吃的是吞吐、延遲、記憶體，還是功耗？如果你現在還是「一個模型、一池 GPU、一個 queue」，你大概正在用錯方式買算力。\u003C\u002Fp>\u003Cul>\u003Cli>前段用高吞吐路徑處理 prompt ingest 和 context assembly。\u003C\u002Fli>\u003Cli>後段用低延遲路徑處理 token generation 和互動式回覆。\u003C\u002Fli>\u003Cli>每段分開量，不要把所有東西平均成一個 SLA。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>這也是為什麼這個 AMD 合作不是裝飾品。Cerebras 不是多掛一個 logo 而已，它是在說：推理基礎設施要按工作負載長相來配。這種說法比「我們有最快的東西」更有用，因為買 \u003Ca href=\"\u002Ftag\u002Fai-\">AI 基礎設施\u003C\u002Fa>的人現在買的不是最快，而是最不痛。\u003C\u002Fp>\u003Ch2>tokens-per-watt 才是這篇真正的重點\u003C\u002Fh2>\u003Cp>文內提到整合平台最高可達 Cerebras-only 方案的 5 倍 tokens-per-second-per-watt。這種數字我會認真看，因為它不是在比誰跑分好看，而是在講營運成本。\u003C\u002Fp>\u003Cp>tokens per second 很重要，但 tokens per watt 更直白。它逼你把吞吐放回真實世界：機櫃真的在跑時，這些 token 到底要燒多少電。我看過太多團隊開心地秀峰值吞吐，卻把電力、散熱、機櫃利用率晾在一邊。等財務來算帳，才發現最好的系統其實是最不會燒預算的那個。\u003C\u002Fp>\u003Cp>這裡的意思很簡單：Cerebras 和 AMD 想把 serving stack 做得更密、更省，不只是更大。每瓦能吐更多 token，你就有空間降價、拉毛利，或兩個一起做。現在 cloud AI pricing 壓力這麼大，這種指標比漂亮 demo 圖實在多了。\u003C\u002Fp>\u003Cp>實操上，我會叫你把 latency 和 throughput 以外的指標也塞進同一張表：功耗、機櫃密度、持續利用率。只要 vendor 說不出 sustained load 下會怎樣，我就會把它當成只會報峰值的簡報機器。\u003C\u002Fp>\u003Cul>\u003Cli>同時追 tokens\u002Fsec、tokens\u002Fsec\u002Fwatt、p95 latency。\u003C\u002Fli>\u003Cli>測 sustained performance，不要只看短 burst。\u003C\u002Fli>\u003Cli>把 power 和 cooling 算進 TCO。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>AMD 這邊也不是路人。它的 \u003Ca href=\"https:\u002F\u002Fwww.amd.com\u002Fen\u002Fproducts\u002Faccelerators\u002Finstinct.html\">Instinct\u003C\u002Fa> 跟 rack-scale 方向，讓 Cerebras 能把推理前半段接起來。Cerebras 還是 wafer-scale 的招牌沒錯，但它終於不用假裝這個招牌可以包辦所有工作負載。\u003C\u002Fp>\u003Ch2>Disaggregated inference 其實就是承認工作負載已經分裂\u003C\u002Fh2>\u003Cp>文章一直用「disaggregated AI \u003Ca href=\"\u002Ftag\u002Finference\">inference\u003C\u002Fa> platform」這個詞，聽起來很硬，其實意思很簡單：推理不同階段做的事不一樣，所以不需要同一種 silicon。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784966594555-v2im.png\" alt=\"AMD+Helios 讓 Cerebras 先拆流量\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我喜歡這個講法，因為它跟我在 production 裡看到的一模一樣。retrieval 很吃記憶體，prompt preprocessing 很突發，generation 很吃延遲，安全過濾和 routing 自己也能卡半天。你如果把這些全綁在同一套架構上，系統會很容易講，操作起來卻很煩。\u003C\u002Fp>\u003Cp>這篇真正的意思是，Cerebras 在往「多架構協調者」移動，而不是只賣一台很猛的機器。這比單純賣硬體更大一點，但也更難，因為它得證明自己能跟別家好好整合，不是只靠純度取勝。\u003C\u002Fp>\u003Cp>我之前優化一個 multi-model assistant 時也遇到同樣問題。第一個錯誤是以為 model 本身是瓶頸，結果通常不是。真正的問題是每個 request 都走同一條路，明明請求形狀差很多。等我們把短互動查詢跟長分析工作分流，整個系統就便宜又好調。\u003C\u002Fp>\u003Cp>實操寫法很直接：先把流量按 request type 畫出來，再按請求形狀分配硬體，不要按組織習慣分。長上下文摘要器不該跟低延遲 coding assistant 擠同一個 queue。你要一條簡單規則，就用這句：互動式請求走最快路，批次大上下文走最肥的路。\u003C\u002Fp>\u003Cul>\u003Cli>按 context length、latency target、output length 分類流量。\u003C\u002Fli>\u003Cli>按主要瓶頸分配硬體，不要按部門分配。\u003C\u002Fli>\u003Cli>保留 fallback path，避免單一 pool 變成單點故障。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>如果你想看 vendor 背景，Cerebras 官方站在這：\u003Ca href=\"https:\u002F\u002Fwww.cerebras.ai\u002F\">Cerebras Systems\u003C\u002Fa>。AMD 官方站在這：\u003Ca href=\"https:\u002F\u002Fwww.amd.com\u002F\">AMD\u003C\u002Fa>。Cerebras Cloud 之後怎麼接這套聯合方案，也值得盯。\u003C\u002Fp>\u003Ch2>OpenAI 和 AWS 比 AMD logo 更重要\u003C\u002Fh2>\u003Cp>這篇不是只把 AMD 拿出來講，它也把 Cerebras 之前跟 \u003Ca href=\"https:\u002F\u002Fopenai.com\u002F\">OpenAI\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002F\">Amazon Web Services\u003C\u002Fa> 的合作一起放進來。這點我覺得更有意思，因為它顯示 Cerebras 在做的是 distribution 和 integration 的網路，不只是列一排合作夥伴。\u003C\u002Fp>\u003Cp>文內提到 \u003Ca href=\"\u002Ftag\u002Fopenai\">OpenAI\u003C\u002Fa> 合約價值超過 200 億美元，AWS 合作也已經帶來商業動能。這些都不是小事。它們在告訴我，Cerebras 想進的是 inference supply chain，不是只當一個有趣的硬體供應商。\u003C\u002Fp>\u003Cp>翻成白話就是，AMD 不是策略本身，它只是策略的一塊。Cerebras 想變成那個讓推理工作負載落地的地方，只要你需要速度、規模、還有很奇怪的硬體配對，它都想接。合作夥伴越多，這個故事就越像真的。\u003C\u002Fp>\u003Cp>我看過很多 infra 公司都走過這條路。真正活得久的，最後都不再賣「我的技術比較強」，而是賣「我的技術能塞進你的系統」。這句話很難假裝，因為它只有在整合真的跑起來時才成立。\u003C\u002Fp>\u003Cp>實操上，如果你自己在做平台，不要把 partnership 當行銷素材。把它當 distribution channel 和 validation path。好的 partner 會讓你說出一句話：這個東西不用重寫就能接進你的 stack。說不出來，那多半只是 logo 交換。\u003C\u002Fp>\u003Ch2>競爭者不是背景板，Cerebras 得真的跑得動\u003C\u002Fh2>\u003Cp>來源也提到 CoreWeave 和 Broadcom 都是實打實的競爭者。這很合理。CoreWeave 正在跟 \u003Ca href=\"\u002Ftag\u002Fnvidia\">NVIDIA\u003C\u002Fa> 一起猛擴基礎設施，Broadcom 也在吃很大的 AI semiconductor bookings。這不是一個可以靠單一巧思慢慢晃過去的市場。\u003C\u002Fp>\u003Cp>這代表 Cerebras 需要每一個能拿的優勢。更好的硬體故事有用，更好的系統故事也有用。市場現在買的是實際 revenue、實際承諾、實際容量。文內說 Cerebras 2026 年第一季營收年增 94% 到 1.934 億美元，cloud 和其他服務營收年增 178%。這種數字比較像是能支撐擴張的跡象，不像純炒作。\u003C\u002Fp>\u003Cp>我不覺得這場競爭是在比誰的架構圖比較漂亮。它是在比誰能用大家吃得下的\u003Ca href=\"\u002Fnews\u002Fbitcoin-price-page-market-view-zh\">價格\u003C\u002Fa>和延遲，穩定供應有用的 inference capacity。CoreWeave 賭的是規模，Broadcom 賭的是 custom accelerators 和 bookings，Cerebras 賭的是 workload specialization。AMD 讓這個賭注變得更廣。\u003C\u002Fp>\u003Cp>實操上，如果你在評估 vendor，我會直接問：你到底是為了 scale、custom silicon、general-purpose compute，還是 workload specialization？如果對方一句話講不清楚，多半就是什麼都想做，結果什麼都不夠像樣。\u003C\u002Fp>\u003Cul>\u003Cli>把 vendor 強項對回你的實際 workload mix。\u003C\u002Fli>\u003Cli>不要只看單一 benchmark 就下單。\u003C\u002Fli>\u003Cli>看 revenue quality，不要只看 headline growth。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>還有一個數字我會記著：文內說 Cerebras 把 2026 core revenue guidance 提到 8.55 億到 8.65 億美元。我不會把它當勝利宣言，我會把它當證據：這家公司正在把架構變成可重複的商業需求，這才是難的那段。\u003C\u002Fp>\u003Ch2>如果是我，我會怎麼抄這套方法\u003C\u002Fh2>\u003Cp>如果我今天要設計一個 AI serving stack，我不會抄它的品牌，我會抄它的邏輯：把 request path 拆成幾段，讓每段跑在最適合的硬體上，然後把整條 pipeline 當成系統來量。\u003C\u002Fp>\u003Cp>很多團隊最常犯的錯，是以為 model 就是產品。不是。產品是 response path。使用者不在乎哪顆 accelerator 做的，他只在乎答案有沒有夠快、夠便宜、夠能吃上下文。\u003C\u002Fp>\u003Cp>這篇合作真正指向的是一種很務實的未來：基礎設施會被拆成專長。不是什麼很空泛的願景，我講的是那種很煩但會真的上線的拆法：一套管 intake，一套管 memory-heavy prep，一套管 generation，一套管 orchestration。\u003C\u002Fp>\u003Cp>實操上你可以先做一個 traffic audit。把 request class、context size、latency target、cost per request 全部量出來，再反推 serving topology。你如果已經在 production 裡，先把一個塞爆的 queue 拆成兩個。光這一步，你會學到的東西就比再看一週 \u003Ca href=\"\u002Ftag\u002Fbenchmark\">benchmark\u003C\u002Fa> slide 多。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cpre>\u003Ccode># Workload-optimized AI inference plan\n\n## Goal\nBuild an inference stack that splits prompt processing, context handling, and token generation across the best-fit hardware.\n\n## Request classes\n- Interactive chat \u002F copilots: low latency, short-to-medium context\n- Coding assistants: low latency, moderate context, high token output\n- Long-context analysis: high throughput, large context windows\n- Batch generation: cost-sensitive, throughput-first\n\n## Routing rules\n1. Send prompt ingestion and large-context assembly to the high-throughput front-end tier.\n2. Send token generation to the low-latency generation tier.\n3. Keep safety, retrieval, and post-processing as separate services.\n4. Route by request shape, not by default queue.\n\n## Metrics to track\n- p50 latency\n- p95 latency\n- tokens per second\n- tokens per second per watt\n- cost per 1,000 tokens\n- sustained throughput over 1 hour\n- queue depth by request class\n\n## Evaluation checklist\n- Does the stack handle long context without slowing interactive traffic?\n- Can the system keep generation latency low under sustained load?\n- Is power usage acceptable at full utilization?\n- Can the platform fail over if one hardware pool is saturated?\n- Do we have separate SLAs for each request class?\n\n## Deployment shape\n- Front-end inference tier: prompt processing, context packing, retrieval assembly\n- Generation tier: token emission, low-latency response serving\n- Control plane: routing, observability, failover, policy enforcement\n\n## Copy-ready positioning note\nWe do not buy one accelerator to solve every inference problem.\nWe match hardware to workload shape, then measure the whole path as a system.\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這份模板最好用的地方，是它逼你把話題從 hype 拉回營運。這些合作最後能不能成，看的就是這裡：前段忙不忙、後段快不快、整體有沒有真的省到錢。如果前段卡住、後段很閒，那你至少知道問題在哪，不用再被漂亮簡報騙一次。\u003C\u002Fp>\u003Cp>我會信的也就這個：不是合作名詞本身，而是它底下那個很務實的承認。\u003C\u002Fp>\u003Cp>來源致謝：原始材料來自 Yahoo Finance 轉載 Zacks Research 的文章 \u003Ca href=\"https:\u002F\u002Ffinance.yahoo.com\u002Ftechnology\u002Fai\u002Farticles\u002Famd-partnership-strengthen-cerebras-ai-150400219.html\">finance.yahoo.com\u002Ftechnology\u002Fai\u002Farticles\u002Famd-partnership-strengthen-cerebras-ai-150400219.html\u003C\u002Fa>。上面的拆解、觀點整理和模板是我\u003Ca href=\"\u002Fnews\u002Fanthropic-kimik3-pr-fires-back-zh\">自己的\u003C\u002Fa>延伸，不是原文改寫。\u003C\u002Fp>","我拆 Cerebras 怎麼把 AMD Helios 接進 WSE，順手給你一份可直接套用的推理分流模板。","finance.yahoo.com","https:\u002F\u002Ffinance.yahoo.com\u002Ftechnology\u002Fai\u002Farticles\u002Famd-partnership-strengthen-cerebras-ai-150400219.html",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1784966609381-x09e.png","industry","zh","ce8922d6-fb09-4b01-b4da-5e890ca0a9ce",[17,18,19,20,21],"Cerebras","AMD Helios","WSE","inference routing","tokens per watt",[23,24,25],"Cerebras 這次是在賣推理分流，不是在賣單顆晶片神話。","tokens-per-second-per-watt 比單看吞吐更接近真實營運成本。","把推理拆成前段與後段，再按 workload 配硬體，才是可落地的做法。",0,"2026-07-25T08:02:52.678031+00:00","2026-07-25T08:02:52.662+00:00","659d9017-0423-4276-a5f6-9ee0fec4c042",{"tags":31,"relatedLang":32,"relatedPosts":36},[],{"id":15,"slug":33,"title":34,"language":35},"amd-helios-lets-cerebras-widen-inference-throughput-en","AMD+Helios lets Cerebras widen inference throughput","en",[37,43,49,55,61,67],{"id":38,"slug":39,"title":40,"cover_image":41,"image_url":41,"created_at":42,"category":13},"811eab3e-0105-455c-b196-83d77bb29e52","google-q2-2026-results-ai-spend-story-zh","Google Q2 2026：AI支出已成估值主軸，不再只是搜尋故事","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785033163241-3n0s.png","2026-07-26T02:32:19.848016+00:00",{"id":44,"slug":45,"title":46,"cover_image":47,"image_url":47,"created_at":48,"category":13},"8a081a75-f194-4e1c-9289-a36ac221f048","ai-regulation-india-business-risk-2026-zh","印度 AI 監管已成商業風險","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785031373528-ak4r.png","2026-07-26T02:02:33.344117+00:00",{"id":50,"slug":51,"title":52,"cover_image":53,"image_url":53,"created_at":54,"category":13},"af446384-5a3b-4675-9df8-8797809f33fd","europe-should-standardise-ai-act-harmonised-rules-zh","歐洲該用統一技術標準落實 AI Act","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785029576170-tlby.png","2026-07-26T01:32:30.58516+00:00",{"id":56,"slug":57,"title":58,"cover_image":59,"image_url":59,"created_at":60,"category":13},"57d808f5-6a9c-4577-96c9-31ea907879ea","amd-anthropic-2gw-ai-capacity-deal-zh","AMD 與 Anthropic 的 2GW 交易，重寫 AI 供應","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785027761252-4vbd.png","2026-07-26T01:02:21.669601+00:00",{"id":62,"slug":63,"title":64,"cover_image":65,"image_url":65,"created_at":66,"category":13},"53d12771-e48a-42dd-a6ef-897634324360","openai-anthropic-dual-dominance-google-falls-behind-zh","OpenAI與Anthropic已進入雙雄時代，谷歌跌出第一梯隊","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785025977106-44rp.png","2026-07-26T00:32:30.875959+00:00",{"id":68,"slug":69,"title":70,"cover_image":71,"image_url":71,"created_at":72,"category":13},"3bc90ce2-80ef-4233-a9bb-a0476f2c606a","system-design-interviews-5-core-ideas-zh","系統設計面試先懂這 5 個核心觀念","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1785007970878-aujo.png","2026-07-25T19:32:26.369407+00:00",[74,79,84,89,94,99,104,109,114,119],{"id":75,"slug":76,"title":77,"created_at":78},"ee073da7-28b3-4752-a319-5a501459fb87","ai-in-2026-what-actually-matters-now-zh","2026 AI 真正重要的事","2026-03-26T07:09:12.008134+00:00",{"id":80,"slug":81,"title":82,"created_at":83},"83bd1795-8548-44c9-9a7e-de50a0923f71","trump-ai-framework-power-speech-state-preemption-zh","川普 AI 框架瞄準電力、言論與州權","2026-03-26T07:12:18.695466+00:00",{"id":85,"slug":86,"title":87,"created_at":88},"ea6be18b-c903-4e54-97b7-5f7447a612e0","nvidia-gtc-2026-big-ai-announcements-zh","NVIDIA GTC 2026 重點拆解","2026-03-26T07:14:26.62638+00:00",{"id":90,"slug":91,"title":92,"created_at":93},"4bcec76f-4c36-4daa-909f-54cd702f7c93","claude-users-spreading-out-and-getting-better-zh","Claude 用戶更分散，也更會用","2026-03-26T07:22:52.325888+00:00",{"id":95,"slug":96,"title":97,"created_at":98},"bd903b15-2473-4178-9789-b7557816e535","openclaw-raises-hard-question-for-ai-models-zh","OpenClaw 逼問 AI 模型價值","2026-03-26T07:24:54.707486+00:00",{"id":100,"slug":101,"title":102,"created_at":103},"eeac6b9e-ad9d-4831-8eec-8bba3f9bca6a","gap-google-gemini-checkout-fashion-search-zh","Gap 把結帳搬進 Gemini","2026-03-26T07:28:23.937768+00:00",{"id":105,"slug":106,"title":107,"created_at":108},"0740e53f-605d-4d57-8601-c10beb126f3c","google-pushes-gemini-transition-to-march-2026-zh","Google 把 Gemini 轉換延到 2026 年 3…","2026-03-26T07:30:12.825269+00:00",{"id":110,"slug":111,"title":112,"created_at":113},"e660d801-2421-4529-8fa9-86b82b066990","metas-llama-4-benchmark-scandal-gets-worse-zh","Meta Llama 4 分數風波又擴大","2026-03-26T07:34:21.156421+00:00",{"id":115,"slug":116,"title":117,"created_at":118},"183f9e7c-e143-40bb-a6d5-67ba84a3a8bc","accenture-mistral-ai-sovereign-enterprise-deal-zh","Accenture 攜手 Mistral AI 賣主權 AI","2026-03-26T07:38:14.818906+00:00",{"id":120,"slug":121,"title":122,"created_at":123},"191d9b1b-768a-478c-978c-dd7431a38149","mistral-ai-faces-its-hardest-year-yet-zh","Mistral AI 迎來最硬的一年","2026-03-26T07:40:23.716374+00:00"]