Enterprise AI Model Sourcing（企业 AI 模型采购）
核心洞察
企业 AI 采购的默认问题不应是“哪家 frontier API 最强”，而应是“这个工作流需要哪种模型来源、哪种部署形态、哪种评测证据和哪种组织能力”。最大模型仍然重要，但在可验证、高频、分布清楚的任务中，专门化小模型可能改写质量、成本和稳定性的排序。
为什么这是模型采购问题
过去三年，企业默认选择最大 frontier model 是合理的：通用 benchmark、供应商能力和风险规避都支持这个选择。
Specialization Beats Scale A Strategic Variable Most AI Procurement Decisions Overlook 提供了一个反例边界：在巴西葡萄牙语 OCR 这个具体企业域里，专门化 3B 模型在质量、成本和稳定性上同时胜出。它不证明“规模不重要”，但证明“规模不是唯一应该优先测试的变量”。
这让模型采购从品牌排序变成系统设计问题。
五个采购变量
| 变量 | 采购问题 | 相关实体 |
|---|---|---|
| 任务分布 | 模型训练历史离部署任务多近？ | 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、系统集成商能带来什么短期能力。
- 内部能力：评测集、训练数据、微调管线、本地推理和运维团队能否沉淀为长期能力。
没有内部微调与评测能力，专门化只是供应商给出的卖点。有了这些能力，专门化才会变成企业自己的模型组合策略。
最小采购判断矩阵
| 工作流特征 | 默认倾向 | 反例检查 |
|---|---|---|
| 高频、可验证、数据敏感 | 内部专门化小模型或 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 模型采购正在从“买最强模型”转向“设计模型组合”。
这套组合的核心资产不是某个供应商账号，而是企业自己能否描述任务、构造评测、理解成本曲线、选择部署边界，并把每次模型选择的证据沉淀为下一次更好的选择。