本地 27B 裸 C 写体素引擎，对比 Opus 4.8

Reddit 用户 codehamr 在 r/LocalLLaMA 发布了一项「周日实验」：让 Claude Opus 4.8 与本地部署的 Qwen3.6 27B 接收同一段提示词，用裸 C（不使用任何引擎、游戏库或框架）写一个体素世界，并对比二者在底层系统编程任务上的实际表现。

实验设置

两侧使用完全相同的提示词，规则非常严格：只能用编译器，不得引入任何引擎、游戏库或框架，模型必须自己完成 chunk meshing、渲染循环与内存管理。

• 左侧（云端）：Claude Code，运行于 Opus 4.8
• 右侧（本地）：Qwen3.6 27B，运行于 vLLM，搭配新发布的 NVFP4 量化与 256k 上下文窗口
• 硬件：RTX 6000 Blackwell 96GB，本地推理约 130 TPS
• 调用方式：通过作者自建的 coding agent 接入

两端表现

在体素物理层面，Opus 4.8 明显占优：地形保持稳定，chunk 边界对齐正确，碰撞检测可正常工作。而 Qwen3.6 27B 虽然能完成编译并启动渲染，但在屏幕上「自我撕裂」——画面出现破洞或错位，输出不稳定。

作者表示，质量差距在意料之中，真正让他意外的是 27B 本地模型居然能处理纯 C 这一层。

一个意外的观察

作者指出，目前大多数本地模型演示都是 Python 或 TypeScript，框架承担了绝大部分实际工作；一旦把框架剥掉，只剩裸指针与手动内存分配，量化模型通常会直接崩溃。本次实验中的 27B 并没有崩溃，只是渲染结果有缺陷。

他在帖子中写道：

两年前，这个提示词给本地模型跑出来的结果是一个 segfault；现在跑出来的是一个虽然有缺陷、但仍然能在你桌子底下那块显卡上跑起来的世界。天花板几乎没动，但地板在冲刺。

对社区的意义

帖子讨论的核心并非前沿模型的极限在哪里，而是本地小模型的「地板」在过去两年中被显著抬高。对关注本地推理、开源模型能力边界的开发者而言，这是一个具体且可复现的代码生成观察：NVFP4 量化的 27B 模型，已能在消费级/工作站级显卡上完成原本被视为小模型能力边界的裸 C 系统编程任务。