从三体问题看三算：算力算法算据的耦合配比与迭代排查

“三体”和“三算”摆在一起，第一反应像是在玩梗。但我把这两个词放到一块，是有实际原因的：过去几年我参与落地过的几个系统级项目，几乎都卡在同一类问题上——不是算力不够，也不是算法不行，更不是数据太少，而是这三者像三个互相绕转的天体，你把其中一个调好，另外两个的相对位置立刻变了。三体问题在数学上没有解析解，只能靠数值积分一步步逼近；三算系统（算力、算法、算据）的资源配置同样没有一劳永逸的公式，只能靠小步试错、持续观测去逼近当下那个最优解。这篇文章不打算讲玄学，我想把这两个概念的对应关系拆开，再落到可复现的计算、可执行的排查流程和几条踩出来的经验上。适合做模型训练、系统容量规划、数据流水线设计的朋友参考，也适合刚入行、想知道“为什么调参调不动”的新人从头看一遍。

1. 把两个词摆到桌面上：三体与三算到底在说什么

开口之前先做一次概念对齐，否则讨论很容易跑偏。这两个词在不同的圈子里指的东西完全不一样，我要聊的是哪一层，得先讲清楚。

1.1 三体问题：一个“没有公式解”的经典困局

三体问题最朴素的版本是：三个质量任意的质点，在彼此引力作用下运动，求它们的运动轨迹。二体问题有漂亮的解析解，椭圆、抛物线、双曲线，用公式能一步到位。但一旦加上第三个天体，解析解就不存在了——这不是数学水平不够，而是被证明过的结论：一般的三体问题不存在由初等函数构成的通解。

这意味着什么？意味着你没法写一个公式，输入三个天体的初始位置和速度，直接输出任意时刻的位置。你唯一能做的是数值积分：把时间切成极小的步长，每一步用当前的位置算受力、用受力算速度增量、用速度增量更新位置，然后不断往前推。步长越小越准，但算得越慢；步长越大越快，但误差会累积。这个“精度与代价的取舍”，是三体问题的工程本质。

还有两个性质必须提。第一是初值敏感：初始条件哪怕差一个极小量，足够长的时间之后，轨迹会完全分道扬镳。第二是长期不可预测、短期可逼近：你没法预测一百步之后它在哪里，但你可以相当准确地算出下一步在哪里，并且通过不断重新观测来修正偏差。

我之所以花篇幅讲这个，是因为它和我们在真实系统里遇到的情况惊人地像。你没法给出一个“多少卡配多少数据配什么算法”的通解，但你可以在每一个阶段做局部最优决策，并靠持续观测把系统拉回正轨。

1.2 三算：算力、算法、算据构成的耦合系统

“三算”这个词在不同行业里指向完全不同。工程造价领域指概算、预算、结算；财务领域指会计核算、统计核算、业务核算；而在智能系统这个语境下，我采用的是最常见的那一版：算力、算法、算据。算力是物理载体，决定单位时间能做多少次运算；算法是转换规则，决定同样的运算能榨出多少有效信息；算据是原料，决定这套系统最终能学到什么、泛化到哪里。

这三者的关系不是简单的加法，而是乘法加约束。你可以把它写成一条很粗的估算式：

系统有效产出 ≈ min(算力供给, 算法效率 × 算据价值) 的量级约束下，取三者中最短的那块板

注意这里用的是“最短的板”而不是“平均值”。算力翻倍但数据只有一百条，产出不会翻倍；数据管够但算法还停留在几年前的思路，算力只是被更快地浪费掉。这跟三个天体互相牵引是一个道理——没有任何一个天体可以独立于另外两个决定自己的轨迹。

顺带说一句，很多人把这一层简化成“大力出奇迹”，觉得堆算力就行。我实测下来，这种理解在早期确实有效，因为那时候三块板都短，随便补哪块都有明显收益；但越往后走，边际收益递减得越快，最后你会发现真正的瓶颈往往藏在最不容易被看见的那一块上。

1.3 为什么这两个词值得放在一起谈

如果只是概念相似，那这篇文章的价值有限。我说它值得谈，是因为三体问题提供的不是比喻，而是可以直接搬过来用的方法论。

第一，数值积分的思想对应“小步快跑的迭代开发”：不要指望一次性设计出完美配比，而是设定一个小步长（比如两周一个迭代），每步都用真实观测结果修正下一步的参数。第二，初值敏感对应“早期决策的长期放大效应”：数据源选错、标注规范定歪，这些在项目初期看起来只是小瑕疵，跑三个月之后会变成无法收拾的偏差。第三，长期不可预测对应“不要做超过观测周期的承诺”：你可以承诺下个季度达到什么指标，但承诺两年后的具体数字，本质上是在赌。

这三条我在实际项目里反复验证过，后面几节会挨个展开讲怎么落地。

2. 三体问题的三个性质，正好是三算系统的三张体检报告

把三体问题的数学性质翻译成工程语言，你会发现它给出的是一套现成的诊断框架。我习惯用它给项目做“体检”，看看到底是哪个维度出了问题。

2.1 不可解析：没有一劳永逸的配比公式

最常被问的问题是：“我这个任务，多少卡、多少数据、多大的模型比较合适？”每次被问到这个，我都得先泼一盆冷水：没有通用答案，只有针对具体约束的近似解。

原因很简单。三算系统里存在大量的非线性反馈：数据规模上去了，模型容量就得跟着涨，否则欠拟合；模型容量涨了，单步训练成本上升，算力预算被挤压，于是你不得不减少训练轮次；轮次减少，数据里的长尾分布就学不透，效果又掉下来。这是一个闭环，任何一个参数变动都会引发连锁反应，指望用一个固定比例的公式套住它，等于指望用二体公式解三体问题。

那工程上怎么办？我的做法是：先建立一个粗糙的可计算模型，用它排除明显不合理的方案，剩下的靠小规模实验定夺。粗糙模型不需要多精确，能把量级算对就够了——比如训练总算力消耗的大致估算、数据准备周期的估算、单次实验的墙钟时间估算。这三个数一出来，很多听起来很美的方案立刻现原形。

这里有个容易忽略的点：粗糙模型的参数必须来自你自己的实测，不能照抄别人的博客。同一块加速卡，在不同的框架版本、不同的并行策略、不同的序列长度下，实际吞吐能差出一倍以上。我见过有团队直接拿公开的基准数字做预算，结果实际跑起来只到预期的六成，整个排期全部推翻重来。

2.2 初值敏感：脏数据是怎么把系统带偏的

三体问题里，初始位置差一个微小量，轨迹会指数级分离。三算系统里对应的现象是：训练数据里占比极小的噪声，会在多轮迭代和多次上线之后被放大成系统性偏差。

我遇到过一个很典型的例子。某次做文本分类，训练集里有一批样本的标注规范没统一——同一个类别，一部分标注员按“主体意图”判，另一部分按“字面表述”判。这批样本占比不到百分之三，单看准确率几乎看不出影响。但上线两个月之后，线上反馈开始集中在某一类边界样本上出错，回头一查，正是当年那批标注不一致的数据把决策边界往错误的方向推了一小段。这个偏移在训练集上是隐形的，在真实分布上被放大了。

这就是初值敏感的工程版本：误差不是线性累积的，而是沿着系统的敏感方向指数放大的。你没法通过“后面多训几轮”把它纠回来，只能在源头控制。

具体怎么控？我的三条硬规矩：一是标注规范必须在第一批数据产出之前定稿，并且用一份不少于两百条的“黄金集”做一致性校验，标注员之间的分歧率超过阈值就回炉；二是任何数据源的接入都要做分布对比，新数据和存量数据的特征分布差异超过预设阈值就单独打标，不直接混入；三是保留数据版本，任何一次效果回退都能追溯到是哪一版数据引入的。第三条最枯燥，但救命的次数最多。

2.3 短期可逼近、长期要重算：工程上的分阶段策略

三体问题没法长期预测，但短期可以算得很准。这个性质在工程上的直接对应就是：排期要按观测周期切段，每段结束时强制重新评估。

我一直反对那种“一口气排半年”的项目计划。不是说不能有长期目标，而是长期目标只能定方向，不能定具体数字。可行的做法是把它切成若干个两到四周的短周期，每个周期结束时重新测算三算的实际状态：算力实际利用率是多少、算法这一版的边际收益还有多少、数据流水线的实际产出速率是多少。三个数字一变，下一个周期的配比方案就得跟着调整。

这套做法的好处是，你永远不会在一个已经明显走偏的方向上投入太久。坏处是管理成本高，需要有人专门维护这套观测机制。我的经验是，项目规模超过某个临界点之后，这个成本是必须花的——不花在观测上，就花在返工上，而且返工的代价通常更高。

顺便说一个实测结论：在项目早期，三算的边际收益排序往往是“数据 > 算法 > 算力”；到了中后期会翻转成“算法 > 数据 > 算力”。这个翻转点没有固定位置，但如果你发现加卡带来的提升已经明显小于预期，基本可以判断已经过了翻转点，该回去抠算法和数据了。

3. 三算拆解实操：把三个“天体”的质量和速度摸清楚

概念讲完，进入可操作的部分。这一节我把三个维度挨个拆开，讲怎么量化、怎么估算、哪些参数最容易算错。

3.1 算力：别拿峰值当预算，先算有效吞吐

算力估算最常见的错误是直接拿厂商标称的峰值算力做预算。峰值是在理想条件下跑出来的，真实训练任务里，数据加载、通信同步、显存换入换出、梯度累积的空转，每一项都在吃掉算力。

我习惯用一个叫MFU（模型算力利用率）的指标来修正：

有效算力 = 标称峰值 × MFU

每天可用算力 = 有效算力 × 86400 秒

MFU 的实测值波动很大，小规模单机任务可能到零点五以上，大规模多机任务掉到零点三甚至更低都很常见。掉的原因通常是通信开销——参数同步的数据量随卡数增长，而单卡的有效计算时间被切碎。

还有一个更隐蔽的坑：显存带宽才是很多任务的真实瓶颈。有些操作用到的算力其实不多，但频繁读写显存，实际速度被带宽卡死。判断方法是算“算术强度”，也就是每搬运一个字节能完成多少次浮点运算。如果这个比值低于硬件的算力带宽比，任务就是访存受限，加算力没用，得改算法结构或换数据布局。

我给你的实操建议是：不要相信任何没有在你自己的任务上实测过的算力数字。花半天时间跑一个最小可用的基准任务，测出真实的每秒处理样本数，后面所有估算都基于这个数，比什么公式都靠谱。

3.2 算法：复杂度和收益之间的边际曲线

算法这块最容易被误解的地方是：更复杂的算法不等于更好的结果，它只是在特定条件下换取更好结果的一种交易。

我一般从三个角度评估一个算法方案：计算复杂度（随输入规模怎么涨）、实现复杂度（工程落地要多少人天）、收益上限（理论上还能提升多少）。三者放在一起看，很多“先进方案”其实并不划算——复杂度涨了一个量级，收益只多了几个点，而且这几个点还不一定能在你的数据分布上复现。

这里有个很实用的判断方法：做一条小规模的收益曲线。固定数据和算力，把算法从简单版本逐步升级到复杂版本，记录每一步的效果和成本。如果曲线在前两步陡峭、后面迅速变平，说明你已经接近这类算法的天花板，继续加复杂度是浪费。如果曲线一直很平，那可能是数据或算力那边有问题，不是算法的问题。

还有一点要提醒：算法和算力之间不是正交的。有些算法在小算力下表现平平，算力上去之后才显出优势；有些算法反过来，小算力下性价比极高，算力一大就被更简单的方案反超。所以评估算法不能脱离算力条件单独做，必须在你的实际预算下测。

3.3 算据：清洗不是越干净越好，是越“值”越好

数据处理这块，新人最容易走极端：要么完全不清洗，把原始数据直接喂进去；要么追求极致干净，反复过滤直到剩不下多少。这两种做法我都试过，效果都不好。

正确的目标函数不是“干净度”，而是单位算力投入换回的信息量。同样一份数据，过度清洗会把有价值的长尾样本一起扔掉，导致模型在边缘场景上表现很差；清洗不足则会让模型把算力浪费在噪声上，收敛变慢。

我的经验做法是分层处理：先做规则能覆盖的硬性问题（格式错误、明显重复、长度异常），这一层成本极低收益极高，必须做；再做需要模型辅助的软性判断（质量打分、语义去重），这一层成本高，要设阈值，只处理打分明显偏低的尾部；最后是人工抽检，比例不用高，但必须固定抽样口径，用来监控前两层的实际效果。

还有一个经常被忽略的指标：数据产出的速率。很多团队在规划时只算总量，不算流速。总量一个亿，但清洗流水线每天只能产出两百万，那就是五十天的等待。这个等待时间必须算进项目周期，否则算力会空转。后面第 4 节我会用一个具体的估算脚本把这件事算清楚。

3.4 三者怎么咬合：木桶、瓶颈与配比测算

单看每一块都不难，难的是判断当前该补哪一块。我用的方法比较土，但有效：把三块板分别换算成同一个单位——天。

算力换算成“完成这次训练需要多少天”，算法换算成“在当前算法下，达到目标效果需要多少训练步数，折合多少天”，数据换算成“产出这么多高质量数据需要多少天”。三个数字摆在一起，最长的那个就是当前的瓶颈，其余两个都是在等它。

这个方法的好处是直观，坏处是粗糙。它假设三者之间没有交叉影响，实际上有——算法效率提高会缩短训练天数，从而让数据的等待时间变得更突出。所以我一般会算两轮：第一轮定瓶颈，然后假设把瓶颈改善百分之三十，再算第二轮，看瓶颈会不会转移到别处。两轮下来，基本能判断出该往哪个方向投入。

提示：如果你算完发现三块板的天数非常接近，不要高兴得太早。这通常意味着系统处在临界状态，任何一块的轻微波动都会让瓶颈跳来跳去，管理成本会急剧上升。这种情况下的正确做法是主动留出百分之二十左右的冗余，宁可有一块板闲着，也不要让三块板同时绷紧。

4. 动手跑两个小实验：从数值积分到三算配比测算

理论说再多不如跑一遍。这一节给两个可以立刻复现的小实验，第一个演示初值敏感到底有多狠，第二个是一个可以直接改成自己参数的配比测算脚本。两个脚本都只用 Python 标准库，不需要装任何第三方包。

4.1 实验一：用六十行代码看初值敏感到底有多狠

这个脚本模拟三个等质量天体在一个平面内的运动，采用经典的“8 字形”周期轨道作为初始条件——这是三体问题里少数几个已知的稳定周期解，非常适合用来观察扰动如何增长。

import math G = 1.0 M = [1.0, 1.0, 1.0] def accel(pos): a = [[0.0, 0.0] for _ in range(3)] for i in range(3): for j in range(3): if i == j: continue dx = pos[j][0] - pos[i][0] dy = pos[j][1] - pos[i][1] r2 = dx * dx + dy * dy r = math.sqrt(r2) f = G * M[j] / (r2 * r) # 引力大小 / 距离，方向由 dx dy 给出 a[i][0] += f * dx a[i][1] += f * dy return a def step(pos, vel, dt): # 速度 Verlet：先走半步速度，再用新位置算受力，最后补半步 a = accel(pos) for i in range(3): for d in range(2): vel[i][d] += 0.5 * dt * a[i][d] pos[i][d] += dt * vel[i][d] a2 = accel(pos) for i in range(3): for d in range(2): vel[i][d] += 0.5 * dt * a2[i][d] def energy(pos, vel): ke = sum(0.5 * M[i] * (vel[i][0] ** 2 + vel[i][1] ** 2) for i in range(3)) pe = 0.0 for i in range(3): for j in range(i + 1, 3): r = math.hypot(pos[j][0] - pos[i][0], pos[j][1] - pos[i][1]) pe -= G * M[i] * M[j] / r return ke + pe def init(perturb=0.0): pos = [[0.97000436, -0.24308753], [-0.97000436, 0.24308753], [0.0, 0.0]] vel = [[0.466203685 + perturb, 0.43236573], [0.466203685, 0.43236573], [-0.93240737, -0.86473146]] return pos, vel def run(perturb, t_end=12.0, dt=0.002): pos, vel = init(perturb) e0 = energy(pos, vel) t = 0.0 traj = [] while t < t_end: step(pos, vel, dt) t += dt traj.append([[p[0], p[1]] for p in pos]) return traj, e0, energy(pos, vel) base, e0, e1 = run(0.0) pert, _, _ = run(1e-8) print("能量相对漂移: %.3e" % abs((e1 - e0) / e0)) for k in [500, 1000, 2000, 3000, 4000, 5000, 6000]: if k >= len(base): break d = sum(math.hypot(base[k][i][0] - pert[k][i][0], base[k][i][1] - pert[k][i][1]) for i in range(3)) print("t = %5.2f 分离度 = %.6e" % (k * 0.002, d))

跑之前先说清楚几个设计取舍。为什么用速度 Verlet 而不是最简单的欧拉法：欧拉法每一步都会系统性地给系统注入能量，跑久了轨道会越转越大，那是数值误差不是物理现象。Verlet 是辛积分器，能量在长时间尺度上只是振荡而不漂移，这一点可以用脚本里打印的能量漂移来验证——步长取 0.002 时，相对漂移通常在万分之一以下，够用了。为什么步长不能太大：三体轨道近距离交会时加速度变化极快，步长太大会直接让天体“穿”过去，结果完全失真。扰动为什么取 1e-8：这个量级相当于把初始速度在小数点后第八位改动一下，现实中的任何测量误差都比这个大。

预期看到的结果是：分离度在前期缓慢增长，然后进入一个近似指数增长的阶段。这就是初值敏感的数值证据。你在系统里留一个万分之一的偏差，跑得足够久之后，两条轨迹会毫无关系。

4.2 实验二：一个可复用的三算配比测算脚本

这个脚本解决的问题是：给定模型规模、数据配比、硬件条件和流水线产能，估算训练要多久、数据要等多久、瓶颈在哪里。

def plan(param_num, tokens_per_param, card_peak_tflops, mfu, card_count, data_rate_per_day, label="方案A"): # 训练总浮点运算量：前向 2ND，反向 4ND，合计约 6ND tokens = param_num * tokens_per_param total_flops = 6.0 * param_num * tokens # 单卡每天的有效浮点运算次数 per_card_day = card_peak_tflops * 1e12 * mfu * 86400.0 card_days = total_flops / per_card_day train_days = card_days / card_count # 数据侧：产出这么多 token 需要多少天 data_days = tokens / data_rate_per_day return { "label": label, "tokens": tokens, "total_pflops_day": total_flops / 1e15, "card_days": card_days, "train_days": train_days, "data_days": data_days, "gap_days": abs(train_days - data_days), "bottleneck": "算力" if train_days > data_days else "数据", } cases = [ plan(7e9, 20, 400, 0.40, 64, 2.0e10, "70亿参数 / 64卡"), plan(70e9, 20, 400, 0.35, 64, 2.0e10, "700亿参数 / 64卡"), plan(70e9, 20, 400, 0.35, 512, 2.0e10, "700亿参数 / 512卡"), ] for c in cases: print("%-22s tokens=%.2e 卡天=%8.0f 训练=%6.1f天 数据=%6.1f天 瓶颈=%s" % (c["label"], c["tokens"], c["card_days"], c["train_days"], c["data_days"], c["bottleneck"]))

参数的含义我解释一下，这几个是必须自己实测的：card_peak_tflops是标称峰值，mfu是实测的有效利用率（这一项绝对不能照抄，必须自己测），data_rate_per_day是你的清洗流水线每天能产出的高质量 token 数。tokens_per_param取 20 是个业界常用的经验配比，不是铁律，小模型可以更高，大模型在数据受限时会降低。

用这几个参数跑一遍，你会看到很典型的现象：小模型时算力充裕、数据是瓶颈；模型放大之后算力迅速变成瓶颈，加卡之后训练时间下来了，数据又跟不上。这就是三体式的耦合——你把一个天体的速度调大，另外两个的相对关系立刻变了。

4.3 结果怎么读，结论怎么用

两个实验跑完，最该带走的是三条判断逻辑。

第一，看差距不看绝对值。实验二里最有用的不是“训练要多少天”，而是“训练天数和数据天数的差值”。差值小说明两边咬合得好，差值大说明有一边在空转，空转的那部分就是浪费的钱。

第二，给扰动留预算。实验一告诉我们扰动会指数放大，那么工程上就必须在早期留出纠偏的余量。我的做法是把数据质量校验、标注一致性检查这类“看起来不产出”的工作，按总工期的百分之十五左右预留，不占用这部分的项目基本都会在后面付出更大代价。

第三，结论有保质期。两个脚本算出来的数字，只在当前参数下成立。参数一变，结论就作废。所以我习惯把这两个脚本存成模板，任何一次方案变更都重新跑一遍，三分钟的事，比事后返工便宜太多。

5. 踩坑记录：三算项目里最容易翻车的几个地方

这一节是我这些年攒下来的问题清单，按症状归类，方便你对照排查。

5.1 症状、根因与处置速查表

这张表能覆盖我遇到过的七八成问题。剩下的两三成通常是多个因素叠加，需要按下面的顺序逐层排查。

5.2 排查顺序：从数据到算法再到算力

排查顺序错了，会浪费大量时间。我的固定顺序是数据 → 算法 → 算力，理由很简单：数据问题的排查成本最低（看几条样本就能发现异常），算力问题的排查成本最高（要跑基准、要抓性能剖析）。

具体做法：先抽五十到一百条训练样本，人工过一遍，看格式、看标注、看分布，这一步通常十分钟内能排除掉一大类问题。然后固定一个小规模配置，把算法链路上每一个环节的中间输出打印出来，确认没有静默失败——我最常遇到的坑是某个预处理步骤抛了异常被吞掉，数据悄悄变成了空值，训练照跑但学不到东西。最后才去查算力，用最小可复现脚本测实际吞吐，和预期对比，差得远再往下剖析。

注意：不要一上来就怀疑硬件。我统计过自己排查过的问题，真正是硬件或算力配置导致的比例不到两成，绝大多数问题出在数据和链路上。

5.3 几条不太好写进文档的经验

第一条，日志要记录“为什么”而不只是“是什么”。大多数人记录的是配置值和结果指标，但真正有用的是当时的判断依据。三个月后回头看“为什么把学习率调成这个值”，如果日志里只有数字没有理由，你等于从零开始重新推理。

第二条，任何一次显著的效果提升都要能复现三遍。单次提升有可能是随机波动，尤其在数据量不大、随机种子没固定的时候。我见过不止一次“重大突破”在第三次复现时消失的情况，如果当时就急着写进汇报材料，后面会很难收场。

第三条，给数据流水线留人工兜底通道。全自动的清洗流程一定有它处理不了的边界情况，这些样本会被静默丢掉或错误处理。留一个抽样导出加人工复核的通道，成本很低，但能及早发现系统性偏差。

第四条，算力预算要按“实验次数”而不是“总时长”来分配。一个项目真正需要的是能跑多少次对比实验，而不是总共能用多少卡时。按次数分配，你会自然地去压缩单次实验的成本，这反过来会逼着你把实验设计得更精简。

第五条，别在项目中期更换核心数据源。这一条是用惨痛教训换来的。中期换数据源，等于把所有已经收敛的结论推倒重来，而且新旧数据混在一起的那段时间，系统的行为完全不可预测。要换就趁早，或者等这一版彻底结束。

我在实际操作中的体会是，三算这件事最难的不是把任何一块做强，而是让三块保持在同一个节奏上。强势的那块会不自觉地挤压另外两块的空间，等你发现的时候，系统已经在一条偏得挺远的轨迹上了。定期重跑一次第 4 节那两个脚本，把三个数字重新摆在一起看，是我目前找到的最省事的校准方式。