有人主張全部私有化，帳單變成機房和運維；有人主張全部商業API，合同和配方進了提示詞。兩端都貴，只是貴法不同。正確切法是場景矩陣：數據敏感到不能出域的，走本地開源模型；要最強推理且可脫敏的，走商業API；要現場低時延的，本地優先。組合使用，而不是選邊站。
先給場景打兩個標籤：敏感度、時延。標籤決定路由，模型廠商只是執行層。
一張路由表就夠起步
內部規章、客戶名單、成本、配方：本地，默認不出域。營銷文案、公開資料摘要：商業API，輸入先脫敏。產線助手、質檢提示：本地小模型，時延按秒計。複雜分析、代碼輔助：可走API，但附件剝離。路由寫在網關，應用不要各連各的。
- 出域必須過脫敏和審批，留審計。
- 本地模型要有版本和回滾，避免\"誰在筆記本上跑的\"成為生產依賴。
- 按場景看成本和錯誤率，而不是按\"我們只用一家\"。
時延是現場的硬約束
車間助手如果要等兩秒以上的雲往返，工人會關掉它。這類場景即使效果略弱，也要本地。XYN 數智化系統把助手請求按場景路由到本地或API，權限與脫敏規則一致。組合清楚了，採購才知道該買卡還是該買token，安全才知道哪條鏈路要重點審。
先給場景貼標籤再買模型。先買模型再找場景，會同時養一套閒置GPU和一份過大的API帳單。
