Fable 停用逼你把模型收回來

Anthropic 停用 Fable 後，我拆出團隊該怎麼把模型依賴從供應商手上收回來，並附可直接複製的審查模板。

我這陣子一直在看大家怎麼把 hosted model 接進產品，老實說，前面都很順。串 API、調 prompt、跑 eval，數字也還看得過去。可我心裡一直卡一個點：你做得越像樣，就越像把核心能力交給別人保管。平常沒事時這叫效率；一旦供應商改規則、改價格、改可用區域，這就不是效率了，這叫被人掐住脖子。我最不爽的就是，很多團隊直到出事才發現自己根本沒留退路。

這次 Anthropic 的 Fable 停用把這件事直接攤開來看。它不是單純的產品下架，而是讓大家重新面對一個很土但很真實的問題：你到底是在用模型，還是在租模型？我讀這件事時主要對照 CNBC 的報導，還有 Anthropic 的 官方網站、Satya Nadella 的 X，以及 OpenRouter 的使用趨勢。真正值得拆的，不是戲劇性，而是下一步架構要怎麼改。

模型會消失，產品就只是租來的

Anthropic announced it had pulled access to its Fable 5 and Mythos 5 models to comply with an export control directive from the U.S. government that cited “national security authorities.”

翻譯一下就是：如果你的產品建立在封閉模型上，你的產品命運其實握在別人政策手上。不是只有 uptime，不是只有帳單，連能不能繼續用都不是你說了算。這種依賴最煩的地方在於，它平常不會炸給你看。你的服務照跑、前端照開、監控全綠，直到某個關鍵能力突然不見，整個流程才像被拔掉一塊骨頭。

CNBC 的敘述很直接，Anthropic 是直接把 Fable 5 和 Mythos 5 的存取關掉，其他模型還在。這個細節很重要，因為它告訴我風險不是「整個 vendor 掛掉」，而是「你最依賴的那一塊被單獨切掉」。這種情況在架構審查時最容易被忽略，因為系統表面上還活著，只有某條關鍵路徑在默默失血。

我自己碰過類似的事。之前有個客服摘要流程，模型換檔後沒有真的停機，但定價變了，成本模型整個歪掉。功能還在，可是商業上已經不好用了。這就是我現在最在意的點：依賴不只是技術問題，還是合約問題、成本問題、甚至風險問題。

實操寫法很簡單，先不要談優化，先做依賴盤點：

• 把每一次 model call 對應到哪個業務流程寫出來。
• 標記哪些流程一旦模型被停用就會壞掉。
• 把「好用」和「核心」分開，不要混成一團。

如果模型一斷，你的營收就停，那你需要的是備援，不是更漂亮的 prompt。

開源不是信仰，是退出門

An open-source model can be downloaded, run on a company’s own infrastructure, and customized for its data and needs.

也就是說，開源模型真正有價值的地方，不是情懷，是你有地方可退。你可以把模型放進自己的環境，自己控權限、自己控版本、自己控部署節奏。這不是要你一開始就全自建，而是你至少要有一條離開供應商的路。沒有這條路，所謂的技術選型其實只是把風險包裝得比較好看。

我不會把 open source 講成神主牌。自己跑模型一定有代價：infra、維運、監控、升級、效能調校，通通都要錢。可問題是，很多團隊把「我們之後再換」當成策略，結果真的要換時，prompt 已經漂了、eval 已經陳舊了、工具呼叫也綁死了。那時候才是最貴的。

這次事件讓我更確定一件事：如果 AI 功能碰到敏感資料、客戶流程、或是公司會拿來算錢的核心邏輯，就不能只看 hosted 版本。你至少要有一個 self-hostable 候選方案，先能跑，再談好不好看。

我會這樣落地：

• 挑一個你能自己部署的模型家族，不要只看榜單。
• 同一個工作流，hosted 和 self-hosted 都跑一次。
• 比較品質差多少、成本差多少、控制權差多少。

你會發現，當風險夠大時，控制權本身就是一種性能指標。

真正的 lock-in 不是 API，是習慣

“The last thing any of us want is a world where every company across every sector is ceding value to a few models that eat everything they see,” Satya Nadella wrote on X.

這句話有點誇張，但我懂他在講什麼。大家以為 lock-in 是 API key 或合約條款，其實更可怕的是團隊開始習慣某個模型的脾氣。prompt 會跟著它調，guardrail 會跟著它調，產品邏輯也會跟著它調。最後不是你綁住模型，是模型綁住你的設計方式。

翻譯一下就是，切換成本很多時候不是技術成本，而是心理成本。團隊會開始問：「怎麼改最不會壞？」而不是「哪個模型最適合這件事？」這差很多。前者是在維持現狀，後者才是在做選型。

我在 agent workflow 上看過這種黏性特別重。你一旦把工具呼叫、輸出格式、錯誤重試都調成某個模型的習慣，換 vendor 就不是換 endpoint 而已，是整個行為邊界要重做。這也是為什麼我現在更偏向把模型差異收斂在 adapter，而不是讓整個產品直接吃 vendor 的脾氣。

實際上可以這樣做：

• 把 prompt、tool schema、輸出格式都版本化。
• 把模型特有的邏輯包進 adapter，不要散在各處。
• 不要讓整個產品都依賴同一個供應商的怪癖。

如果你能換模型而不用重寫 app，才算真的有選擇權。

便宜不是省錢，是把模型分層

“The era of token maxing is over,” Yash Patel said.

這句我聽了直接笑出來，因為它很粗，但也很準。意思很簡單：大家不想再為每一個 token 都付高價了，尤其是那些其實不需要頂級模型的工作。市場成熟之後，預算會逼著你誠實面對一件事：不是每個步驟都值得用最貴的模型。

CNBC 裡提到的重點是，企業現在在找 better, cheaper, faster models。這不是採購部門在碎念，這會直接改架構。你一旦接受「不是所有任務都要最強模型」，就可以把工作流拆層：便宜模型做分類、中階模型做草稿、昂貴模型只處理真正難的推理。

我自己重構過幾次這種系統。第一版通常很浪費，因為大家怕出錯，乾脆全部丟給最強模型。等帳單來了，大家又突然很懂 routing。這種劇本我看太多次了。

可以直接這樣做：

• 先做 task router，再談擴量。
• 高頻、低風險步驟用小模型或開源模型。
• 把昂貴模型保留給真正卡關的部分。

如果你的架構不能在成本上優雅降級，那它不是 production-ready，它只是 demo 長得比較像真的。

中國開源模型受歡迎，不是偶然

Models from DeepSeek, Tencent, Xiaomi, and MiniMax all rank among OpenRouter’s most-used this month, even against closed competitors.

這段很值得台灣團隊注意。CNBC 提到，投資人押注這次停用事件會把需求推向 open models，而 DeepSeek、Tencent、Xiaomi、MiniMax 這些名字也真的在使用榜上往前。這不是口號，這是使用者行為。人最後還是會選好用、可得、便宜的東西，不太會因為品牌故事就一直死撐。

翻成工程語言就是：如果模型夠好、夠便宜、夠容易跑，團隊就會用。你可以嘴上說自己偏好某家大廠，但真正在 work queue 裡被呼叫的，通常是那個最順手、最能交差的方案。這跟基礎設施工具一樣，最後贏的常常不是最會講故事的，而是最少讓你加班的。

我會建議團隊把這件事當成選型而不是立場。不要先問「哪個陣營比較對」，先問「哪個模型在我們自己的資料和任務上過關」。OpenRouter 這類平台的價值就在這裡，它反映的是實際呼叫行為，不是誰在社群上喊得最大聲。

落地方式：

• 建立一份自己的 benchmark 集合，不要只看公開榜單。
• 把多語言、多模態、領域任務分開測。
• 模型沒打過你的 eval 之前，別先下結論。

最強的模型不是聲量最大那個，是最符合你工作負載那個。

我會先問退出策略，不先問 prompt

如果是我在看一個 AI stack，我現在第一個問題不會是 prompt 寫得漂不漂亮，而是：你怎麼退出？這個問題很土，但很有效。因為你只要開始問退出策略，整個團隊的思考就會從「怎麼把模型用滿」轉成「怎麼不要被模型綁死」。

這代表架構要先設計可攜性。模型最好放在內部介面後面，prompt 和 eval 進版控，provider-specific 的東西全部收斂到 adapter。再來就是至少保留一個可 self-host 的候選模型，哪怕一開始不是主力，也要能在緊急時接手。

我也會把對外承諾講清楚：我們不把任何外部模型當成單點故障。這句話聽起來像內控文件，但其實很實用。因為它逼你去做 fallback、做測試、做切換演練，而不是把風險藏在簡報裡。

我會用這份檢查表：

• 我們能不能在自己的 infra 上跑 fallback 模型？
• 換供應商時，產品要改多少 code？
• 哪些 workflow 最怕政策、區域、價格變動？
• 我們有沒有同時比較 hosted、open、self-hosted 的 eval？

如果大多數答案都是否，那這個 stack 其實比看起來脆很多。

可抄的模板

# AI 模型依賴審查模板（可直接貼進 Notion / GitHub / Confluence）

## 1) 模型清單
- Provider:
- Model name:
- 用途:
- 資料敏感度:
- 業務重要性:
- Fallback model:
- 是否可 self-host: yes/no

## 2) 風險盤點
- 如果存取被撤銷，哪些流程會壞？
- 如果價格翻倍，哪些流程會先爆？
- 如果模型行為改變，哪些輸出會失真？
- 哪些地區 / 政策會影響可用性？

## 3) 架構規則
- 模型必須放在內部介面後面。
- prompt 必須進版控。
- tool schema 必須版本化。
- provider-specific 邏輯只能放在 adapter。
- 高頻低風險任務優先走便宜模型。
- 真正困難的任務才用高價模型。

## 4) 評估計畫
- Hosted benchmark:
- Open benchmark:
- Self-hosted benchmark:
- Accuracy target:
- Latency target:
- Cost target:
- 要監控的失敗類型:

## 5) 退出策略
- Primary provider:
- Backup provider:
- Self-hosted deployment plan:
- Model replacement RTO:
- Prompt / eval artifacts RPO:
- Owner:

## 6) 決策
- 保持 hosted:
- 增加 fallback:
- 轉向 open / self-hosted:
- 下次重評日期:

## 7) 可直接貼到團隊規範
我們不把任何外部模型當成單點故障。
每個 production AI workflow 都必須有文件化 fallback。
任何使用敏感或 mission-critical 資料的 workflow，都必須有 self-hostable 路徑，或經過明確例外核准。

這份模板的價值不是叫你反供應商，而是叫你少一點驚嚇。你可以拿它去做架構審查、採購審查、甚至 incident postmortem。它會把原本很空泛的「我們應該更有韌性」變成可以逐條回答的清單。

我這篇的拆解主要是從 CNBC 的 Anthropic’s Fable shutdown is a big moment for open-source AI 來的，外加我自己對模型依賴、架構切分與 fallback 設計的整理。原始事實、引述與人物名稱來自來源文章；模板、判讀方式和實操建議是我另外整理出來的。