CARLA & Unreal Engine: 0.9.15 vs 0.10, Part 2
同步模式下的 FPS 指服务端每秒能推进多少个 tick（世界步数），不是显示帧率。固定步长 0.05 s/tick 时，换算成实时倍率：
本机实测（RTX 5090，Epic 画质，720p，Town10HD，CP0 冒烟报告口径）：
| UE4（0.9.15） | UE5（0.10.0） | |
|---|---|---|
| 同步 FPS | 97.6 | 42.3 |
| 实时倍率 | ≈ 4.9× | ≈ 2.1× |
同一张卡、同一画质，——UE5 慢了 2.3 倍。
闭环评测的可行性门槛是实时倍率 ≥ 1：仿真世界跑得比真实时间快，实验才排得进日程。42.3 FPS 意味着 UE5 侧每跑 1 秒仿真要花约 0.47 秒墙钟——看起来宽裕，但要注意这是纯世界推进，还没算模型推理占的时间。VLM 类模型（如 SimLingo）单帧推理 0.7–1 秒量级，远大于 tick 本身的 24ms，实际闭环吞吐由模型主导，server FPS 只是预算的第一项。
这组数字可比的前提是四同：同机（同一张 RTX 5090）、同配（Epic 画质 720p）、同图（Town10HD）、同模式（同步）。任何一项不同——比如换画质档、换异步模式——数字就不可比。这组基线也用于后续所有实验的墙钟外推：采数、评测的排期全部按 42.3 / 97.6 折算，不拍脑袋。
吞吐（throughput）：RGB 720p 连采五分钟，UE4 侧每秒 110.1 帧、UE5 侧每秒 40.4 帧，两侧零丢帧（CP0 冒烟实测）。吞吐的天花板在数据链路的每一段都可能出现：GPU 渲染 → 显存回读 → 序列化 → TCP 传输 → 客户端反序列化。UE5 侧慢，瓶颈在源头——渲染本身只有 42.3 FPS，传感器流不可能比世界推进更快。
延迟（latency）：RPC 往返实测 UE4 侧 30ms、UE5 侧 43ms。这条链路是 WSL2 客户端 → 虚拟交换机 → Windows 宿主 server，跨操作系统边界，比普通 localhost 通信贵一个量级。
丢帧与否不取决于带宽，取决于模式：同步模式下 server 推一步就等客户端，数据必然对齐到齐；异步模式下客户端跟不上就丢。所以”两侧零丢帧”说明的不是网络好，而是评测口径正确——数据质量两侧无差异，差的只是速度。
排期算账要把这两项都折进去：
以 UE5 侧为例：tick 24ms + RPC 43ms + SimLingo 推理 ~700ms 起——模型占绝对大头，但 RPC 的 43ms 在每个 tick 都要付一次，长路线累计不可忽略。所有评测/采数任务的墙钟估计都按这个公式用实测值外推，这是本项目排期的基本纪律。
实测占用（CP0 口径）：
| 占用方 | 显存 |
|---|---|
| UE4 server（Epic 720p） | ~8.1 GB |
| UE5 server（Epic 720p） | ~9 GB |
| 模型推理 | 6–13 GB（AutoMoT 官方栈 bf16 约 13 GB） |
两台 server 的”地租”相差不到 1GB——渲染保真度的代价主要付在帧率上，不是显存上。真正贵的是模型。
一张 32GB 的卡：
这个边界直接催生了项目的 GPU 任务分级调度：同一时刻只允许”重任务组合”的一种形态在卡上，跨侧实验排队而非并行抢卡；采数/评测一律后台跑。显存预算不是性能优化问题，是实验能否并存的硬约束。
同机多显示适配器时（本机在册 3 个虚拟显示适配器 + Intel 核显 + 5090），-graphicsadapter=N 的枚举顺序两侧不同：UE5 侧 =2 选中 5090，UE4.26 侧 =0 才是 5090（=2 时 5090 显存平躺、同步仅 13.9 FPS，数据作废特征明显）。且索引会随重启漂移。所以启动流程必须带 nvidia-smi 显存增量校验——server 起来后显存应比基线涨 4GB 以上，不涨就是选错了卡。
专门做了”UE5 server + torch 模型同卡”的压力实测（T0.5，CP0 报告）：
| 组合 | 显存总量 | 结果 |
|---|---|---|
| UE5 server + torch 占 8GB | 29.5 GB | PASS |
| UE5 server + torch 占 13GB（≈ AutoMoT 级别） | 32.6 GB | PASS，帧率仍有 43 FPS |
结论：显存打满到 32.6GB 也不崩、不降速——UE server 的显存是启动时占住的”地租”，压力来自宿主内存而非显存余量。
UE5 server 在 GPU 之外还吃掉宿主内存约 10GB。压测发现：WSL 侧压 30GB + UE5 server 时，按原 .wslconfig 56GB 口径，宿主空闲内存只剩 2.9–3.2GiB——FAIL。修法是把 WSL2 降档：memory=32GB / processors=16 / swap=16GB。降档后复测：WSL 压 28GB + UE5 server 驻留 4 分钟，宿主空闲稳定 12.9–14.5GB（≥6GB 判据 PASS），释压后 60 秒冒烟回归 PASS（同步 41.9 FPS、RGB 零丢帧）。
WSL2 默认按宿主内存的一半动态申请，且不主动归还。宿主要同时养 Windows 桌面、两台 UE server（各约 10GB RAM）、远程桌面服务——WSL 不设上限，最坏情况下宿主被挤到无内存可用，先死的往往是 server。.wslconfig 降档的本质是给宿主留出门禁余量：用 WSL 侧的确定性约束换整机的确定性存活。这类”门禁实测”（给定压力组合、定 PASS/FAIL 判据、复测回归）贯穿本项目，每个资源决策都要有一次压测背书。
UE4 的画面便宜，因为大量成本在离线付掉了：光照贴图预先烘焙，运行时只查表；LOD 由美术预先砍好，运行时只画简化模型。UE5 把这两笔账都挪到了每帧：Lumen 每帧实时算光线弹射（SDF 求交 + 表面缓存 + 时域滤波），Nanite 每帧做层级簇剔除和微三角形软件光栅化。97.6 → 42.3 的落差，就是”预计算”和”实时算”的差价。
官方内测口径下 0.10 的峰值只有约 25 FPS。本机 RTX 5090 跑出 42.3，已明显高于官方参照——5090 的算力红利吃到了一部分，但吃不平管线路径的本质差异。
42.3 这个数的定性很重要：这是渲染管线的真实差异，不是 bug。所以它不进”待修清单”，而是进”基线常量”——后续所有实验设计（采数排期、评测墙钟、双实例并发）都把 2.3 倍慢当成已知条件内嵌进去。排期公式里它是除数，不是变量。
这个区分（“真实差异” vs “待修问题”）是实测文化的一部分：看到一个”坏”数字，先问它是缺陷还是物理。判据是看机制——慢的每一毫秒都能指到 Lumen/Nanite 的每帧开销上，机制闭合，就是真实差异。
CARLA 0.10 只有两张图：Town10 重制版 + 一张矿场图。UE4 资产进不了 UE5——Lumen 要按动态全局光照重做材质与光照，Nanite 要按虚拟化几何重导网格——所以 0.10 的 Town10 是从资产层整个重做的。
结果是微妙的中间态：路网有血缘，几何近似，但材质、光照、细节全新。同名路线可以在两侧复刻（同一组起点终点、同一个路口拓扑），但没有任何一个像素能对齐。
成对渲染对比的可行粒度只能是语义对齐：同一条路线路径、同一个机位语义（路口中心、朝向相同），接受米级几何偏差和完全不同的外观。本项目 M3 的成对采图（两侧 Town10 布置对齐相机位姿）就是这个口径。
这张”唯一的城”同时是限制和礼物：
看两侧的成对画面时，“UE5 更真实”是观感结论；实验结论只能是”输入分布换了之后模型行为怎么变”。画面差异是手段不是结论——同一坐标两座城，对模型是两份不同的考卷，成绩差才是数据。
来源：官方发布说明与社区 issue，本项目调研报告 §2.1 核实。
对待技术预览版限制有两条路：掩盖它，或把它编进实验设计。本项目走后者：
这个思路的通用心法：限制若能同时施加于对照组两侧，就从缺陷降级为边界条件。真正危险的不是有限制，而是两侧限制不对称——那才是混杂变量。
四条限制贯穿全程，所以本项目所有结论都必须反复声明边界：结论成立于”Town10、白天、11 款车型、自建评分”的口径内。0.10.1+ 若补齐地图与 ScenarioRunner，结论要重新评估——对照实验的结论从不超出它的边界条件。
0.10 的车型只有 11 款，而且蓝图命名和 0.9 不延续：0.9 侧常用的英雄车 vehicle.lincoln.mkz_2020 在 0.10 不存在，要用老名字 vehicle.lincoln.mkz（T2.1 实测）。测试车两侧也不同：UE4 侧用 vehicle.audi.tt，UE5 侧用 mkz——对比实验的英雄车必须在两侧各自确认存在后统一，不能想当然沿用 0.9 的清单。
官方标注 0.10 传感器”有黑屏 bug”。本项目冒烟用脚本枚举探测了 14 个传感器：全部正常。RGB / GNSS / IMU / LiDAR 主力传感器均已迁移。
两个事实放在一起才是完整教训：技术预览版的官方清单要逐项实测。官方的”有 bug”可能已被修、可能只在特定配置触发、可能根本就不在你用的传感器上；反过来，官方没标 bug 的地方也可能埋雷（mkz_2020 消失就是文档没写的事）。对一个技术预览版，唯一可信的清单是自己 probe 出来的那份。
本项目做法：接触任何技术预览组件前，先写一个枚举式 probe——列出所有可用车型蓝图、逐个 attach 传感器取一帧验证——把”官方声称”变成”本机实测”再进设计。这一步的成本是小时级，被坑一次的成本是天级。
ScenarioRunner 和 Leaderboard 在 0.10 上不工作，意味着 Bench2Drive 提供的三样东西全部要自建：
本项目的答案是自写 route 执行器和评分器，罚分系数与 Bench2Drive 对齐——评分公式同源，UE5 侧的 DS 才能和 UE4 侧（以及官方榜单）放在同一刻度上比。对齐系数而不是自创系数，是因为研究问题问的是”渲染差异的影响”，不是”新评分体系下的表现”；评分函数一变，又多一个混杂变量。
背景车流也是变量：leaderboard 原密度（瞬时约 15 辆）在对齐短路线上会互堵，模型礼让导致路线超时、墙钟爆炸。两侧的修法：
密度不对齐，DS 差可能是”交通更堵”而不是”渲染更真”——又一条混杂变量的封堵。
代价是实打实的：自建闭环评分链后续踩了十二轮坑才收敛。回报是评分逻辑两侧同源——这是全部对比结论的可比性根基。生态断层逼出来的自建，最后反而成了方法论的资产。
| 档 | 做法 | 回答什么 |
|---|---|---|
| UE4 基线 | 官方权重回 Bench2Drive 考一次 | 锚点：模型在”母语世界”的真实水平 |
| UE5 zero-shot | 权重不改，直接进 UE5 闭环 | 自变量的效应：渲染+物理变化带来多少域差距 |
| UE5 微调 | UE5 自采数据上微调，再考 | 可回收性：适应能挽回多少损失 |
三档之间的铁律：同模型、同路线、同评分——差异只保留渲染与物理两项。任何一档换模型或换评分，比较就失效。
三档里信息密度最高的是第二档：它把”引擎升级”这个干预直接施加在 frozen 权重上，DS 变化量就是域差距的行为学度量。主模型 SimLingo（纯视觉）与第二模型 AutoMoT（动作分支含 LiDAR）的对照也落在这一档——LiDAR 吃几何不吃画面，AutoMoT 的 DS 变化预期更小，它本身就是”渲染敏感度”的内置对照组。
| 档 | DS | 备注 |
|---|---|---|
| UE4 基线 | 49.59 | 噪声带 12.91，卡死翻转主导 |
| UE5 zero-shot | 56.35 | Δ+6.76 < 噪声 20.74，按”不显著”口径 |
| UE5 微调 | v1/v2 判废归档 | 微调对训练/评测管线错配极端敏感，单独成集剖析 |
两个读数纪律：一是 DS 个位数差异落在跨 seed 噪声带内，“UE5 zero-shot 不降反升 6.76 分”不能读成”UE5 画面有帮助”，只能读成”该口径下无显著退化”；二是微调档的两次失败不是噪音而是结论素材——闭环微调对训练/评测预处理约定（裁剪、坐标、target_point 语义）的错配极端敏感，这本身就是有价值的负结果。