它比手写快吗：把「生成 3D 场景」的效率账算清楚

它比手写快吗把「生成 3D 场景」的效率账算清楚一句提示词换来一个能直接双击打开的 Three.js 场景——这件事听起来像是在压缩工期。但只要真正跑过几轮就会发现问题不在能不能生成而在这笔时间账怎么记。Qwen3.5-4B-3D-Coder 是一个很适合用来算账的对象它是一个 4B 级、Apache-2.0 的独立微调模型基于 Qwen/Qwen3.5-4B非官方发布专门生成自包含的 Three.js 单文件 HTML 场景权重只有 2.5–8.5 GB能在消费级硬件上离线跑训练数据也公开了 4,146 条样本3,933 训练 / 213 验证。这意味着生成侧的每一分耗时都可以被拆解、复算、质疑。本文不打算给出快 10 倍这种结论而是给出一套能自己代入数字的计量框架从配置里的权重字节数推 token 速度上限从生成参数和对话模板推出一次抽卡的真实 token 预算再把它和手写路线的成本结构放在同一把尺子上。一、先把尺子校准公平计时要固定八个变量生成快还是手写快之所以争论不出结果是因为双方量的根本不是同一个东西。手写方算的是敲键盘 调灯光生成方算的是等模型吐字两边都把最贵的部分藏在了对方的账本里。口径项需要明确的定义常见的不公平做法起点从空白文件还是已知需求文档开始手写从零算生成不把写提示词的时间算进去终点能打开 / 视觉达标 / 可交互 / 可维护四档差别巨大生成方停在能渲染手写方被要求能交付思考预算是否计入think里的推理 token只报输出 HTML 的 token 数重试是否计入第 2、3 次重新生成只报成功那一次审查是否计入读懂生成代码的时间默认生成完就懂了硬件FP16 / Q8_0 / Q4_K_MGPU 还是 CPU用顶配 GPU 跑生成用手写方的旧笔记本做对比环境首次部署装运行时、关掉 MTP如何摊销一次性成本记在第一次任务上或干脆不算迭代后续第 k 次改动的成本如何计只比首版不比第 5 版后面所有推导都会标明用的是哪一档。先给结论的骨架生成式压缩的是从 0 到 1的截距手写压缩的是从 1 到 n的斜率。这两件事被混为一谈是这个话题里最大的噪音源。二、生成侧的真实耗时从权重字节数倒推本地推理的 decode 阶段基本是内存带宽受限的每吐一个 token都要把参与计算的权重从显存/内存里读一遍。所以 token 速度有一个硬上限理论 token/s ≈ 有效内存带宽 ÷ 每 token 需读取的权重字节数 实际 token/s ≈ 理论上限 × 0.5 ~ 0.7受 KV 读取、调度、采样开销影响每 token 的权重量可以从仓库里的权重文件直接读出来。model.safetensors.index.json 的元数据写着total_parameters: 4539265536、total_size: 9078531072——4.54B 参数、8.46 GiB 的 FP16 权重其中包括 24 层的视觉塔。GGUF 两个量化版的 LFS 对象大小分别是 2.52 GiBQ4_K_M和 4.18 GiBQ8_0折算下来约 4.8 bit/参数和 7.9 bit/参数。权重形态每 token 权重量相对 FP1650 GB/s 内存估算100 GB/s估算300 GB/s估算900 GB/s估算FP168.46 GiB1.00×~3 tok/s~7 tok/s~21 tok/s~63 tok/sQ8_04.18 GiB2.03×~6 tok/s~14 tok/s~43 tok/s~128 tok/sQ4_K_M2.52 GiB3.35×~10 tok/s~23 tok/s~71 tok/s~213 tok/s上表的绝对数值按带宽 × 0.5–0.7折算只用于量级判断不代表任何实测。它给出的信息很明确这台机器是台式机 DDR5、是核显、还是独显对生成成本的影响是 3–20 倍比换一个更好的提示词重要得多。一次抽卡要吐多少 token生成物是一个自包含的单文件几何体构造、灯光、材质、相机控制、动画循环全部内联官方示例里连相机控制都要求直接在 HTML 内实现不引 addons。这类场景通常在几百到两千行的量级按代码的 token 密度折算正文大约在1 万到 3 万 token。还要加上思考部分。chat_template.jinja 在add_generation_prompt时会直接写入think除非显式传enable_thinkingfalse而数据集本身也是含完整 thinking trace的。所以一次生成的实际输出预算是单次输出 token ≈ 场景代码 token1 万–3 万 思考 trace token 单次耗时 ≈ 输出 token ÷ 实际 token/s 首 token 延迟首 token 延迟prefill在这个规模下不是瓶颈500 token 的提示词按2 × 参数量 × token 数估算约 4.5 TFLOPs在几十 TFLOPS 的有效算力下是亚秒级。真正吃掉时间的是 decode。把两段拼起来得到一张抽卡耗时表按 2 万 token 输出估算场景实际 token/s估算单次生成耗时8 GB 显存 Q4_K_M~23约 15 分钟8 GB 显存 Q8_0~14约 24 分钟CPU 推理 Q4_K_M~10约 33 分钟高端独显 FP16~63约 5 分钟这张表能解释一个很多人踩过的落差在 CPU 或小显存机器上AI 秒出 3D是不存在的它是十分钟出一次。而十分钟这个数字一旦和重试相乘就变得很危险。期望次数才是真正的乘数README 里对 10 月 27 日检查点的描述是one-shot 成功率大幅提升部分场景仍可能需要再试一次或做修正但没有给出具体成功率。所以这里不编造数字只给出结构期望生成耗时 单次耗时 × E[尝试次数] E[尝试次数] 1 ÷ 一次成功率 p一次成功率 p假设值期望尝试次数15 分钟/次时的期望耗时0.52.030 分钟0.71.4321 分钟0.851.1818 分钟0.951.0516 分钟注意 p 从 0.5 抬到 0.85只省下 12 分钟而硬件从 CPU 换到独显同样一次生成能从 33 分钟压到 5 分钟。在这个模型上算力投入的边际收益高于提示词调优的边际收益——至少在单次生成的粒度上是这样。从仓库里能看到质量确实在收敛images/roma3.png记录了同一个罗马场景在 10 月 25、26、27 三个预览版本下的对比README 也提到最新的检查点同时改善了成功率与整体质量并修复了部分用户反馈的层级相关问题。这类训练侧把 p 推上去的收益是任何本地调参都换不来的。三、生成之后那段没人愿意计的时间生成结束不等于交付。这一段是账本里最容易缺失的一栏也是决定到底快不快的关键。修正成本低但必须先读懂README 的 Known issues 写得很克制目前观察到的 bug 主要是重复变量名而不是重大结构性问题。这句话的信息量比看上去大——变量重名是局部错误骨架是对的。这意味着修正路径是定位重复声明 → 改名 → 刷新页面而不是推翻重来。在 15 分钟一次生成的成本下这个判断直接影响策略错误类型修复成本估算更优策略重复变量名、少个分号1–5 分钟手改绝不重生成某个物体位置/比例不对5–20 分钟手改参数整体构图不符合意图15 分钟以上重生成或改提示词结构选错该用体素却用了曲面越改越贵重生成且先改提示词所以修正阶段的第一笔支出不是打字是读代码。一个两千行的单文件场景即使只是通读并建立心智模型也需要 15–30 分钟。这笔时间在手写路线里是不存在的——因为代码本来就是你自己写的。如果把它漏掉生成路线的成本会被系统性低估 20%–50%。环境成本一次性但会绊住第一次README 里有一条被反复转载的警告在 LM Studio 里必须关闭 multi-token predictionMTP否则模型无法正常工作而该选项默认开启。这不是玄学config.json 里有对应字段mtp_num_hidden_layers: 1——基座带一层 MTP 头量化运行时对它的支持不一致就会出现乱码或截断。除此之外还有两个容易浪费时间的点采样参数必须照抄。generation_config.json 给的是temperature 0.6、top_k 20、top_p 0.95、repetition_penalty 1.0README 面向两个量化版给的是 0.6–0.8 / 20–40 / 0.90–0.95 / 1.0。代码生成对温度敏感把温度调到 1.0 以上再抱怨结构崩了属于自找的。系统提示词是契约不是建议。仓库明确要求只使用 Three.js 0.160.0 的核心 ES 模块、不引 addons、相机控制写在 HTML 内Use only the Three.js core ES module from https://cdnjs.cloudflare.com/ajax/libs/three.js/0.160.0/three.module.min.js. Do not import addons or legacy examples/js paths; implement any camera controls directly inside the HTML.少了这段约束模型很可能写出examples/js/controls/OrbitControls.js这类早已废弃的路径产出物在浏览器里直接白屏——然后你会以为是模型不行。按一次性成本算环境搭建大约 0.5–1 小时下载 2.5 GB 权重、装运行时、关 MTP、试跑一次。如果只做一个场景这笔钱摊在单个交付物上很显眼如果做二十个它可以忽略。四、手写路线的同口径对照手写一个同等复杂度的场景成本结构完全不同。它的大头不是写几何体而是那些反复的、无法预测的调试灯光角度试十次、相机初始位置试八次、材质参数微调到看起来对、性能掉帧后回头砍 draw call。下面给一组可替换的参数而不是宣称的实测值。请把右列换成你团队的真实数据再算环节手写成本经验区间说明场景结构设计0.5–2 小时决定有哪些物体、如何分层几何体与布局编码2–6 小时最大的一块且随细节线性增长灯光与材质调优1–3 小时试错驱动难以预估相机控制与交互0.5–1 小时若允许引 addons 会更快性能与兼容性0.5–2 小时移动端、低端 GPU 会显著拉长合计单人中等复杂度单文件场景6–16 小时熟手新手请自行上浮这套数字和生成侧放在一起会得到一个很反直觉的结论生成路线首次成本 ≈ 环境摊销(0.5–1h) 单次生成(0.08–0.55h) × E[次数] 审查修正(0.3–0.6h) × E[次数] ≈ 1.5–3.5 小时 手写路线首次成本 ≈ 6–16 小时在首版这个口径上生成路线的优势是数量级的不是百分比的。即使 p 只有 0.5、即使你在 CPU 上跑、即使把审查时间算满它大概率仍然在 3 小时以内完成第一版。但账不能到这里就结束。五、真正的分水岭是迭代次数这是整个话题里被忽略最多的一层。看两个成本函数的形状生成路线: T(k) T_gen k × G G 单次迭代成本 手写路线: T(k) T_hand k × H H 单次迭代成本关键在于G和H的关系。直觉上会认为改生成代码和改自己写的代码一样快实际并非如此因为存在两种退化改不动就重抽。当你要改的是构图或结构而不是一个数值最省事的做法是回去改提示词重新生成——于是单次迭代成本退回单次生成 × E[次数]也就是 15–45 分钟。而且重抽之后你之前手工修补的 bug 全部作废。改得动也不想改。生成代码的命名、分层、抽象方式不是你的心智模型。你能改但每次改动都要重新建立上下文。这就是前面说的读代码成本它在每次迭代都要付一次。同一份代码上的第 5 次改动手写可能是改三行、刷新、30 秒生成路线可能是想清楚提示词、重跑、等 15 分钟、发现别的坏了。斜率上的差距会在第 3 到第 5 次迭代时抹平截距上的优势。用一个具体例子数字为假设用于说明形状迭代次数生成路线首次 2h每次迭代 0.4h手写路线首次 10h每次迭代 0.5h12.0 h10.0 h32.8 h11.0 h106.0 h15.0 h2512.0 h22.5 h5022.0 h35.0 h注意这张表里我给生成路线的迭代成本打了折0.4h 0.5h。即便这样差距也是线性收窄而非反超——因为真正让生成路线变慢的是结构级改动必须重抽这个阶跃而不是每次多花几分钟。把G设成 0.8h结构改动占比高时的现实值交叉点会出现在第 13 次左右。所以正确的问题不是它比手写快吗而是这个场景我会改几次。六、把结论落到团队画像上综合前面的推导可以给出一个相对明确的判断。值得转向的场景一次性或低频交付展会大屏、产品落地页的背景 3D、方案汇报里的空间示意。这类场景改 1–2 次就定稿截距优势可以吃满。仓库画廊里的十张图就是这个定位的直接证据——从樱花寺庙庭园到黄昏村落都是一格画面级别的作品。探索期的方向验证需要在一个下午看十种构图而不是把一个构图做到极致。生成路线把构图的试错成本从小时级压到分钟级这个价值远超代码质量本身。非 3D 专业的前端团队团队里没人写过 Three.js但需要一个能跑的场景。生成物是单文件、零构建、file://直接开验证成本极低。需要离线/内网交付Q4_K_M 只有 2.52 GiB8 GB 显存够用即使纯 CPU 也能跑只是慢。Apache-2.0 许可也省掉了商用授权的法务问询。机械与硬表面细节是这类模型少见的强项。LGA 3647 插槽这类针脚阵列 金属结构的题材手写的收益极低重复劳动多、构图确定正好落在生成路线的甜区不建议整体转向的场景需要精确工程约束要和 CAD/BIM 尺寸对齐、要可按参数重算的结构。生成物是看起来对不是算出来对。长期演进的产品级场景会持续迭代几十次、多人协作、需要 code review 和测试。前面第五节的斜率问题在这里是致命的。有严格性能预算移动端 draw call 上限、低端 GPU 的帧率底线。生成代码的优化目标不是性能实例化、合并几何体、LOD 这些通常缺席。需要标准资产管线GLTF 导入、材质库、动画剪辑、美术交接。单文件 HTML 是交付物不是资产。最务实的中间路线把生成当成草稿机而不是代码作者用它在十分钟内产出 3–5 个构图方向选定一个之后把生成物当成带正确空间关系的参考实现人工重写为符合团队规范的模块化代码。这样截距优势和斜率优势都能拿到——代价是你要接受写两遍。体素类场景特别适合这条路线因为它的结构本身就是数据驱动的一堆带坐标的立方体从生成物里把坐标抽成配置、把渲染循环重写成实例化渲染工作量可控七、一份可以直接抄走的计时表最后给一张表。下次有人问这东西到底快不快把这张表填完答案会自己浮出来。项目手写生成备注环境准备一次性0______ h下载权重、关 MTP、跑通需求/提示词撰写______ h______ h提示词要写主题布局风格首次产出______ h______ h生成侧 单次 × 期望次数代码通读0自己写的______ h别填 0修正至可运行______ h______ h已知问题多为变量重名修正至视觉达标______ h______ h这一栏差距最大第 2 次改动______ h______ h开始付斜率第 5 次改动______ h______ h交叉点通常在这附近硬件口径____________必须写清 FP16/Q8/Q4 与设备填完之后大概率会看到这样一个分布首次交付那一行生成侧赢得很干脆第 5 次改动那一行手写侧赢得很安静。这就是这笔账的全貌。它不是AI 取代手写而是两类成本曲线在不同区间各占上风。真正需要判断的从来不是模型有多快而是你手上的这个 3D 场景究竟是一次性的画面还是要养两年的资产。顺带说一句架构上的余量这个模型的 32 层里有 24 层是线性注意力、只有 8 层是全注意力full_attention_interval: 44 个 KV 头 × 256 维KV cache 大约 32 KiB/tokenFP16。喂 3 万 token 的上下文也只占约 1 GB配上 Q4_K_M 的 2.5 GiB 权重8 GB 显存仍有富余——这意味着把整个现有页面丢进去让它改这种用法在显存上是可行的。但在时间上它仍然要按前面那张抽卡表来算。显存够不等于迭代便宜。创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考