Enterprise AI Model Sourcing（企业 AI 模型采购）
核心洞察
企业 AI 采购的默认问题不应是“哪家 frontier API 最强”，而应是“这个工作流需要哪种模型来源、哪种部署形态、哪种评测证据和哪种组织能力”。最大模型仍然重要，但在可验证、高频、分布清楚的任务中，专门化小模型可能改写质量、成本和稳定性的排序。
为什么这是模型采购问题
过去三年，企业默认选择最大 frontier model 是合理的：通用 benchmark、供应商能力和风险规避都支持这个选择。
Specialization Beats Scale A Strategic Variable Most AI Procurement Decisions Overlook 提供了一个反例边界：在巴西葡萄牙语 OCR 这个具体企业域里，专门化 3B 模型在质量、成本和稳定性上同时胜出。它不证明“规模不重要”，但证明“规模不是唯一应该优先测试的变量”。
这让模型采购从品牌排序变成系统设计问题。
新增维度：访问权与退出权
20260831-the-price-of-entry-to-the-frontier 补上了模型采购的上游约束：模型不一定继续以“任何客户都能按 token 购买”的方式存在。实验室可能通过可信伙伴计划、地区和国籍限制、政府许可或产品默认集成控制访问；SaaS 产品也可能把单一模型写进用户已经依赖的工作界面。
- 判断：企业模型采购必须同时管理能力、价格、访问权和退出权；一个价格可接受的模型，如果被地区限制、配额、默认集成或许可门槛锁住，仍可能不是可持续的基础设施。
- 证据：20260831-the-price-of-entry-to-the-frontier；Salesforce 与 Anthropic 的 Claudeforce 公告；Anthropic 关于 Fable 5 与 Mythos 5 访问指令的声明。
- 边界：这些材料记录的是 2026 年的具体产品合作与政府事件，不能推出所有模型都会永久采用同样的封闭策略。
因此，采购评审在原有五个变量之外，还应问：
- 访问由谁决定：供应商、产品平台、政府，还是客户自己的部署环境？
- 模型能否替换：API、prompt、工具调用、评测集和数据管线是否可迁移？
- 默认集成带来的便利，是否换来了单一供应商的架构依赖？
- 开放权重的许可、托管、安全审查、硬件和运维条件是否真的可承受？
退出权必须落实为运行时 Control Plane
20260926-latentspace-openrouter 把“退出权”从采购条款推进到实际运行时。Midha 回忆 Discord 用闭源模型做社区定制 moderation 时，provider 的 guardrail / post-training policy 会直接拒绝本来属于业务需求的输入；不同社区又有自己的规则，因此“供应商允许什么”与“企业实际需要什么”并不天然一致（Transcript 搜索锚点：“content moderation”“we need access to the weights”“custom eval”）。
判断：企业拥有模型退出权，不能只靠合同写“可更换供应商”。真正的退出权需要一个可执行 control plane，使工作流能在 provider policy、价格、可用性或任务适配发生变化时切换模型，并保持自己的 eval、数据策略和治理边界。
- 证据：20260926-latentspace-openrouter；Transcript 搜索锚点：“content moderation”“You need governance”。来源同时指出 code-based LLM integration 最终需要管理模型访问、数据 policy 和团队权限。
- 边界：这是 Discord/OpenRouter 参与者的一手经历，不能推出所有闭源 provider 都会与企业政策冲突，也不能推出所有企业都值得维护多模型 control plane；复杂度应与真实 switching need 匹配。
同一来源还提供了一个采购层面的实现约束：OpenRouter 称默认不读取 prompts/completions，组织需要 opt-in 才记录（Transcript 搜索锚点：“Open Router can't see your prompts or completions”）。这意味着中间层本身也必须被当作数据处理方审查；“多模型自由”不应以默认汇聚业务内容为代价。
五个采购变量
| 变量 | 采购问题 | 相关实体 |
|---|---|---|
| 任务分布 | 模型训练历史离部署任务多近？ | Distributional-Alignment |
| 专门化层级 | 起点是通用模型、领域模型，还是业务域模型？ | Specialization-Compounds |
| 评测证据 | 是否有真实工作流评测，而不是只看公开榜单？ | Evaluation-Set |
| 成本曲线 | 高频调用时 API 成本、推理成本和运维成本如何变化？ | Specialized-Small-Models |
| 部署约束 | 数据、权限、合规和运维是否要求本地化或分层？ | Layered-AI-Sourcing |
专门化小模型适合的位置
专门化小模型不是通用模型的全面替代，而是适合进入企业 AI 组合的一层。
更适合的场景：
- 任务边界清楚，输入输出稳定。
- 有大量重复调用，推理成本会变成主要变量。
- 输出可验证，能建立客观评测和回归测试。
- 企业拥有或能合法获得足够接近部署分布的数据。
- 任务涉及数据主权、延迟或本地部署要求。
不适合默认小模型化的场景：
- 任务开放、跨域、长尾、不确定。
- 缺少真实评测集，只能靠主观感受判断质量。
- 业务需求还在探索期，过早专门化会锁死方向。
- 运维能力不足，无法持续监控、更新和回滚模型。
与分层 AI 来源策略的关系
分层 AI 来源策略原本强调 on-prem、cloud API、FDE 和内部团队之间的分工。专门化小模型把这个框架再推进一步：即使同样选择“模型能力”，也要继续区分 frontier generalist、开源通用模型、领域模型和业务域专门模型。
这意味着企业模型组合可能长这样：
- frontier API 负责开放推理、快速探索和低频复杂任务。
- 专门化小模型负责高频、可验证、成本敏感的核心流程。
- FDE 或外部部署团队负责穿越早期集成约束。
- 内部团队逐步接管评测集、数据管线和模型运维。
采购能力的成熟标志，不是替某一个模型站队，而是能把不同模型放到正确工作流里。
开闭源模型不是同一条曲线
Open and closed models are on different exponentials 给采购框架补了一个经济维度：闭源前沿模型与开放模型经济不是同一条性能曲线上的先后关系，而是两种复利机制。
- 闭源前沿模型通过模型、harness、工具、serving infra 和产品分发的垂直集成，在复杂知识工作中捕获 智能溢价。
- 开放模型经济通过低成本、可控性、本地部署、专门化和多供应商竞争，在达到质量阈值后的任务中扩散。
因此企业采购应把任务分成两类：仍然需要边际智能的任务，以及已经达到足够好阈值、应优化成本和控制权的任务。
内部微调能力也是采购变量
企业是否能选择专门化小模型，不只取决于模型开不开源，也取决于自己能否低成本地做微调、回归测试和部署。Sequence-Packing 这类训练管线优化看似底层，但会改变采购算术：如果一个企业可以在本地硬件上快速微调小模型，它就不必把所有高频、敏感、可验证任务都交给外部 API。
因此模型 sourcing 需要同时问两类问题：
- 外部能力：frontier API、FDE、系统集成商能带来什么短期能力。
- 内部能力：评测集、训练数据、微调管线、本地推理和运维团队能否沉淀为长期能力。
没有内部微调与评测能力，专门化只是供应商给出的卖点。有了这些能力，专门化才会变成企业自己的模型组合策略。
成本判据：成本/完成任务，而非成本/token（08-26 补充）
OpenRouter（2026-08）把"成本曲线"变量操作化为明确公式：
cost per task = (input tokens × input price + output tokens × output price) × expected attempts
核心洞察：低单价模型在重试、长输出、需要更强模型兜底时更贵。经济单位是"完成一次任务的总成本"，不是 API 标价。Chen et al.(2026)《The Price Reversal Phenomenon》：32% 的模型对中低标价模型总成本反而更高，极端 28× 反转；同一 query 两个模型的思考 token 消耗差 900%，重复运行单查询波动最高 9.7×。
这修正了采购讨论的一个常见误区：
- 按 token 比价（$0.75 vs $2.00/M input）只反映单位价，漏掉
expected attempts项——而该项通常决定结果 - 实测判据：GPT-5.4 mini 标价约为 Claude Sonnet 5 的 1/2.4，但若 Sonnet 5 首试成功 95%，mini 必须首试成功 ≥40% 才真正更便宜；低于 40% 时"更便宜的 token 更昂贵的完成任务"
采购流程含义：benchmark 只做短名单过滤器（滤到几个候选），决策用你自己 prompts 在真实工作负载上测量，终点是成本/1,000 完成任务而非模型品牌排序。对无法构造真实评测集的团队，该流程无法启动——评测集基础设施是成本判据的前提条件。
从 Humans-as-Router 到 Workload Routing
20260926-latentspace-openrouter 给这个采购方法增加了运行时视角：用户很早就会“先问更快/便宜的模型，不够好再升级强模型”，即 humans as router（Transcript 搜索锚点：“humans as router”）。Agent 时代把这个问题进一步结构化：OpenClaw 的 heartbeat 与真正任务调用价值密度不同，高频 heartbeat 没必要默认购买最高价 frontier intelligence（搜索锚点：“OpenClaw”“heartbeats”）。
判断：成熟模型采购不应只产生一张“批准模型列表”，还应产出 workload → minimum sufficient model capability 的运行时策略。采购与路由因此是同一个问题的离线/在线两面：采购决定可用供给，router 决定每个动作实际消费哪一层供给。
- 证据：20260926-latentspace-openrouter（搜索锚点：“humans as router”“OpenClaw”“heartbeats”）；20260825-openrouter-choose-best-ai-model。
- 边界：路由器需要可靠的 workload classification、fallback 和 eval；错误降级会把成本优化变成质量损失。低 QPS 或单一稳定工作流也可能没有足够收益抵消多模型复杂度。
最小采购判断矩阵
| 工作流特征 | 默认倾向 | 反例检查 |
|---|---|---|
| 高频、可验证、数据敏感 | 内部专门化小模型或 on-prem | 是否缺少训练数据和运维能力 |
| 低频、开放、需要前沿推理 | frontier API | 是否会沉淀为高频核心流程 |
| 流程复杂、组织阻力大 | FDE / 部署伙伴 | 是否能把 evaluation set 和运行知识带回内部 |
| 探索期、不确定需求 | 云 API 快速试验 | 是否过早把供应商绑定成长期架构 |
| 高杠杆、边际智能改变结果 | 闭源前沿模型 + 集成 harness | 是否只是短期兴奋，缺真实评测证据 |
| 达到质量阈值、成本敏感 | 开源/专门化/本地模型 | 是否低估运维和质量责任内化 |
这个矩阵的作用不是给出固定答案，而是防止采购讨论停留在模型品牌排序。每个工作流都要同时看任务分布、证据强度、调用频率、数据边界和内部承接能力。
数据主权条款也是采购变量
五个采购变量之外，Palantir 的 AI 主权 playbook（2026-07-27）补上了第六个维度：选择托管路径之后，适用什么数据处理条款。核心概念是 Alpha-Transfer——企业的 prompts、responses 与使用模式承载的独特机构知识，可能经条款许可的通道转移给提供商并被转售。严格 ZDR（不落盘、不人审、不训练、仅内存暂存）是必要不充分条件：beta 服务、安全分类器触发、图像输入、prompt 缓存、超链接条款单方变更等至少八条例外路径可以稀释它。
这把模型采购从"选哪个模型"扩展到"选哪种数据关系"：
- frontier API 路线必须附带条款工程（ZDR + 唯一许可用途 + 变更锁定 + 迁移缓冲），否则采购的是"带泄露通道的能力"。
- 条款需要技术门来执行：allow-list、beta header 阻断、区域路由 fail-safe——法务条款若无运行时执行，等于超链接条款（Policy-as-Code-for-Agent-Governance 的采购层镜像）。
- 彻底路径仍是 Hardware-Sovereignty：neocloud + 开源自托管把数据留在自己控制的栈内——playbook 自身也承认，额外主权控制往往意味着自托管开源模型。
注意该来源为 vendor 立场（Palantir 销售主权 AI），机制清单可作检查表，论点强度需打折。
边界
DharmaOCR 的证据很强，但范围窄。它来自 OCR 任务、特定语言文档、特定 benchmark 和模型发布方文章。知识库应保留这个结论的边界：
专门化小模型已经足以挑战“最大模型默认最优”的采购假设；但每个企业域都需要自己的真实评测来决定是否成立。
没有评测集，专门化只是叙事。有评测集，采购才开始变成工程。
结论
企业 AI 模型采购正在从“买最强模型”转向“设计模型组合”。
这套组合的核心资产不是某个供应商账号，而是企业自己能否描述任务、构造评测、理解成本曲线、选择部署边界，并把每次模型选择的证据沉淀为下一次更好的选择。