[从零训练一个500B大语言模型] 25/25：模型做出来以后，这笔投入怎样继续产生价值？

聊天窗口已经能接待用户，我把服务记录和最初的采购表并排打开。左边，服务器与交换机的金额超过三亿美元；右边，一份服务成本演算把一次请求算到了几美分。

同一套机器，怎么会同时出现在这样悬殊的两笔账里？那几美分里究竟装了什么，最初投入的钱又该由谁承担？

我先把计算器放到一边，沿着机器的用途重新整理记录：买下来时付了多少，训练一个版本占用了多久，上线以后又完成了多少请求。三笔账各自回答清楚，下一轮的钱才知道该往哪里花。

先把第三篇的账接回来

先翻回第三篇的采购清单。640台主训练服务器，加20台备用机，共660台、5,280张B200；真正参加主训练的是5,120张。眼前提供服务的机器，也是从这套资源里划出来的。

按2026年10月27日记录的公开配置价，660台含八张指定网卡的服务器，每台457,798美元，合计302,146,680美元。416台指定交换机，每台34,555美元，合计14,374,880美元。两项相加是316,521,560美元。

我把报价日期和配置一起留在金额旁边。采购沿着同一张清单取得批量价格、交付日期与付款条件，收到一份就更新一份。网卡已经随整机计价，不能在网络账里再付一次。

首年人员现金预算5,822,096美元，按既定运行负载与电价情景计算的电费8,176,000美元，九个月规划机房租金20,047,500美元。加总后，当前规划小计为350,567,156美元。

表格下面还有空行：按距离配对的光模块与光纤、共享存储和管理网络、运输安装税费，以及数据和外部服务。第三篇安排13.5MW容量从第4月起租九个月；截至2026年11月4日，采用每kW每月165美元、电费另计的规划租金，即每月2,227,500美元、九个月20,047,500美元。机房合同签订后再换成供应商价格。

这张表先回答公司要准备多少现金。当前约3.5057亿美元的规划小计有了来处，剩余项目逐项拿合同补齐，完整预算再加10%的风险额度。可即使每一行都填满，它仍然没有回答另一件事：刚刚训练出来的这个模型版本，究竟用了其中多少？

采购现金：购买设备时按合同实际支付的钱。付款可以分阶段，设备仍按完整配置计入采购清单。

买下机器，与训练一轮，是两笔不同的账

服务窗口还在运行，下一批评估任务也在排队。同一台服务器训练完一个版本，还可以继续研发、生成材料、接待用户。采购款买下了这些后续用途，不能全压在第一轮主训练上；机器的投入也不能只剩每个月的电费。

我在现金账旁边加了一本资源账。前一本记录每月实际付款，检查资金够不够；后一本按作业记录GPU小时、存储、人员和服务，追踪每个版本用了什么。服务再沿着自己的用量，计算一次请求的成本。

同一套设备可以从三个角度看：现金账记录付款，资源账把使用量分给训练、微调和服务，服务账再计算每次请求的成本。它们通过分摊联系起来，不能把三张账的数字再次相加。中间的色条表示不同任务的用量分类，长度仅作示意。

先把主训练放进去。原计划76天、5,120张活跃卡，排程对应的占用量是：

5,120 × 76 × 24 = 9,338,880 GPU小时

第2篇算出的理论时间约75.35天，76天用于排程。现在有了作业记录，就逐项换成实际占用：调度记录提供机器时间，训练日志提供有效token，故障、保存恢复和等待各留一栏。排程和实耗放在一起，差额也就能继续追查。

主训练那行填好，作业目录里还有前面的小实验与失败尝试，后面的SFT、奖励训练和验收。它们也在消耗同一套资源。我按作业编号归到各个阶段，最后加起来，才看见一个可交付版本走过的完整路程。

GPU小时记出来以后，还需要给它定一个一致的内部价格。我和财务把服务器资本占用先按三年、零残值做简化比较，再加网络与设施分摊；各项任务使用同一口径。正式会计折旧和税务处理沿用公司的政策，这张内部资源表负责帮助工程比较下一项选择。

GPU小时：一张GPU被任务占用一小时的资源计量单位。

成本分摊：把共享设备和服务的成本，按照一致规则分配给使用它们的任务。

同样的机器，为什么用得少反而更贵？

给GPU小时定价时，另一个差额冒了出来。机器在机房里放满一年，未必全年都有值得做的任务。空着的时间没有产出，采购款却已经留在账上。

我先只拿服务器这一项算：457,798美元的八卡整机，按三年、每年365天连续可用，一共有210,240个GPU小时。采购款除以它，约为每可用GPU小时2.18美元。

把真正分给有用任务的时间换进去，数字变了。70%的利用率，对应服务器资本部分每有效GPU小时约3.11美元；只有35%，就变成约6.22美元。电力、网络、机房与运维还在后面。机器没涨价，单位产出的资本成本却翻了一倍。

这笔差额把我带回主训练结束后的资源安排。线上服务和故障替代先留出容量，评估、教师生成与后续研发再按需求分配。每个池同时记录任务完成量和排队情况，长期闲置的容量就重新配置，下一轮采购也跟着调整。

下一次是否扩大模型，同样要经过这张表。更大的模型多占用多少GPU小时，换回来哪项能力，先在可比任务上看收益。这样，结束一轮主训练以后，机器还有明确的下一项工作，新的投入也有了衡量依据。

利用率：在选定时间与资源范围里，资源被实际使用的比例。这里同时看被任务占用和完成有用产出的情况。

一次请求的成本怎样算

资源重新分好，我回到右边那张几美分的服务账。第24篇测的是一个副本在目标延迟内接得住多少流量，现在要把维持这个副本的费用也放进去。

先把某个月的全部服务支出记为C，完成请求数记为N，每请求成本就是C÷N。GPU分摊、CPU与内存、网络存储、机房电力和直接运维都进入C。前面训练研发的投入另列回收账，服务运行费与模型研发费就各有了位置。

我在成本表里先选每GPU小时4美元这一档，查看一组16卡副本的变化。全天运行，一个月按730小时，GPU相关成本就是46,720美元。平均每秒完成1个请求，月请求数约2,628,000，GPU部分约每请求0.0178美元；平均降到每秒0.1个请求，同一笔费用就分成每请求约0.178美元。

4美元这一格是选入表中的敏感性分析值，随后按正式报价和内部资源成本替换。每秒完成量取整个计费月的平均，闲时已经在里面；再乘一次利用率，就会重复计算。

几美分终于有了分子和分母，新的问题却藏在请求本身。贴进整份说明书，和只问一个短问题，占用的资源很不同。我把输入长度、输出长度、缓存命中与延迟等级分开记录，再计算各组成本，避免平均数把长文的代价盖住。

单位成本：完成一个请求、生成一定数量token或解决一个任务所消耗的成本。必须同时说明计量范围。

便宜的回答，也要完成任务

按请求分组以后，小模型的低价很显眼。比较表里，一种方案每次0.002美元、任务成功率50%；另一种每次0.01美元、成功率90%。便宜的一次调用可能还要重试，可能要人工修正，也可能最后仍得转给较大的模型。用户要完成的事，并没有在第一份回答出现时自动结束。

我于是把一次请求往后追到任务结束，增加“每个成功任务的总成本”。同一个任务的尝试与审核费用都记在一起，成功按第23篇的标准判定，失败和人工接管也留下记录。现在才看得清，低价究竟省在了哪里。

沿着这些任务记录，服务开始分工：明确、短小的任务先交给较小模型，复杂长文与难题交给500B；需要新事实时，先检索再按材料回答。决定请求去向的路由器也参加评估，尤其检查难题有没有被错留在能力不足的模型那里。

第一版先用容易识别的任务类别与输入特征分流，并留少量随机抽检。等记录稳定，再训练更细的路由模型。用户要求的质量与隐私边界保持一致，调整的是在这个范围内把工作交给谁。

到2026年，公开推理框架已经提供缓存、分块输入与多副本扩展等机制。它们改变的是服务效率；我们仍用同一组任务检验最终产出。vLLM的调优文档可作为服务试验的起点，具体节省多少由本项目日志计算。

用户的新问题，怎样回到下一轮训练

任务记录积累起来，失败也开始有了不同的样子。有的答不出新近发生的事，有的明明拿到了材料却引用错了。把它们都送去重训，会让下一张GPU账单很快长起来。我先逐项找出缺口出现在哪一段。

新事实缺失，先补检索与资料更新；材料已经在输入里却引用不对，检查提示与阅读能力；工具接口变了，修适配与测试。反复误解同一类要求，才整理新的监督示范；需要通过尝试学习的任务，再补可验证环境与奖励训练。修复沿着问题走，训练成为其中有明确用途的一步。

确实需要补教材的部分，重新回到第7至10篇的流水线：记录来源和使用条件，清洗、去重、审核，再固定版本。用户内容按授权范围处理。已经用于改进的失败题转入回归集，原来的测试隔离继续保留，验收另补新题。

这次我先把目标缩到长文引用错误，同时守住数学与代码表现。另一个候选尝试缩短回答，完成率仍放在旁边检查。每批只比较几个清楚的变化，经过离线评估、小流量试运行和成本核对，再决定扩大使用。

记录慢慢形成了固定节奏：每周整理问题与运行账，每两周比较一批小实验。重要故障即时处理，普通改进积累足够证据再训练，模型是否发布由验收决定。大集群的下一段时间，就从这些明确的小问题里排出来。

再打开最初那张采购单

最初的采购单，数量一栏还是空的。现在旁边已经接上10T累计输入token、5,120张活跃B200、76天主训练排期，以及660台服务器的采购规模。再往后，是模型版本、用户请求和每一次改进的记录。

这些数字各有更新的入口：采购输入等合同补齐，排期随实测吞吐修正，能力由评估报告核对，服务成本从线上日志计算。计划与实际的差额一起保存，下一轮就能看见上一次判断偏在何处。

桌上的两笔账也终于接起来了。现金表继续补齐剩余报价，研发按任务记录GPU小时，线上服务同时看质量、延迟与单位成本。用户没能完成的事，经过审核，成为下一轮资料、产品修复或训练实验的起点。

买卡时的问题是，什么样的机器能让这个模型学起来。现在，机器已经有了持续的去处，问题变成了下一份算力该用在哪里。哪项能力值得继续训练，哪件事用检索、较小模型或产品调整就能做好，答案会留在这些记录里。拥有自己的模型，终于从一张采购单，变成一套能够继续做判断、继续改进的工作。