本地显卡跑4小时的AI任务，云服务21分钟就完成了

有人用本地显卡跑Qwen3.8:27B，把一个2.1MB的C语言游戏转成网页版。源文件game.c大约600k tokens。模型上下文窗口只有262144，根本装不下。AI没法一次性读完，只能自己遍历文件，判断哪些代码重要。

测试环境是RTX 6000 Pro 96GB显卡。模型用FP8量化，上下文开满262144。两个代理框架跑同一份权重。hermes花了4小时18分钟，codehamr花了1小时40分钟。两者转换结果都被评为"bad“。

对照组是Claude Code云服务上的Opus 5。同一任务用了21分钟，输出1759行代码，结果评为”okay"。

测试者的判断是：本地模型的表现仍然取决于提示词。相同权重在两个框架下产出同样糟糕的结果，瓶颈不在工具，在指令本身。hermes机制更多，但单轮对话加薄弱的提示词让它没东西可用。最后花了4小时，还是同样的结果。

时间差的原因，有人用数据拆解过。基于400次调用的统计，提示处理占约70%的时间，生成输出只占30%。大部分等待时间，AI都在反复读代码。vLLM引擎会重新处理已经处理过的上下文。不用LMCache这类缓存工具的话，引擎可能花4分钟重读会话，才开始写第一个字。

硬件设置也被质疑。有评论者指出FP8 KV缓存量化可能造成严重问题，建议去掉量化再试。有人直接问测试者：有RTX 6000，为什么不用完整的bf16模型跑？

上下文压缩是另一个变量。约10%的测试运行中，上下文被压缩过至少一次，最多压缩了6次。对应的运行时间是4小时46分钟。压缩提示的质量会影响最终结果。

改进方法有两条路径。一条是先让AI写一个到目标语言的转译器，先拿到能跑的代码。再逐函数重写，严格对照高层或底层参考，才能做到像素级精确。另一条是先把大文件拆成多个小文件，加测试捕获函数行为，然后才开始移植。

这些方法能不能让本地模型达到Opus 5的水平，测试没有给出答案。一位评论者的观察解释了差距的背景：本地硬件对家庭用户来说确实不错。但对Anthropic来说，这只是四舍五入误差。云服务商能投入的硬件规模完全不同。

测试者自己也在追问：本地GPU跑了好几个小时，云服务21分钟就结束。这些小时到底花在哪了？数据给出了部分答案：大部分时间消耗在处理和重新处理代码上，而不是生成代码。缓存管理、量化精度这些细节，正在拉开本地模型与云服务之间的实际距离。