Scaling Law 预算分配器
一笔算力预算，两段账。第一段拧 GPU 时数，看 Chinchilla 配比把它换成多少参数、多少 token——预算翻 100 倍，参数只翻 10 倍。第二段拧训练费差、推理单价差与累计请求量，看「按配比训大」与「密植训小」两条成本线在哪相交——配比最优 ≠ 总成本最优，胜负手在请求量。
纯前端算真实公式：C≈6·N·D、D=20·N ⇒ N=√(C/120)，与知识库《Scaling Law 与算力预算》动手节 plan() 伪代码逐字对齐；交叉点 Q*=Δ训练费÷Δ单价 对齐「两本账的交叉」一节，零 API、零延迟。
第一段账 · 训练配比：一笔预算怎么分给参数与数据
参数倍数 vs 预算倍数（双对数）
横轴读预算倍数（相对文章算例），纵轴读参数倍数：青实线是 N=√(C/120) 的真形状，灰虚线是「预算翻几倍参数翻几倍」的错觉——实线永远压在虚线下面。
对数刻度 · 文章口径 $2/卡时——一笔训练预算的一次性投入
C ≈ 6·N·D（6 ≈ 每 token 每参数运算次数），D = 20·N ⇒ N = √(C/120)
文章算例：100 万 GPU 时（约 200 万美元）按配比 = 61B 参数 × 1.22T token——C≈6ND 与 D=20N 联立得 N=√(C/120)，这就是「标准配比」的锚点。
第二段账 · 密植交叉点：配比最优 ≠ 总成本最优
累计总成本 vs 请求量
起点差是多喂的数据费，斜率差是每次推理的单价差——A 线缓起步陡爬升，B 线高开低斜率：请求量越大，密植越占优。
方案 B 比 A 多花的一次性训练费——多喂的数据费
方案 A 每千次请求比 B 贵多少——模型越小单次越便宜
部署后累计请求——一缓一陡两条线的胜负手
演示口径：方案 A 锚定文章算例（61B 配比模型：训练 200 万美元、推理 $10/千次），方案 B 为密植版——绝对数值拧着玩，两线相交的机制是真的。
总成本 = 训练费 + 单价 × 请求量，交叉点 Q* = Δ训练费 ÷ Δ单价
已过交叉点（9.95 亿 次）：密植省下的推理费开始反超多花的数据费，当前已省 4.04 万美元——「训得更小、喂得更久」成立，新一代开源模型普遍这么打。