Strands Decider 解讀：Amazon 自報工單降本 98%，便宜在哪裡？（2026）

2026 年 11 月 9 日，Amazon 工程師 Carr Onstott、Mehul Jaiswal 與 Strands Agents 團隊在官方部落格發布了〈Amazon saves millions by replacing Sonnet 4.6 with Strands Decider〉，說明如何用 Strands Decider 接替 Claude Sonnet 4.6，處理內部工單標籤。作者估算模型成本降低約 98%。這個案例值得讀，因為它問了一個很實際的問題：一項工作若只需要選出類別，還需要每次生成一段答案嗎？

接下來先看系統究竟改了什麼，再重算成本與時間，最後判斷哪些部署經驗值得帶走。先把範圍說清楚：這是公司對自己工作負載的部署報告；內部分類品質與流量，仍需依作者敘述理解。

一、Strands Decider 換掉的是生成步驟，也改了輸入

原本的任務，是把各種內部請求分進 20 個類別。Sonnet 路徑讀取較長的系統提示詞，再輸出 JSON；新路徑把工單與候選類別交給決策模型，取得各選項分數及信心。作者先試 2B，再改用 Gemma 4 系列的 E4B，不能把本案的成績直接寫成「2B 模型擊敗 Sonnet」。

這個機制可以在官方架構說明中核對：模型沿用語言模型的主幹，把生成文字的輸出頭換成替選項評分的 pointer head。它像讀完申請單後，直接指向某個資料夾；應用程式再把結果寫回工單。省下逐字生成，不代表省掉理解輸入的計算。

部署同時重寫了類別描述。作者把每類縮成一兩句條件，加上「none」候選；為了配合此次採用的 4,096 Token 視窗，長工單還會捨棄最舊留言。所以本案比較的是兩套輸入、輸出與服務方式不同的系統。若要分辨改善來自哪裡，還應測試舊模型搭配相同精簡描述，以及同樣截斷策略的結果。

模型並非在這篇文章發布當天才出現。官方介紹文日期為 2026 年 10 月 1 日；E4B 模型卡的首發紀錄為 10 月 9 日，Gemma 4 家族介紹文則在 10 月 15 日發布。11 月這則消息的新意是實際部署經驗。

二、98% 怎麼算？先認清 Token 帳與 GPU 時間帳

以下金額與平均呼叫時間來自原文，均限於作者描述的設定。原文列出的 Sonnet 單價，與查閱時的 Anthropic 定價文件所列 Sonnet 4.6 基本輸入／輸出費率一致；這並不獨立證實 Amazon 的實際帳單。

每張工單的比較項目	Sonnet 4.6 路徑	Strands Decider E4B 路徑
輸入／輸出 Token	6,554／170	2,009／1
平均呼叫時間（作者報告）	4,215 毫秒	897 毫秒
估算模型成本	約 US$0.0222	約 US$0.0005
每百萬張估算成本	約 US$22,200	約 US$500

Sonnet 的算式是 6,554 × 3 ÷ 1,000,000 ＋ 170 × 15 ÷ 1,000,000 ＝ US$0.022212。拿約 US$0.0005 比較，降幅約 97.75%，四捨五入就是 98%；平均呼叫時間則縮短約 78.7%。這些算式可核對，原始流量與量測結果仍是作者提供。

Decider 不是照上表的 Token 數收費。作者用 SageMaker ml.g5.xlarge，並以每小時 US$1.408 估算，單機每個請求約 640 毫秒。若一台持續處理，每小時約 5,625 張，每百萬張約 US$250；保留突發流量餘裕後，作者估為約 US$500。640 毫秒的單機處理數字，與上表 897 毫秒的平均呼叫時間，應分開讀。

把公式改寫，差異就清楚了：單張基礎服務成本 ＝ 每小時實例費用 ÷ 每小時實際處理張數。依原文單價、假設整小時維持一台且沒有其他費用，每小時只有 100 張時就是 US$0.01408，1,000 張時是 US$0.001408。這是示意重算，說明GPU 忙不忙，會直接改變省多少。

原文的費用比較排除了 Lambda；要決定是否遷移，還得加上佇列、監控、儲存、維運與錯誤返工。每百萬張依兩個約數相減可省 US$21,700，若要一年省到 US$200 萬，便需要約 9,217 萬張的相同流量與單位差額。這是條件式推算，不能當成已核實的年度節省金額。

三、原文延遲圖的證據界線：公開程式碼寫了合成佔位

這裡有一項需要特別區分的材料。原文說 Lambda 平均執行時間降低 74%，但其公開嵌入圖表頁的 JavaScript 註解，把資料標為依參考 CloudWatch 截圖合成的佔位內容。

PLACEHOLDER: synthesized to match the reference CloudWatch screenshot.

中文：佔位資料：合成出與參考 CloudWatch 截圖相符的資料。

Strands Agents，該嵌入頁的程式碼註解

程式接著用固定種子的亂數、預設曲線與尖峰產生資料。圖內顯示約 3,312 毫秒到 748 毫秒，重算約下降 77.4%，也和圖上固定的 74% 標示不同。因此這條公開曲線不能用來獨立驗證真實流量，更不能拿它替 74% 背書。這項缺口不等於整個部署敘述為假；它表示現有可見圖表與原始監控紀錄之間，還隔著一層需要補齊的證據。

同樣要避免把 Lambda 執行時間和模型呼叫時間混為一談。兩者測量邊界不同；即使都有改善，也應各自提供時間範圍、樣本數與分位數，才適合判斷尖峰流量或慢請求是否一起變好。

四、品質要怎麼對帳？公開模型成績和內部工單各有考卷

作者說，調整信心門檻後，E4B 在另一組內部工單上勝過正式環境的 Sonnet。要把這句話升級成可比較的品質結論，還需要測試集大小、各類錯誤、低信心未套標比例，以及人工判定規則。尤其若低信心案件被留下，應同時公布「處理多少」與「處理得多準」。

公開的 E4B 模型卡提供了另一份可讀材料：在 4,096 視窗的 JevBench 公開題集，作者記錄答對 187／231 題。這是模型發布者的公開評估，題目也不同，不能替 Amazon 私有工單補出等效品質。模型卡還明確提醒，信心校準來自保留的短分類任務，應在自己的流量上量測門檻。

例如，系統把一般容量請求分錯一次，和把安全事件漏分一次，代價可能完全不同。若只報整體正確率，常見類別就可能蓋住少見但昂貴的錯誤。我會優先看每類召回、錯誤代價、人工接手率，以及長工單截掉最舊留言後的退步案例。

作者另報告：同樣內容僅改 JSON 鍵順序，部分輸出機率可移動到 0.19，因此固定排序。這是該團隊的觀察，不能推廣成所有模型都會出現相同幅度；值得採取的動作，是把序列化方式、選項順序與版本一起固定，再測擾動，而非只記模型名稱。

五、Strands Decider 部署最值得借用的，是雙軌與回退

We didn’t want to flip a switch and hope.

中文：我們不想只是切換開關，然後寄望一切順利。

Carr Onstott、Mehul Jaiswal 與 Strands Agents 團隊，原文

原文用 AppConfig 控制三種狀態：BEDROCK 由 Sonnet 單獨處理；DUAL 兩邊並行，仍套用 Sonnet 的標籤並記錄差異；DECIDER 才正式換用新路徑。作者說回退是約 45 秒的設定變更；這是他們的系統經驗，自己的環境仍需演練。

雙軌思路也有獨立的官方操作材料可參照：SageMaker Shadow Tests 文件說明如何複製正式請求給候選版本，並讓正式版本繼續回應。這份文件支持影子測試的機制，不是對本案內部成效的背書；原文採用的是應用層的 AppConfig／Lambda 分流。

實作時，兩邊一致只能證明一致，還不能證明一起答對。除了集中看分歧案例，也要抽查一致案例，並把流量尖峰、罕見類別、長工單與拒絕套標納入。回退則至少驗三件事：設定生效、佇列可續跑、重試不會重複寫標籤。

六、AlphaLab 的判讀：省錢來自任務邊界，遷移靠完整帳

我同意：固定選項值得擁有專門的決策路徑

把生成式模型放進每個節點，開發時很方便；但上線後，很多節點可能只剩固定規則下的選擇。若語意判斷仍有價值、結果又容易驗收，專門決策路徑值得測。這個案例的方向合理：讓能力、輸出形式與任務需求對齊。

若分類還必須附上理由、候選規則常改，或很舊的留言會決定正確類別，就把這些需求也放進考卷。需要第二個模型補解釋、重新校準門檻，或多次讀取長文時，合併後的品質與帳單才是比較對象。

我存疑：98% 的基準能否代表你今天的替代選擇

本文支持測試這個方向，卻不會只安排 Sonnet 與 E4B 兩個選手。scikit-learn 官方文字分類範例提供稀疏文字特徵與多種分類器的比較方法；這證明傳統分類基準可建立，不證明它在本案必勝。依資料情況，把規則、傳統分類器、較便宜的生成模型與決策模型放到同一份考卷，才知道額外複雜度買到了什麼。

另一個問題是，把標籤描述精簡後，原來的生成模型能省多少？真正可行的選擇，也可能是大部分案件走便宜路徑，困難案件才升級。若升級比例、人工費用或維運負擔太高，漂亮的單次推論數字就未必能轉成總成本優勢。

下一步：挑一個分類節點，先設定留下它的條件

先挑一項穩定、可回查的分類工作，用去識別且獲授權的代表樣本建立答案本。為每類錯誤訂代價，寫下可接受的未套標比例、慢請求時間與總成本；再用同一份輸入比較候選路徑。這些門檻是你要先決定的驗收條件，不能由新模型的漂亮結果反推。

離線通過後，小範圍雙軌，人工核對分歧並抽查一致，最後才逐步接管。關心如何把題目、評分與停止條件串起來，可以接著讀 最小 Agent Harness。值得帶走的原則，是先證明這項決策能交付，再計算每個合格結果的完整成本。