UNIT 08渲染约 27 分钟 · 核心线
渲一部片要等多久？
广州片最后那一版，2376 帧，4080 从头到尾没歇，渲了 8 小时 42 分钟 C04。开渲之前你问：「……最快能渲染的时间速度大概是」，又加一句「4k 也测试」。这一课把那天的账从头算一遍：怎么估，估不准时差在哪，什么情况下这笔账整个作废。
08 · 1账单的第一行：多少帧 × 每帧多久
第一行谁都会列：一帧多久 × 多少帧。每秒 24 帧、100 秒就是 2400 帧；那天实测 2K、每像素采样 128 次，一帧 27 秒（那天最后选的是 1080p · 128，一帧 16 秒；这里先拿 2K 举例）：
2400 帧 × 27 秒 = 64,800 秒 ≈ 18 小时
每像素采样几次记作 spp（samples per pixel），第 7 课讲过它为什么决定噪点。三档尺寸：
| 档位 | 尺寸 | 像素 | 是 1080p 的 |
|---|---|---|---|
| 1080p | 1920 × 803 | 154 万 | 1 倍 |
| 2K | 2560 × 1071 | 274 万 | 1.78 倍 |
| 4K | 3840 × 1606 | 617 万 | 4.00 倍 |
难的是第二行：换一档——更清楚的 4K，或更干净的 256 次采样——账变成多少？最顺手的算法是按比例：像素多几倍、采样多几倍，时间就多几倍。先用它猜一道。
同一张 4080、同一批镜头，只让它渲这一件事：「2K · 256 spp」和「4K · 128 spp」，哪一档一帧渲得快？
- 2K · 256 快得多：4K 的像素是 2K 的两倍多
- 4K · 128 快得多：采样只有一半
- 差不多一样快
实测：2K · 256 一帧 46 秒，4K · 128 一帧 47 秒，几乎一样 C04。测法：4080 独占，陈家祠屋脊、沙面古榕、海心沙日落、夜江四个偏重的镜头，各连续渲 4 帧取平均。
猜「2K 快得多」的，只看了分辨率；猜「4K 快得多」的，只看了采样。显卡不分这两样：它要算的是像素 × 每像素采样这么多个样本，分辨率和采样在账上是同一种东西。
2K · 256：274 万像素 × 256 ≈ 7.0 亿个样本
4K · 128：617 万像素 × 128 ≈ 7.9 亿个样本
只差一成多，所以两档差不多久；同样的时间，4K · 128 还多得一版 4K 母版。
一分半的导览：两档为什么差不多，「按倍数一乘」又会错在哪。它会带着下面的实验台走一遍，你随时可以接手。
08 · 2那按样本数一乘，不就行了？
既然只看样本数，还有更省事的算法：拿最便宜的 1080p · 128（一帧 16 秒）当单价，别的档按样本数的倍数一乘。4K · 256 的样本数是它的 8 倍，所以该是 16 × 8 = 128 秒。
按这个算法，4K · 256 该是 128 秒一帧。实测是多少？
- 差不多就是 128 秒
- 比 128 秒还长：4K 更吃显存，会额外变慢
- 明显比 128 秒短
实测 86 秒，比按倍数算的少了 42 秒 C04。4K 是更吃显存（显卡自己的内存），可要是它装不下、在显存和内存之间来回倒数据（换页），实测只会比按倍数算的更慢，不会更快（第 4 节细说）。下面把五档实测都画出来：虚线是「只按倍数」，看它在哪一档准、往哪边偏。
- 来自材料
- 五个实测点（C04：4080 独占，四个偏重镜头各 4 帧取平均，2026-09-27）；三档尺寸；各档的自适应采样阈值。
- 本实验的设定
- 两条直线。「只按倍数」穿过原点和你选作单价的那一档；「固定开销 + 倍数」是浏览器对五个点现算的、离五个点最近的那条直线（最小二乘）。整片账单假设一路渲、全片的镜头都和测速镜头一样重。
- 它能证明
- 在这批镜头、这张卡上，一帧的时间 ≈ 一段固定开销 + 与样本数成正比的一段，五个点都在 ±3 秒以内。
- 它不能证明
- 换了场景、换了显卡还是这两个数；灰色区域比实测过的样本数更少或更多，那里的线是往外延伸的猜测（外推）。256 那两档的自适应采样更严（见下文旁注），spp 不是唯一在变的东西。
把「画哪条线」换成「两条都画」。虚线只在它的单价那一档准，往右越偏越多：4K · 128 它估 64 秒，实测 47；4K · 256 它估 128，实测 86。换一档当单价也一样：穿过原点的直线，总是在便宜的档估少、在贵的档估多，单价取在哪一头，只有那一头准。
五个点其实排在一条不过原点的直线上。实验台找出离五个点最近的那条线：每帧先有约 8.5 秒，之后每 1 亿个样本再加约 5 秒。前面那一段叫固定开销（per-frame overhead）：不管分辨率和采样开多少，每一帧都要花。拿 4K · 128 验一下：7.9 亿个样本 × 5 秒 ≈ 39 秒，加上 8.5 秒 ≈ 48 秒，实测 47 秒。五个点离这条线都不到 3 秒。
这 8.5 秒里具体是什么，这批数据拆不开。每帧都要做、又不随采样变的活都会落进这一项，比如 CPU 先把这一帧的场景摆好交给显卡、画完再取回来存成文件 C48。另外，采样也不是一律算满：已经够干净的像素会提前停，所以「256 次」实际算的样本比名义上少，256 那两档的点会比真算满 256 次低一点。这两个原因在这五个数里分不开，但不妨碍拿这条线估这几档。
这条线还说明一件事，实测也对得上：降档省下的，没有你想的多。4K · 128 降到 1080p · 128，样本少了四分之三，可那 8.5 秒一点没少：实测从 47 秒到 16 秒，只省了三分之二。档越低，固定开销占的比例越大；1080p · 128 那 16 秒里，差不多一半是它。
不看上面，用一句话说：为什么「只按倍数」在贵的档估得太多？
回头再看 2K 那两档：从 128 次采样到 256 次，一帧多花了 19 秒。换来的是什么？
先拆时间。按固定开销那条线，8.5 秒的固定开销一点没动；随采样变的那一段从约 18.5 秒涨到约 37.5 秒，正好翻倍。两段合起来，整帧 27 秒变 46 秒，是 1.7 倍，不是 2 倍：第 7 课说的「采样那部分跟着采样数走，整帧不到那么多」，量出来就是这个样子。再看换来的：采样翻倍，噪点只降到 1/√2 ≈ 0.71，少约三成。多花七成的时间，换三成的噪点，广州片最后留在了 128。
08 · 3同一张卡，游戏为什么只要 14 毫秒？
你问过：「为什么游戏里反应这么快，渲染却要渲染这么久？」C47 手边正好有一组对照：同一张 4080、同一个机位（沙面古榕大道），广州片用 Cycles 一帧约 16 秒，《拾光》用 UE 实时一帧约 14 毫秒，差了一千多倍。
游戏的账是倒着算的：不问「这一帧要多久」，问「这一帧最多能给多久」。要跑 60 fps，一秒切成 60 份，每帧只有 16.7 毫秒，这叫帧预算（frame budget）。摆场景、画、后期，全得挤进这一格。挤不进会怎样？广州网页版在 M4 上一帧约 17 毫秒，只比 16.7 多一点，结果被垂直同步（V-Sync：屏幕只在每次刷新的那一刻换画面）压到了 30 fps——这一帧没赶上这次刷新，就得等下一次 C10。这把尺子怎么用、游戏靠什么挤进这一格，第 10 课会细讲。
所以游戏不是「算得快一点」，是换了一套账：每个像素只算很少几次，缺的靠借前几帧、提前算好存起来的光照（烘焙）、远处换简化模型补回来（第 6、10 课）；离线的路径追踪每像素上百次采样、光线来回弹。MotionLib 那种 4 秒一帧，是 60 fps 预算的 240 倍。
08 · 4这笔账的两个前提
前面的账都默认了两件事：显卡真的在算；东西装得下。任何一条不成立，实测就会离模型差出几倍、几十倍。这时候别去调模型，去查前提。
显卡真的在算吗
红魔第一版的手机产品镜头用 Cycles（Blender 的路径追踪渲染器）渲，一帧约 100 秒，看上去 Cycles 就是这么慢。其实是从 Mac 远程登录（SSH）到 Windows 上启动 Blender、脚本里又没设渲染设备，Cycles 悄悄用 CPU 在渲；强制用显卡（OPTIX，NVIDIA 显卡的光追接口）后约 3.2 秒 C21。长卷宣传片也撞过：远程启动的浏览器跑在没有显示器的后台会话里，拿不到显卡，一帧 14.8 秒，换到桌面会话 1.1 秒——那次是你看了一眼任务管理器发现的：「Windows上的GPU都没有占用，都是用的CPU」C15。慢几十倍，账单里没有哪一项解释得了，只能是干活的设备换了；GPU 渲染几乎不读硬盘，换固态救不回来。
装得下吗
4080 有 16 GB 显存（VRAM，显卡自己的内存，和电脑的内存 RAM 是两回事）。一个有 81 个带骨骼角色的重场景（用 Blender 的实时渲染器 EEVEE 渲），单独跑占约 7 GB、每帧约 3 秒。再开一个一起跑呢？
一个重场景单独跑，每帧约 3 秒，每分钟出 20 帧。再开一个一样的一起跑，两路加起来每分钟能出多少帧？
- 约 40 帧：两路翻倍
- 还是约 20 帧：显卡本来就满了，两路平分
- 只剩两三帧
实测：两个一起跑占到 14.7 GB，每帧从约 3 秒掉到约 50 秒——开始在显存和内存之间来回倒数据了（换页）。为什么离 16 GB 还差一点就开始换页，笔记里没写；能确定的只有这两组数。两路加起来每分钟 2.4 帧，比一个一个排队慢八倍多。猜「翻倍」的，是把显卡当成了能无限分身的工人；猜「平分」的，想的是算力，没想到装不下时连一路的速度都保不住。
- 来自材料
- 两种状态的实测：单独跑约 7 GB、约 3 秒一帧；两个一起跑 14.7 GB、约 50 秒一帧（工作机笔记，2026-09-25）。
- 本实验的设定
- 每个场景按约 7 GB 画；两个场景以外的那 0.7 GB 是 14.7 减去两个 7 GB 的差，没有单独测过。每分钟几帧是用秒/帧现算的。
- 它能证明
- 装不下的代价不是慢一点，是慢一个数量级；排队比挤着快。
- 它不能证明
- 每个场景占多少显存要看场景本身；同一份笔记里，轻的 EEVEE 镜头三四个并行也没事。
显存吃紧的另外三次，后果各不一样：
| 案例 | 怎么挤的 | 结果 |
|---|---|---|
| C07 | 9 个渲染挤一张卡，其中 6 个是 SSH 断线后没人收的孤儿进程 | 显存约 15 GB，一张预览帧 611 秒；结束孤儿后约 1.3 GB，同类预览 22 秒（不是同一个镜头） |
| C16 | 长卷宣传片 6 个浏览器进程并行出帧 | 13.5–14.4 GB，其中一个进程和显卡断了连接（丢了显卡上下文），却没报错，片尾约 7.7 秒长的一段画面缺了山水；交付的封面也截自坏帧 |
| C05 | 广州片第一次开运动模糊 | 最重的沙面镜头直接崩溃：运动模糊要给几千万片树叶多存一套位置，可真在动的只有镜头、船、鸟和人 |
变慢、崩溃、静悄悄地出坏帧，三种后果里最后一种最危险，只有逐帧查画面才抓得到。规矩于是定成：重到会顶满显存的场景一个一个排队；平时这张卡上最多同时跑两个任务（全局两个名额）；每个任务带标签，退出时按标签把远端进程一起结束 C07。轻一些的镜头两路并行没问题——广州片最后就是两路一起渲的；装不下时，排队才比挤着快。
08 · 5终点任务：两天，一张 4080
把这一课合起来用。你有两天、一张独占的 4080，要渲一部 100 秒、每秒 24 帧的片。
账单还有一个省法：改了哪一段，只重渲哪一段。红魔（每秒 30 帧）v6 只动了 40.1–50.3 秒的翅膀，就只重渲 1201–1510 这 310 帧，从启动到成片约 22 分钟 C25。能这么做，是因为每一帧的画面只由这一帧的时间决定（随机数也用固定的种子），重渲的那段和前后接得上。
最后回到开头那天：估的和实际的对不上，差在哪？
带走一个问题
广州片的动态分镜是 960 × 402、每像素 16 次采样。按这一课的模型，它一帧的时间里，固定开销占多大一块？这对「先出一版低清草稿」意味着什么？模型没在这一档测过，你的答案要带上这一句。
不看上面，写下这一课撞上的几堵墙，再展开对照
- 只看分辨率，或只看采样 → 账上是样本数：像素 × 每像素采样。
- 按样本数的倍数一乘 → 每帧还有一段固定开销，档越低它占得越多，降档省不满。
- 以为游戏只是算得快 → 实时是 16.7 毫秒的预算，超一点帧率就掉一半；它每像素只算很少几次。
- 以为多开几路更快 → 显存装不下就换页，慢一个数量级，甚至静悄悄出坏帧。
- 实测比模型慢几十倍 → 先查前提：显卡到底在不在算。