4B模型微调实战：Three.js 3D场景生成能力持续提升

小模型也能玩转3D场景生成

最近，一位开发者在Reddit上分享了其4B参数模型微调项目的最新进展。该项目基于Qwen3.5-4B进行通用编码能力的微调，并以Three.js场景生成作为核心测试任务。从最新checkpoint的生成视频来看，模型在场景质量和一次通过率上都有肉眼可见的进步——虽然首次尝试仍会搞砸部分场景，但整体趋势令人鼓舞。

这个项目最吸引人的点在于：它证明了小参数模型在特定编码任务上，通过持续微调可以逼近实用水平。作者坦言"仍然好奇这个小4B能推到多远"，这种探索精神正是开源社区最宝贵的部分。

技术路线与当前进展

微调策略与测试基准

作者选择Qwen3.5-4B作为基座，瞄准"通用编码"能力进行微调，而Three.js场景生成则充当了天然的评测场——它同时考验代码语法正确性、空间逻辑和API调用准确性。这种"用生成任务反哺编码能力"的思路，比单纯刷HumanEval分数更贴近真实开发场景。

目前模型仍处于训练中，最新checkpoint在场景质量和一次成功率上均有"明显提升"。作者没有给出具体百分比，但强调"更新后的checkpoint确实更好"，并已同步更新Q4_K_M和Q8_0两个量化版本。

Qwen3.5-4B 是阿里通义千问^广告系列中的小尺寸基座模型，4B 指约 40 亿参数。相比 7B、14B 等更大规模模型，4B 模型对显存和算力的要求更低，经过 INT4 量化后可在 8GB 显存的消费级显卡上运行，适合本地部署与快速迭代。选择它作为微调起点，意味着作者优先考虑的是可及性与训练成本，而非追求榜单最高分。

Three.js 是浏览器端主流的 WebGL 封装库，开发者通过 JavaScript 调用其 API 即可创建 3D 场景、相机、光照与材质。用自然语言生成 Three.js 代码，要求模型同时掌握 API 名称、参数顺序和三维空间关系，比纯文本代码生成更难，因此常被用作检验编码模型结构化推理能力的测试任务。

量化文件修复与社区反馈

值得留意的是，作者专门修复了此前部分用户遇到的层（layer）问题。这意味着早期量化版本可能存在兼容性缺陷，而这次更新让模型在更多本地环境上可以正常运行。对于想在自己机器上跑起来的开发者，这无疑是个好消息。

作者也鼓励试用的用户反馈"什么能跑通、什么会崩"——这种对失败案例的渴求，恰恰是迭代小模型最需要的养料。

量化是将模型权重从 FP16 等高精度格式转换为 INT8、INT4 等低精度格式的过程，可大幅降低显存占用和推理延迟，代价是少量精度损失。GGUF 格式配合 llama.cpp 生态常用的 Q4_K_M、Q8_0 等量化方案，分别代表 4 位和 8 位混合量化等级，数字越大精度越高、体积越大。所谓“层问题”，通常指某些网络层在量化后数值溢出或反量化出错，导致模型输出乱码或直接崩溃，需在转换脚本中针对性处理。

训练计划与后续发布

按照作者的规划，训练预计在10月28日07:30 UTC左右完成。之后会一次性放出全套资源：

• 完整的FP16权重
• 所有量化版本
• 训练数据集
• 技术报告

更关键的是，作者一直在保存每个checkpoint的测试结果，计划用多组提示词做横向对比，形成一份"模型训练全程进化报告"。这种透明度在个人微调项目中并不多见，对想复现或借鉴的开发者来说价值很高。

小模型微调的意义与观察

4B级别的模型能在本地消费级硬件上运行，如果能在Three.js这类结构化代码生成上达到可用水平，意味着独立开发者和小团队可以用极低成本搭建3D场景原型工具。当然，目前模型"首次尝试仍会出错"，距离生产级可靠性还有距离，但一次成功率的持续爬升说明方向是对的。

从社区反馈看，大家最关心的还是量化版本的实际表现和训练数据的构成。等10月28日全套资源发布后，这些疑问应该会有更清晰的答案。如果你对小型编码模型感兴趣，不妨下载当前checkpoint试试，并把踩到的坑反馈给作者——毕竟，小模型的进步往往就藏在这些真实用例里。