有人主张全部私有化、账单变成机房和运维；有人主张全部商业 API、合同和配方进了提示词。两端都贵、只是贵法不同。正确切法是场景矩阵：数据敏感到不能出域的走本地开源模型；要最强推理且可脱敏的走商业 API；要现场低时延的本地优先。组合使用、而不是选边站。
先给场景打两个标签：敏感度、时延。标签决定路由、模型厂商只是执行层。
一张路由表就够起步
内部规章・客户名单・成本・配方：本地、默认不出域。营销文案・公开资料摘要：商业 API、输入先脱敏。产线助手・质检提示：本地小模型、时延按秒计。复杂分析・代码辅助：可走 API、但附件剥离。路由写在网关、应用不要各连各的。
- 出域必须过脱敏和审批、留审计。
- 本地模型要有版本和回滚、避免「谁在笔记本上跑的」成为生产依赖。
- 按场景看成本和错误率、而不是按「我们只用一家」。
时延是现场的硬约束
车间助手如果要等两秒以上的云往返、工人会关掉它。这类场景即使效果略弱也要本地。XYN 数智化システム把助手请求按场景路由到本地或 API、权限与脱敏规则一致。组合清楚了、采购才知道该买卡还是该买 token、安全才知道哪条链路要重点审。
先给场景贴标签再买模型。先买模型再找场景、会同时养一套闲置 GPU 和一份过大的 API 账单。
