附录C：成本估算与资源模板¶
C.1 附录定位¶
数据工程项目最容易被低估的，不是技术复杂度，而是成本结构。很多团队在立项时只问“训练要几张卡”，却没有系统回答以下问题：样本采集与清洗谁来做，标注复核要花多少人天，评测与排行榜维护需要多少长期预算，多模态文件存储和回源流量要花多少钱，教学镜像是否需要固定一整学期的资源。大规模训练的资源消耗和碳排放已经被多项研究专门讨论，说明训练预算不能只被当成临时工程开销处理（Patterson et al. 2021）。
因此，本附录的目标不是给出一个放之四海而皆准的价格表，而是建立成本估算的方法、表格和复盘模板。只要方法稳定，具体单价即使随时间变化，团队仍可以快速重新估算；如果方法本身缺失，即使掌握了某个时点的单价，也无法做出可靠预算。
C.2 成本为什么要按生命周期拆开¶
很多预算争议的根源，不是总额高低，而是不同角色关注的成本对象不同。研究人员可能只关注训练 GPU，平台工程师更关心存储和回流，课程负责人更关心镜像和助教工时，管理层则关心季度投入与交付节奏。若没有统一拆分，讨论会不断失焦。
一个更适合数据工程项目的拆法，是按生命周期拆成六类成本：
| 成本类目 | 核心问题 | 典型单位 |
|---|---|---|
| 数据接入成本 | 拿到样本要花什么 | 人天、API 调用、抓取任务 |
| 清洗与加工成本 | 把样本做成可用资产要花什么 | CPU/GPU 时长、人天 |
| 标注与复核成本 | 监督信号如何形成 | 每样本、每小时、每轮 QA |
| 训练与推理成本 | 模型消费数据要花什么 | GPU 小时、tokens、吞吐 |
| 评测与发布成本 | 比较、榜单和开放维护要花什么 | 任务批次、人工复核、人天 |
| 教学与运维成本 | 让他人长期可复现要花什么 | 镜像、账号、课程助教工时 |
这种拆法的价值，在于它逼着团队承认一个现实：真正长期昂贵的，往往不是首发训练，而是后续治理与维护。
C.3 总体估算公式¶
一个足够实用的总体估算公式可以写成：
为了便于执行，可以把每一项都拆成“固定成本 + 规模成本 + 返工风险储备”：
很多团队预算失控，并不是 variable 项看错了，而是完全没预留 risk 项。例如，重复标注、脱敏返工、榜单复核、样本下线和学期中镜像修复，几乎都会在真实项目中出现。
C.4 数据接入与清洗成本模板¶
C.4.1 接入成本不应只看“抓回来多少”¶
接入阶段至少要估三种成本：接入脚本开发、数据拉取运行、来源核验与授权确认。一个简单模板如表 C-1。
| 项目 | 单位 | 数量 | 单价/工时 | 小计 | 备注 |
|---|---|---|---|---|---|
| 接入脚本开发 | 人天 | 抓取/API/解析适配 | |||
| 数据拉取任务 | 批次 | 含失败重试 | |||
| 来源与许可核验 | 人天 | 合作方、协议、日志整理 | |||
| 存储入湖 | TB/月 | 原始层存储 | |||
| 数据抽检 | 人天 | 首轮质量基线 |
如果项目源头较多，建议把来源核验成本单独拉出来，而不是混进脚本开发。因为它往往是影响上线节奏的隐性关键路径。
C.4.2 清洗成本最容易低估返工¶
清洗成本通常包含规则开发、批处理资源、异常样本复核和重新运行成本。推荐使用下面的拆法：
| 成本项 | 估算方法 |
|---|---|
| 规则开发成本 | 规则数量 × 平均设计与测试工时 |
| 批处理成本 | 数据量 × 单位处理资源消耗 |
| 失败样本复核成本 | 异常样本数 × 单样本复核时间 |
| 重跑成本 | 主流程每次重跑资源 × 预计重跑次数 |
特别是在文档、多模态和语音项目里，重跑成本经常被忽略。比如 OCR 策略、去重阈值、音频切片规则一旦调整，后续常常需要重新生成一整层中间产物。
C.5 标注、审阅与合成数据成本模板¶
C.5.1 标注成本一定要区分“首标”和“复核”¶
只按每条样本标一个单价来估算，几乎一定会低估预算。更合理的方式是把标注拆为：
- 首标成本
- 复核成本
- 仲裁成本
- 标注说明迭代成本
- 平台与管理成本
表 C-2 可作为通用模板。
| 项目 | 单位 | 数量 | 单价/工时 | 小计 | 备注 |
|---|---|---|---|---|---|
| 首标 | 条/页/分钟 | 与任务粒度相关 | |||
| 复核 | 条/页/分钟 | 建议按抽样率估算 | |||
| 仲裁 | 条/页/分钟 | 高争议样本专项预算 | |||
| 说明迭代 | 人天 | 指南与 QA 会议 | |||
| 平台维护 | 月 | 账号、权限、导出 |
如果任务属于偏好对齐、多模态区域标注或语音情绪控制，仲裁和说明迭代成本往往比首标更容易成为瓶颈。
C.5.2 合成数据不是“零人工成本”¶
很多项目听到“用大模型生成合成数据”后，会天然以为成本能显著下降。但真实情况通常是：首轮生成成本下降了，验证和筛选成本未必下降，甚至更高。合成数据成本至少应包含：
| 成本项 | 说明 |
|---|---|
| prompt/template 设计 | 谁来定义生成协议 |
| API 或推理成本 | 生成本身的 tokens 或 GPU |
| 过滤与打分 | 自动 judge、规则筛选 |
| 人工抽检 | 验证是否真的可用 |
| 回炉重生成 | 对失败样本再处理 |
也就是说，合成数据最稳妥的预算方法不是“生成 10 万条的 API 账单”，而是“生成、过滤、抽检和返工的全链成本”。
C.6 训练与推理资源估算模板¶
C.6.1 训练资源估算不要只看卡数¶
训练预算最容易被简化成“几张卡、跑几天”，但真正决定成本的至少还有三件事：有效吞吐、失败重跑概率和调参轮次。以 Megatron-LM 为代表的大规模训练系统表明，模型并行、数据并行和流水并行策略会显著影响吞吐、显存占用和失败恢复成本（Narayanan et al. 2021）。一个更稳妥的表格如下：
| 项目 | 单位 | 数量 | 单价/工时 | 小计 | 备注 |
|---|---|---|---|---|---|
| 训练 GPU | GPU 小时 | 正式训练 | |||
| 调参 GPU | GPU 小时 | 小规模试验 | |||
| 评测推理 | GPU 小时 / tokens | 含切片评测 | |||
| 数据准备 CPU | 核时 | 分词、打包、校验 | |||
| 失败重跑储备 | 百分比 | 建议单列 |
如果团队完全不估失败重跑储备，预算表很容易在第二轮实验后失真。对工程项目而言，预留 10% 到 30% 的风险资源通常比“第一次估得极准”更有价值。
C.6.2 推理成本要按场景拆分¶
推理成本至少应分为三类。对于长上下文和高并发服务，PagedAttention 等内存管理机制已经成为推理服务成本估算的重要参照，vLLM 的工程文档也提供了部署和调优层面的实践入口（Kwon et al. 2023; vLLM Project 2026）。
| 场景 | 特点 | 估算重点 |
|---|---|---|
| 离线批评测 | 批量、可排队 | 吞吐、并发、结果缓存 |
| 在线服务 | 延迟敏感 | 峰值并发、上下文长度、回退策略 |
| 教学实验 | 时段集中 | 学期镜像、账号上限、失败重试 |
把这三类推理成本混在一起，会让团队既解释不清为什么线上预算高，也解释不清为什么课程周会出现资源峰值。
C.7 评测、榜单与公开维护成本模板¶
C.7.1 公开基准的长期成本往往高于首发成本¶
一个公开 benchmark 的成本不止是“首发一次”。真正持续发生的支出包括：
- baseline 复现和升级
- 提交结果校验
- 可疑结果人工复核
- 样本争议处理
- 文档与镜像维护
- 教学版本锁定
表 C-3 可以帮助团队单独估这个部分。
| 项目 | 周期 | 单位 | 估算方式 |
|---|---|---|---|
| baseline 重跑 | 季度/半年 | GPU 小时 | 基线数量 × 单次评测成本 |
| 提交审查 | 月 | 人天 | 提交量 × 单次核验工时 |
| issue 处理 | 月 | 人天 | 历史平均工单量 |
| 文档更新 | 版本发布时 | 人天 | Card、FAQ、release note |
| 教学镜像维护 | 学期 | 人天/实例 | 开课前冻结与学期内补丁 |
如果这一层成本没有被预算，公开基准很容易首发时热闹、半年后失真。
C.7.2 评测成本为什么常常在后期突然上升¶
不少团队在项目初期会觉得评测成本很低，因为早期只是在小范围内跑几个基线。可一旦数据集进入公开发布、课程实验或多团队协作阶段，评测成本往往会迅速上升，原因通常包括：
- 切片数量增加，单次评测不再只算总分。
- baseline 数量增加，需要保留历史可比性。
- 可疑结果需要人工复核，而不只是自动脚本判定。
- 课程实验需要锁定一套稳定评测环境，不能跟随主线频繁变动。
因此，评测预算最好分成“内部研发评测”和“公开维护评测”两本账。前者服务快速迭代，后者服务稳定比较。把两者混在一起，会让团队在项目成熟期突然觉得“为什么评测开始变贵了”，其实只是此前没有把公开维护成本正式看见。
C.8 存储、网络与归档成本模板¶
C.8.1 多模态项目中，存储成本必须单列¶
文本项目很多时候还能容忍“粗略估一下磁盘”，但文档、图像、音频、视频和 Agent 轨迹一旦进入项目，存储和回源流量就必须显式进入预算。建议至少区分：
| 类目 | 说明 |
|---|---|
| Raw 原始文件 | 最大但访问频率未必高 |
| 中间产物 | OCR、特征、转码、索引 |
| Curated 正式版本 | 训练与评测正式输入 |
| Release 镜像 | 对外发布和课程复现版本 |
| 归档层 | 冷存储与长期保存 |
如果没有这种分层，团队很容易在项目中后期发现：真正昂贵的不是训练，而是所有中间产物都被默认永久保留。若项目使用 Kubernetes 承载训练、评测或教学环境，资源配额、存储卷、命名空间和作业生命周期也应纳入预算表，具体资源对象和调度语义可参见 Kubernetes 官方文档（Kubernetes Authors 2026）。
C.8.2 归档策略会直接影响未来三年的可维护性¶
归档不是简单地把旧版本压缩起来，而是决定未来还能不能复盘和复现。一个好的归档预算至少应回答：
- 哪些版本必须长期保留。
- 哪些版本只保留元数据与指针。
- 哪些课程镜像需要按学期冻结。
- 哪些公开版本需要可回滚。
没有归档策略的项目，后续最常见的问题是“省下了一点存储费，却失去了复盘能力”。
C.8.3 网络回源与外部调用成本不能被混入“其他”¶
在多模态项目、RAG 项目和开放榜单场景里，网络与外部调用开销经常被写进一个模糊的“其他成本”，这会直接削弱预算判断能力。建议至少单列三类：
| 类别 | 常见来源 | 为什么必须单列 |
|---|---|---|
| 回源流量 | 对象存储下载、课程镜像拉取 | 访问峰值常与课程节点重合 |
| 外部 API | judge、OCR、翻译、脱敏 | 计费逻辑常按调用量快速放大 |
| 外发同步 | 公开发布、镜像复制、跨区备份 | 与合规和可用性策略强绑定 |
只要这些费用被单列，团队就更容易回答一个关键问题：成本上升到底是因为项目规模真的变大了，还是因为发布方式、课程使用方式或外部服务依赖方式发生了变化。
C.9 三套可直接使用的资源模板¶
C.9.1 小型研究/课程模板¶
适用对象：实验室、单课程、原型项目。
| 模块 | 建议预算思路 |
|---|---|
| 数据处理 | 以人天为主，资源为辅 |
| 标注 | 小样本高质量，复核比例适当提高 |
| 训练 | 先估试验轮次，再估正式轮次 |
| 评测 | 强调切片与复盘，不盲目扩榜单 |
| 教学 | 必须单列镜像与助教支持工时 |
C.9.2 中型团队项目模板¶
适用对象：多成员协作、季度交付、有内外部使用方。
| 模块 | 建议预算思路 |
|---|---|
| 数据接入 | 建立固定入口与版本策略 |
| 清洗治理 | 单列重跑成本与异常复核成本 |
| 训练推理 | 用正式训练、调参、评测三账分开 |
| 发布维护 | 把 benchmark 和 issue 运维作为长期项 |
| 合规 | 审批、脱敏、撤回流程计入管理成本 |
C.9.3 开放基准/高校合作模板¶
适用对象：要做对外发布、课程复现和长期维护的资产。
| 模块 | 建议预算思路 |
|---|---|
| 数据版本 | 至少保留 raw、curated、release 三层 |
| 文档 | Card、FAQ、release note 不得省略 |
| 榜单 | 审查、复核、撤榜机制必须计成本 |
| 教学 | 学期冻结版本与实验脚本必须单列 |
| 交接 | 每学期或每版本预留移交整理工时 |
C.9.4 以一轮高校合作数据集发布为例的估算顺序¶
如果团队要完成一轮高校合作数据集从整理、评测到公开发布的流程，估算时建议采用下面的顺序，而不要一上来只问训练预算：
- 先估接入与许可核验成本，因为这是能否对外发布的前提。
- 再估清洗、脱敏和版本打包成本，因为这决定是否能形成稳定 release。
- 再估 baseline 和评测脚本成本，因为没有它们就没有可比较发布。
- 最后再估教学镜像、榜单运维和 issue 处理成本，因为这些决定资产能否长期维护。
这种顺序和很多团队的直觉相反，但它更符合第十二篇的中心思想：数据集不是“一次训练前的原料”，而是会持续消耗维护资源的工程资产。
C.9.5 建议保留的预算台账字段¶
预算模板真正想长期发挥作用，最好不是每次另起一张 Excel，而是沉淀为一份持续更新的预算台账。建议至少保留以下字段：
| 字段 | 说明 |
|---|---|
| budget_cycle | 对应季度、学期或版本周期 |
| asset_scope | 涉及的数据集、benchmark 或课程 |
| planned_cost | 预算值 |
| actual_cost | 实际值 |
| variance_reason | 偏差原因 |
| reusable_asset_output | 本轮形成的长期资产 |
| one_off_cost | 一次性开销 |
| maintenance_cost | 后续维护开销 |
一旦这些字段被持续保留，团队就能逐渐回答一个有价值的问题：哪类投入最容易沉淀成长线资产，哪类投入虽然昂贵却只是在被动补洞。
C.10 季度复盘时最该看的不是“超没超预算”¶
预算复盘最容易犯的错误，是只看是否超支，而不看为什么超支。真正对下一轮项目有用的问题通常包括：
- 超支主要来自训练、返工、标注还是维护？
- 哪一项成本原本没被看见，现在必须正式入表？
- 哪些开销换来了可持续资产，哪些只是补洞？
- 教学、公开基准和生产版本是否被不当地混算？
- 下一季度最值得控制的是哪一层，而不是哪一个数字？
也就是说，预算表不是为了把项目变成财务游戏，而是为了把“资源到底投在了哪种数据价值上”说清楚。
C.10.1 适合写进季度复盘的三张图¶
如果项目需要把预算复盘写成更可沟通的报告，最值得保留的通常不是几十行细碎账目，而是三张总结图：
- 生命周期成本分布图：展示接入、清洗、标注、训练、评测、维护各自占比。
- 预算偏差来源图：展示超支来自返工、调用量增长、镜像维护还是人工复核。
- 资产沉淀对照图：展示本季度花出去的钱，形成了哪些可复用版本、模板或公开资产。
这三张图的意义，在于它们把财务语言重新翻译回工程语言。对于需要在书稿、课程、开源基准或生产项目之间共享资源模板的团队来说，这种翻译尤其重要，因为它能帮助不同角色对“投入换来了什么”形成一致认知。
C.11 本附录小结¶
本附录建立了数据工程项目的成本估算方法和资源模板。核心结论有三条。
第一，成本必须按生命周期拆解，否则团队只会看到训练成本而忽略治理成本。
第二，最容易失真的不是单价，而是返工、复核、维护和教学复现这些风险项。
第三，真正成熟的成本管理，不只是为了省钱，而是为了让资源投入和数据资产价值之间形成可解释的对应关系。
参考文献¶
Patterson D, Gonzalez J, Le Q, Liang C, Munguia L, Rothchild D, So D, Texier M, Dean J (2021) Carbon Emissions and Large Neural Network Training. arXiv preprint arXiv:2104.10350.
Narayanan D, Shoeybi M, Casper J, LeGresley P, Patwary M, Catanzaro B (2021) Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM. In: Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis. arXiv:2104.04473.
Kwon W, Li Z, Zhuang S, Sheng Y, Zheng L, Yu C H, Gonzalez J E, Zhang H, Stoica I (2023) Efficient Memory Management for Large Language Model Serving with PagedAttention. In: Proceedings of the ACM SIGOPS 29th Symposium on Operating Systems Principles, pp 611-626. https://doi.org/10.1145/3600006.3613165.
Kubernetes Authors (2026) Kubernetes Documentation. https://kubernetes.io/docs/.
vLLM Project (2026) vLLM Documentation. https://docs.vllm.ai/.