一位开发者想看看新出的 qwen3.8:27b 在“把 C 代码移植成网页版”这种硬核任务上到底行不行。他的实验对象是一个单文件 C 写的程序化射击游戏（game.c），要求在不给任何后续反馈、只发一次提示的情况下，把这份 2.1 MB、约 600k token 的 C 代码整体移植成单文件 HTML/three.js，并保留一个 bot。这个文件远超模型 262144 的上下文窗口（两倍多），所以模型必须自己读文件、摸清重点。

任务设定：39k 行 C 代码，一次提示

部署环境是 qwen3.8:27b 以 FP8 权重 + FP8 KV cache 跑在 vLLM 上，上下文开满 262144，硬件是 RTX 6000 Pro 96GB。对照组的 Claude Code 默认配置里跑的是云端参考模型 Opus 5。游戏文件大约 39k 行，实际 token 量约 60 万，所以即便窗口拉满，模型也只能看到不到一半，剩下的要靠它自己“翻文件”来理解。

实测结果：三种跑法，差距悬殊

结果按“客户端/模型、耗时时长、输出行数、效果”列出：

• Claude Code + Opus 5（云端参考）：21 分钟，1759 行，效果“还可以”（okay）。
• hermes 客户端 + qwen3.8:27b：4 小时 18 分，949 行，效果“差”（bad）。
• codehamr 客户端 + qwen3.8:27b：1 小时 40 分，1056 行，效果“差”（bad）。

视频里先放 C 原版，再按表顺序展示三个移植版。只有 Opus 移植出来的东西算“能玩”，本地模型跑出来的基本不可用。作者自己强调：每种配置只跑了一次，单轮提示面对 39k 行 C 代码本来就是极端环境，所以这不代表普遍情况。

本地模型到底卡在哪？

作者给出的判断是：本地模型仍然成也提示词、败也提示词。同一个权重在两个不同的 harness（hermes 和 codehamr）下，产生了同样糟糕的移植结果。hermes 携带了大量机制和指令模板，但单轮任务 + 很薄的提示词让它没什么可发挥，最后花 4 小时跑到了同样的坏结果。换句话说，一个复杂的 harness 救不了薄弱的提示词，只会白烧 GPU 时间。

网友对这个结论有不少共鸣。有人分享自己做过类似的事，对象是更大的代码库，他学到的关键点是：直接让 AI 转换代码，它会“重新想象”源码，结果基本没用，哪怕是前沿模型也会搞砸。他成功过的做法是：先写一个转译器把代码翻译到目标语言，前沿模型能很轻松地完成这一步；然后你会得到能运行的代码，虽然看起来像被打乱的源码，但至少能跑；最后再让模型按高/低层参考逐函数重写（比如像素比对或寄存器值），虽然慢，但最终能得到像素级完美的结果。

另有人指出，FP8 KV cache 量化可能就是问题源头之一，建议作者关掉量化、用 bf16 再跑一次。还有人说，vLLM 这类引擎会把大量时间花在“重新处理已经处理过的上下文”上——云端模型通常会把 KV cache 存在内存里，而 vLLM 如果没配合 LMCache，可能释放了缓存，导致模型被迫重新读一遍之前的内容，有时甚至要等 4 分钟才开始生成 token。如果内存足够，强烈建议加 LMCache。

怎么改才能救回来？

网友也给了不少实操建议：如果想让 Qwen 27B 干这种大活，别指望单轮直接成功。最好先让模型把大文件拆成结构清晰的多个小文件，给关键函数写测试，然后才去移植。也有人提到 Qwen 3.8 在 “xhigh” 模式下表现最好，特别适合长任务探索——如果调度模式不对，性能会差很多。还有人表示，FP8 并不是世界末日，前提是要用 LLM compressor 对模型做校准再做 KV cache 量化，直接裸用 FP8 确实会掉点；相比之下，权重量化（比如 Qwen 的 FP8 或 Unsloth 的 Q8_0）比最差的 KV 量化伤害还大。有网友直接反问：既然你有 RTX 6000，为什么不用 bf16 全精度跑？内存完全够，别省那点显存。

最后，作者附上了 C 原版和一个实验性的本地优先、无插件 harness 的地址，都在 example.cn 上，感兴趣的人可以自己去跑一遍试试。如果你也在折腾本地模型移植大项目，先把提示词做厚、把任务拆碎、把缓存管好，至少比直接“一把梭”靠谱。