微调还是调用API？文档提取流程的成本考量
用于审计文档处理流程的实测成本模型展示了为何在价格方面模型路由优于微调，以及何时因架构精度或欧盟数据驻留要求而有必要拥有专用模型。
工程领域的领导者们总是反复提出同一个问题，通常是在收到 OpenAI 或 Anthropic 发来的第一张大额账单之后：团队应该自行微调模型，还是继续使用 API？人们普遍认为微调成本更低。虽然有时确实如此，但原因往往并非大家所想的那样，而且对许多团队而言这一观点本身就是错误的。本文通过一个基于实际文档量的系统案例，从两方面对比成本，所用价格均为2026年9月的标价，这样你就能明白真正的节省点在哪里、何时拥有模型才是合理的，以及如何在不冒险投入八周工程师时间进行猜测的情况下做出决策。
人们想象中的选择已不复存在
有一个变化悄然改变了整个讨论的格局：在本文撰写时，已经无法对当前最先进的模型进行微调了。
根据OpenAI的定价页面，其微调平台正在逐步被淘汰：新客户无法注册，目前仅剩o4-mini这一可微调模型，训练费用为每小时100美元。Anthropic自身的API则从未提供过微调功能，其历史上唯一的做法是在Amazon Bedrock上对Claude 3 Haiku进行监督式微调，而除Bedrock和Google Cloud之外，Haiku 3在其他平台均已停止使用。
因此，在2026年底，“微调与前沿技术”这一概念实际上有着更具体的含义：选用Qwen、Llama、Nemotron系列或gpt-oss这类开放权重模型，根据自身数据训练LoRA适配器，然后再将其部署在自己的基础设施上，或通过Fireworks、Together之类的服务提供商来托管。这种选择带来的风险并非人们通常所想的那些与模型选型、评估及服务相关的问题，这些工作通常是托管API会代为处理的。在将相关内容提交给董事会之前，务必对此有清晰的认识。
参考系统：审计证据平台
此处提到的系统并非玩具级产品，而是一个专为中型企业设计的完整审计证据平台，正是英国或北欧地区的会计事务所会实际购买的产品。该系统分为七个阶段运行：
- 数据上传。客户通过门户网站上传文件，多为扫描后的PDF格式。常见的上传文件包括发票、采购订单、收货单、银行对账单、租赁协议以及董事会会议记录。
- 分类处理。每份文档都会被分配一个类型，并送入相应的检测流程。
- 数据提取。结构化字段会被纳入固定的模式中，包括供应商、日期、净额、增值税、采购订单编号、审批人、货币类型以及成本中心。每次输出的结果都必须是符合该模式的有效JSON格式。
- 控制测试。该功能会进行三方比对，确认发票内容是否与采购订单及收货单一致，同时检查审批人是否拥有相应的授权。这部分功能大多由普通代码实现，而非基于模型。
第2阶段和第3阶段几乎消耗了所有处理单元，同时也是系统中最重复、最机械且受架构限制最严格的环节。而第6阶段和第7阶段才是真正需要判断力的部分，但其处理量却微不足道。请记住这种比例关系，因为后续的所有分析都基于此。
估算处理单元数量
该模型假设在任何模型处理之前，所有文档都会先通过OCR转换为文本。这样可以避免按图像token计费，这也是实际操作中的常规做法。
每份文档需要经过三次处理（分类、提取和自我检查），总计大约：
- 5,200个输入token，包括文档文本、结构方案以及少量示例
- 600个输出token，用于生成结构化结果
模型考虑了两种规模：
- Pilot版本：每月10万份文档，相当于某公司在业务高峰期的处理量。
- Scale版本：每月200万份文档，相当于同一产品销售给50家公司的处理量。
Pilot版本每月的token总量约为5.8亿，而Scale版本则为116亿。
费用构成
下表所列价格为2026年9月各供应商定价页面上公布的标准级列表价格，包含全球路由费用，且不享受批量采购或缓存折扣。价格变动频繁，因此仅可作为参考，在制定预算前请再次核实。
在测试规模下，进行微调已毫无意义。在Claude Sonnet 5上运行完整的提取流程每月成本约为1,640美元，Haiku 4.5约为820美元，而经过微调的8B模型则约为116美元。即便每月节省约1,500美元，也远不足以抵消微调带来的成本。在此阶段，直接使用API即可。
在大规模应用时，选择就变得至关重要：
- Claude Opus 5：每月约82,000美元
- GPT-5.6 Sol：每月约65,600美元
- Claude Sonnet 5：每月约32,800美元
- Claude Haiku 4.5：每月约16,400美元
- GPT-5.6 Luna：每月约3,520美元
宣称通过微调可节省90%以上的成本确实很有吸引力，从数字上看这一说法也成立：微调成本约为Sonnet 5型号费用的7%，低于Opus 5型号费用的3%。但任何团队本就不应使用旗舰级模型来进行大规模账单提取操作。将优化后的设计与刻意设计出高成本的模式进行比较，这只是营销手段而非真正的分析。
真正带来大幅节省的是路由优化，而非微调
对比列表中的最后两行数据：GPT-5.6 Luna型号的费用为3,520美元，而经过微调的8B模型费用为2,320美元。两者每月的差异为1,200美元，每年则约为14,400美元。
正确构建微调模型需要完成数据标注、编写评估工具、运行训练任务、搭建服务系统以及添加漂移监测功能。合理的预估时间为八个工程师周。按照欧洲典型的综合承包费率计算，仅通过节省代币成本就能在最多十八个月的时间里实现回本。
更实用的结论是，最大的成本降低来自路由优化。将分类和提取任务从高端服务转移到仍能通过评估的最经济层级后，Opus级服务的月费从82,000美元降至3,520美元，降幅约为96%。只要有合适的路由工具和充足的评估数据集，这一调整仅需一个下午即可完成。在此基础上再进行微调还能再节省约34%的成本。同样的原理——根据每次调用需求调整模型规模——在通过路由、检索和评估来合理调整LLM规模一文中有更详细的阐述。
训练成本几乎可以视为免费。Fireworks提供的LoRA监督微调服务适用于参数量高达160亿的模型，每百万训练令牌的费用为0.50美元。2,500个令牌的标注样本共两万个，训练三轮后总计1.5亿训练令牌，每次训练费用约为75美元。在开发阶段进行八次训练的话，总成本大约为600美元。计算成本从来都不是最昂贵的部分，真正昂贵的是数据准备和评估工作。那些仅根据GPU成本来估算微调费用的，往往是没有实际操作过的人。
为何要进行微调
如果仅从令牌费用来看不值得，还有其他两个因素可能使其变得有必要。
原因一：严格遵循架构规范
这一点在审计工作中尤为重要，但却远未得到应有的重视。
前沿模型属于通用型模型。让它们从51个固定子类别中选择时，由于生成听起来合理的文本正是其训练目标，因此偶尔会选出第52个类别。对于聊天助手而言，这类失误几乎无关紧要；但在需要经过正式审计并出具意见的工作报告中，这则属于缺陷。
最近的研究也得出了类似结论，不过其中很多仍是预印本研究，阅读时需牢记这一点：
- 2026年发表的一篇关于安全文档分类的预印本研究，用51个预定义子类别对各种模型进行了评估，要求以严格的JSON格式输出结果。在该研究中，本地部署的微调模型比那些通过提示训练的先进模型高出15到20个百分点，研究人员还发现GPT-5创造了分类体系中不存在的子类别名称。他们的解读至关重要：先进模型擅长处理格式较为宽松的文本提取任务，但在严格的架构约束下，模型的校准能力比推理能力更为重要。
对于审计产品而言，字段提取准确率提升2个百分点的价值可能超过所有推理功能的总成本，因为每一次提取错误都需要人工审核，而人工审核是该业务中最昂贵的资源。
第二个原因：准确知晓数据存储位置
在欧洲，这往往是决定合作与否的关键因素。
英国或欧盟的会计事务所的审计文件中包含客户的财务记录、员工数据，有时还有第三方的个人信息。数据处理地点并非次要考虑因素，通常只是采购方会问的第二个问题。
截至2026年9月，现有的选择让许多团队感到意外：
- Anthropic的自有API不提供欧盟驻留选项。
inference_geo参数仅接受global或us值，仅在美國處理的服務費率为标准费率的1.1倍。若想让Claude留在歐盟，必须使用AWS Bedrock或Google Vertex的歐盟地區服務，而這些地區端點的費率比全球端點高10%。在撰写本文时，Microsoft Foundry的Claude尚无歐盟數據區。 - OpenAI支持地區化處理，对于2026年3月5日之后推出的模型，其費率會上浮10%。
- Fireworks在将服務限制在特定地區時，費率會乘以1.5。
当按使用量来定价时，情况就有所不同了。两块专用H100芯片用于运行经过微调的8B模型，受地域限制且需全天候运转，每月的成本大约为17,520美元。若在欧盟的Bedrock端点上使用Claude Sonnet 5来处理相同的工作负载，成本约为36,080美元；而使用Opus 5则需约90,200美元。
这正是欧洲人主张拥有该模型的真正理由。并非因为代币更便宜，而是因为合规性说明只需一句话就能讲清楚，无需复杂的架构图。
不要过早购买专用GPU
每月固定的GPU费用看似很有吸引力，却让许多团队陷入困境，因为只有当使用量达到极高水平时才能实现成本效益。以全球市场价计算的两块专用H100显卡每月约需11,680美元作为基准，其成本分界点大致如下：
- Claude Sonnet 5每月处理70万份文档时，API费用更低
- Claude Haiku 4.5每月处理140万份文档时
- GPT-5.6 Luna每月处理660万份文档时
典型的审计类产品在前两年内使用量很可能低于上述所有阈值。通过无服务器方式托管微调后的模型则完全可以避开这一问题：无需为闲置的GPU付费即可获得定制化权重，因此这是较为合理的起点。不过其缺点是延迟和容量方面的控制力较弱，而这只有在使用量达到较高且稳定的水平时才会成为问题。
帮助做出决策的四个问题
1. 您实际的月度Token处理量是多少？如果每月处理的Token量不足10亿，那就选择最便宜的Frontier层级来满足评估要求，把原本用于该层级的8周工程师工作时间投入到更重要的任务上。在试验性规模上进行微调纯属做秀，并非真正的工程实践。
2. 任务的范围和限制有多严格？固定的输出格式、固定的标签集以及每天成千上万个几乎相同的示例都表明适合采用微调方法。而需要开放式推理、主观判断以及为合作伙伴撰写文案的任务则应交给Frontier模型处理，而且很可能会一直使用该类模型。
3. 数据必须存储在何处？要求处理操作必须在欧洲经济区范围内进行的合同条款，会在考虑成本之前就缩小候选方案的范围。应在初步估算中就将数据存储相关的额外费用纳入考量，而非在架构审查时才发现。
4. 能获得至少10,000个带标签的示例吗？NVIDIA研究团队关于代理系统中小型语言模型的论文指出，调整小型模型时所需的示例数量大约在1万到10万之间。如果无法获得这么多示例，那么首个项目就应该对训练流程进行改造，使其能够自行记录训练数据。
最后一点是此处最具价值但也最少被强调的模式。在边界 API 上进行部署，并记录每一次调用，包括输入内容、输出结果以及审核人员的修改。六个月后，你就能拥有一套无需额外成本的带标签数据集，从而能够基于实际证据而非猜测进行微调。记录客户文档本身也涉及数据保护要求，因此应从一开始就为这些日志设计保留和访问规则。
同一篇 NVIDIA 的论文还估算了在三个开源智能体项目中，小型模型能够承担的 LLM 调用比例：MetaGPT 约为 60%，Open Operator 为 40%，Cradle 则为 70%。并非全部由小型模型处理，也非完全不用，正确的答案是多种模型混合使用，而只有日志才能表明哪些调用该由哪种模型处理。
最有力的反论
企业采用数据则显示了相反的趋势。根据Menlo Ventures的企业调查，企业工作负载中开源技术的占比从19%下降到11%，而资金则集中流向了封闭式的API：Anthropic占企业LLM相关支出的40%，OpenAI占27%，Google占21%。（Menlo是Anthropic的投资者，了解这一点有助于理解这些数据。）
这并不与上述分析相矛盾，它只是反映了不同选择之间的权衡点。封闭式API在便利性上更具优势，而便利性往往能占据上风。那些从开源模型微调中获得实际价值的团队，是出于明确可述的原因而主动选择承担更高的运营成本。如果无法说明这一原因，那么这项调查结果就值得重视。
关于欧盟法规的简短说明
英国和欧盟的团队会询问有关《人工智能法案》的情况，因此一份简短的总结很有用。请将其视为入门介绍而非法律建议，并在依赖任何日期之前确认现行文本。
正式名称为《（欧盟）2026/1744号法规》的《人工智能数字综合法案》于2026年7月24日刊登在官方公报上，并于三天后的7月27日正式生效。该法规将独立第三附录系统的高风险义务实施日期从2026年8月2日推迟至2027年12月2日。对于第一附录所涵盖的嵌入式人工智能产品，新实施日期为2028年8月2日。
第50条规定的透明度义务并未推迟，仍按原计划自2026年8月2日起实施。对于更早投放市场的系统，第50条第2款要求的标识义务则从2026年12月2日开始适用。
那些为审计师提供支持并保留人工审批环节的工具通常不属于附件三的范围，但需根据自身使用场景来判断：如果任何组件会影响招聘决策或信用评估，那么它就属于适用范围。这些内容均不影响GDPR的约束，无论《人工智能法》如何对系统进行分类，该法规依然适用于系统中流动的客户数据。
需求确实存在。在沃尔特斯·克鲁沃的一项调查中，4,214名内部审计专业人士中有39%表示已经在使用人工智能技术，另有41%预计将在一年内开始使用。
此类系统的分阶段实施计划
对于着手构建这类系统的团队，推荐的步骤如下：
- 选择通过评估集的最经济型基础版本进行部署。 对每个模型调用进行记录，让实际参与审计工作的审计师在业务高峰期使用该系统，暂不进行任何微调。
这四个阶段中有三个的成本都低于许多团队在第一天就投入的金额。
关键要点
- 当前的前沿模型通常无法进行微调，因此真正的选择是在带LoRA适配器的开放权重模型与托管API之间做出抉择。
核心问题从来不是小型模型与前沿模型之争，而是哪些调用确实需要推理能力。答出了这个问题，成本问题在很大程度上也就迎刃而解了。
相关阅读
- RAG架构解析：流程阶段、核心组件及不同变体 — 了解检索增强生成技术的端到端工作原理，RAG系统需要哪些组件，以及各类已命名的RAG变体如何归类于同一框架之下。