私有 AI 成本：衡量被接受的任务，而不仅仅是令牌

MLPerf 根据测试条件和质量要求区分推理工作负载。[1] 私有 AI 的采购决策也需要同样的严谨：在比较成本之前，先定义什么算是有用的工作。我们的立场是，每个被接受任务的成本比单纯的令牌价格更能反映试点效果。

这个衡量方法很直接。将分配给试点的所有成本（包括审核和修正）相加，然后除以通过约定验收检查的输出数量。这是一种建议的评估方法，而非 Software Tailor 客户已实现节省的声明。

为完成的工作命名

文档摘要并非模型生成段落就算完成。试点团队可能要求摘要明确决策、保留所有截止日期，并提供返回相关原文段落的路径。错过截止日期的输出需要修正后才算被接受。

在测试前写明这些条件。使用一小批允许的文档，涵盖不同长度和布局。包括一个棘手的例子：扫描页、冲突日期或依赖脚注含义的表格。每个候选配置保持相同输入集，避免工作变化被误认为模型改进。

我们的 AI PDF Reader 是文档工作流的一个可能起点。评估仍应同时考察实际源文档和答案。引用的存在有助于审核，但其存在本身不是验收决定。

记录被拒绝的输出和被接受的输出。否则报告只描述最佳情况，而团队却为整个队列买单。

对于本地部署，在规定的评估期内分摊设备成本。必要时加上测量的电费、适用于所选配置的软件费用，以及设置或维护服务所花时间。结果旁边注明假设。现有有闲置容量的工作站和新购专用服务器属于不同采购情形。

对于托管模型，记录试点实际请求的费用，包括重试。还要计入本地情况中包含的相同审核和集成工作。对一条路径应用完整成本模型，对另一条应用狭义模型，会导致无法支持决策的比较。

审核时间需要明确估价。合理的做法是报告经过的分钟数和估算的人工成本，前提是标明估算依据。除非组织有可信方式实现，否则不要将员工节省的时间当作现金节省。即使工资不变，任务缩短也有价值。

将特殊的安装工作与经常性运营分开。团队才能判断令人失望的第一周是安装工作量大，还是工作流持续存在问题。

Hugging Face 的模型卡格式支持关于预期用途、限制和评估的信息。[2] 将该文档视为候选记录的起点。添加所使用的确切模型版本、本地文件或变体、运行时版本以及执行测试的机器。仅凭模型名称不足以复现购买评估。

同样的原则也适用于性能证据。MLCommons 描述了与提交的系统和软件相关的基准测试结果，并区分了比较类别。[1] 已发布的基准测试可以帮助构建问题框架，但不会为未经测试的办公工作流程提供测量结果。

分别测试冷启动和已运行服务。记录达到有用响应的时间以及完成时间。如果两个人将共同使用系统，应测试该情况，而不是从单个请求推断。这些是试点设计选择，而非声称每个部署都有相同的瓶颈。

该 AI Server 产品页面描述了共享推理的服务器路径。当共享服务适合拟议的任务时，请使用该路径；不要仅为了让试点项目看起来像未来的全组织部署而添加服务器。

最终记录应显示输入集、验收规则、验收数量、审核时间和成本假设。包括最重要的失败案例及其经过适当编辑的源材料。审核人员应能够理解团队为何偏好某一配置，而无需依赖作者的热情。

如果质量不可接受，廉价的结果也无济于事。如果质量可接受但操作工作量过大，请缩小工作流程范围或更改配置，然后重新运行相同的测试。我们关于此的配套文章是关键基础设施中私有 AI 的证据将这种习惯应用于不同的决策边界。

从一个可用任务开始 Software Tailor 产品目录，定义其验收检查，并保持第一个成本表足够小以便审计。有效的数字是可用工作的成本。