Can a Local AI Cluster DESTROY Claude Fable? | GLM 5.2 + Kimi K.27 🤯

GLM 5.2与Kimi K.27本地集群配置详解

本期节目旨在进行一场终极对比，测试GLM 5.2、Kimi K.27以及付费模型Gemini Pro和Claude Fable在生成3D游戏时的表现。为了给予开源模型最佳机会，主播升级了本地部署配置：GLM 5.2从之前的4.8位量化提升至5.8位量化，并在Mac Studio和MacBook Pro上通过分布式计算运行。同时，Kimi K.27也从3.5位量化提升至4.24位量化。这种高比特量化带来了显著优势，例如在数学测试中无需开启“思考”模式即可得到正确答案。虽然本地AI生成耗时较长，但主播指出这为未来硬件普及预留了空间。

"I made an even bigger one, a 5.8 bit quant and I'm running this on my Mac Studio..."

Gemini Pro与Claude Sonnet的失败案例

在确立基准前，主播首先测试了付费服务Google Gemini Pro。尽管Gemini曾被视为行业标杆，但其生成的“3D超级马里奥世界”表现糟糕：碰撞检测失效且角色无法正确移动。当被质疑时，Gemini承诺改进但结果依然平庸。相比之下，Claude Sonnet Max Thinking版本则因免费额度耗尽及引用错误而无法运行。这些付费模型的失败为后续开源模型的表现提供了鲜明的对比背景，突显了当前商业AI在复杂代码生成上的局限性。

"This is a pathetic generation from a paid service online Google Gemini Pro."

GLM 5.2不同思考模式下的性能对比

GLM 5.2在关闭思考模式下生成了16,000个Token，耗时约23分钟（1400秒），速度约为11.5 Token/秒。生成的游戏《Sky Hopper》具备奔跑、跳跃和鼠标控制镜头功能，视觉效果优于Gemini。开启高思考模式后，生成量增至24,000 Token，游戏角色形象更贴近水管工且包含声音和移动平台。在最大思考模式下，生成量高达44,000 Token以上，速度略降至10.5 Token/秒。尽管本地运行速度慢于云端，但GLM 5.2在功能完整性和可玩性上全面超越了Gemini Pro，证明了高量化开源模型的潜力。

"This is an amazing generation... He can run, he can jump."

GLM 5.2 在低量化下的《超级马里奥》生成表现

在本片段中，创作者测试了 GLM 5.2 模型在 4.8 bit 量化下的代码生成能力，重点考察其在减少内存占用时的稳定性。尽管降低了精度，模型生成的游戏依然 可玩，且保留了如双跳等核心机制。虽然存在浮空砖块轻微裁剪的问题，但整体动态水平与高量化版本相似。随后切换至 Max Thinking 模式，在单台配备 512GB 内存的机器上运行，生成了 51,000 tokens 的代码。该版本呈现出极高的视觉质量，角色设计类似羊驼且拥有生动的表情与音效交互，被评价为 Bravo 级的生成效果。创作者指出，此次测试未使用任何代码修正或 Harness 框架，完全依赖模型单次提示词的原始输出能力。

"I didn't actually have to correct anything... This is just straight up raw"

Kimi K2.7 代码版在《超级马里奥》中的对比测试

接着，视频转向开源模型 Kimi K2.7 的代码版本测试。在禁用思考模式下，该模型生成了 8,300 tokens 的代码，但存在一定错误。启用思考模式后，模型增加了约两把抓（two handfuls）的推理规划，却仅生成了 8,500 tokens 的代码量。这一现象表明，思考模式消耗了部分 token 预算用于推理而非代码生成，导致最终产出略少。尽管生成的《超级马里奥》版本中角色外观不佳且存在 Bug，但在该特定对比场景中，GLM 5.2 被认为赢得了展示。创作者建议用户若拥有 Claude Sonnet 访问权限，可尝试相同提示词以进行跨模型对比。

"Maybe you're better off making it do the code and then correcting it rather than getting it to think"

《Out Run》赛车游戏的生成质量与调试过程

在《超级马里奥》测试后，创作者要求 Kimi K2.7 生成经典赛车游戏 Out Run。禁用思考模式下，模型仅用 7,000 tokens 生成了一个基础但视觉效果不错的版本，包含3D汽车、树木和道路。启用思考模式后生成量激增至 25,000 tokens，但引入了方向控制反转（左变右、右变左）的 Bug。尽管进行了调试，道路质量仍不如禁用思考版本，且车辆存在渲染裁剪问题。相比之下，GLM 5.2 在 Q5.8 bit 量化下生成 22,000 tokens，虽首次出现菜单屏幕问题需修正，但后续版本展现了精致的街机风格加载界面与霓虹灯光效果。Max Thinking 模式则因上下文窗口限制需分多轮生成，总计产出 90,000 tokens 的代码。

GLM 5.2赛车游戏生成：单提示词下的性能与局限

在本地集群测试中，GLM 5.2生成赛车游戏最后20,000个token耗时3,000秒，总生成时间约一个半小时。尽管是单提示词（one-shot）生成，游戏已具备基础功能：车辆可左右转向、存在碰撞检测及检查点系统。然而，转向逻辑不够激进是主要痛点，车辆仅轻微右偏导致无法顺利超车。虽然存在缺陷，但生成内容包含90,000个token的完整代码结构，显示出巨大的开发潜力。作者指出，随着AI降低游戏开发门槛，未来将出现大量“快餐式”粗糙作品与精心打磨的精品并存的市场分层。

"The steering is a bit not as aggressive as I hoped it to be. So, it only steers slightly to the right..."

Kimi K2.7迭代优化：从糟糕初稿到完整体验

Kimi K2.7通过Visual Studio Code插件进行开发，其迭代优化能力显著优于一次性生成。初始版本被评价为“糟糕”，但在多次提示词修正后，游戏质量大幅提升：增加了引入过场动画、人群欢呼特效及引擎音效。最终版本支持车辆左右行驶与道路碰撞，虽存在向左偏航的小bug，但整体完成度较高。作者认为Kimi在视觉推理（visual inference）方面具有GLM 5.2暂时无法匹敌的优势，即能直接根据网页截图复现页面。在赛车游戏对比中，两者表现不相上下（neck and neck），但Kimi的多轮迭代机制使其在复杂功能完善上更具灵活性。

"I told it make it better this game on YouTube and then it started improving the generations..."

地图系统终极对决：GLM本地推理击败Claude Fable

在最后的挑战中，测试对象为城市交通地图系统。基准模型Claude Fable（耗时1小时生成）存在严重缺陷：铁路地图逻辑错误、不支持移动端点击交互，且因过于优秀曾被下架。相比之下，GLM 5.2在本地运行（无互联网访问权限）表现惊人：在高思考模式下，仅用34,000个token即完成生成，无无限循环错误。GLM生成的地图支持城市点击交互并显示完整铁路系统，虽存在飞行图与铁路图重复的bug及坐标精度问题（可能因量化导致），但其零修复代码直接可用的特性，以及在离线环境下依靠模型记忆重建数据的能力，使其在稳定性与交互性上全面超越Fable。

GLM 5.2 地图交互与移动端适配测试

在对比本地模型生成的交互式地图时，GLM 5.2 的表现优于 Claude Fable。虽然两者都支持点击城市并显示动画，但 GLM 在移动端视图下能正常渲染，而 Fable 在此模式下直接失败。此外，GLM 生成的地图允许用户通过鼠标缩放和拖动屏幕，且能搜索特定城市（如纽约）。尽管 Fable 也具备搜索功能，但 GLM 在交互完整性上更胜一筹。值得注意的是，GLM 生成的地图中包含了阿拉斯加作为美国的一部分，而 Fable 的生成结果中缺失了该区域。

"I can see Alaska as part of the United States of America. Whereas, Fable, there is no Alaska."

高思考模式下的代码生成与代理式工作流

在启用 Max Thinking Mode（最大思考模式）后，GLM 5.2 消耗了 97,000 tokens 的上下文窗口，生成过程耗时极长。由于原始输出包含错误且文件过大（约 60,000 tokens），测试者采用了代理式工作流，仅要求模型输出特定的函数代码变更而非重写整个文件。这种策略避免了数小时的额外等待时间，体现了在本地大模型开发中精准指令优化的重要性。生成的地图支持点击城市查看交通估算，例如显示驾车需 6 小时、飞行需 11 小时（尽管数据准确性存疑，如皮尔到丹佛的飞行时间），且所有地理信息均源自模型内部记忆，未联网获取。

"I was saying like, just output the function... rather than give me the whole file again."

Kimi K2.7 表现及底层渲染引擎对比

在最后一项测试中，通过 Kimi Code Agent 运行 Kimi K2.7。其生成的地图支持缩放和移动端显示（虽仅占半屏），但在火车路线映射上同样出现错误，与 Fable 和 GLM 类似。Kimi K2.7 在飞行路线映射上表现较好，能准确显示机场节点。测试者指出，不同模型使用了不同的底层渲染引擎：Claude Fable 使用 MapLibre 和 React，GLM 5.2 使用 D3.js，而 Kimi K2.7 使用了 Carto（被可口可乐和福特使用）。尽管 Kimi 在部分交互上略有优势，但 GLM 因其在移动端的完整性和可点击性被认为在地图测试中获胜。

"Kimi K 2.7 was using Carto... it's used by Coca-Cola and Ford, so that is a situation right there."

GLM与Kimi在分布式计算下的生成质量对比

在本次测试中，GLM 5.2模型在4.8位量化下虽然出现少量错误，但在5.8版本运行于分布式计算时表现稳定，未观察到明显Bug。生成结果呈现出“美丽的画面”，显示出较高的稳定性与视觉完整性。相比之下，Kimi K.27的表现稍逊一筹，主要问题在于画面出现了“off-road”（偏离主题）的情况。尽管其中包含了一列火车等壮观元素，但整体存在明显的细节丢失。

"It looks like a beautiful generation over there. And with Kimiko, once again, this one doesn't look as good cuz he's doing a bit of off-road."

这种差异可能源于量化过程中的精度损失，或是模型本身在图形生成能力上的局限。Kimi未能完全还原预期的复杂场景结构，导致视觉连贯性受损。这表明在本地部署环境下，不同开源模型对量化敏感度的差异会直接影响最终输出的可用性。

超级马里奥生成案例与Fable模型的失误分析

视频作者认为，GLM在开头生成的超级马里奥场景堪称“壮观”，因此将比分判给这一方。该案例展示了开源模型在无互联网连接、无外部纠正机制的情况下，仅凭一次90,000 token的提示词就能产出高质量内容的能力。相反，Claude Fable的表现令作者失望。尽管外界报告称其为“自切片面包以来最好的东西”，但实际生成中暴露出多处错误。

"I think the Super Mario generation at the beginning with a GLM was just spectacular. So, I'd have to give the points to that one."

具体而言，Fable无法正确生成铁路结构，且缺乏“Look at that target”等高级交互机制。此外，该模型在移动设备上的兼容性存在问题，未能实现预期的功能。作者强调，开源AI模型在无网络、无辅助修正的“直出”模式下表现出的鲁棒性，远超预期。

观众互动与对AI生成人类形象特征的观察

在视频尾声，作者邀请观众投票决定“谁赢得了比赛”，并表达了对开源模型表现的惊讶。尽管Fable在理论上被推崇，但实际表现不及本地部署的开源模型。作者特别提到一个有趣的细节：生成的AI角色拥有“恶魔角”，这引发了关于这些AI模型为何倾向于认为人类具有此类特征的讨论。

"You also have devil horns. But there's something going on that these AIs think we look like."

此外，作者展示了一个拥有“美丽动画眼睛”的生成案例，并称赞其发型具有2029年未来感风格。他幽默地指出，这种发型让人联想到埃隆·马斯克（Elon Musk）的脑机芯片植入后的形象。这一部分不仅总结了技术对比，还通过幽默的观察点收尾，强调了AI生成内容在细节拟人化上的独特趣味。

结论

测试表明，GLM 5.2在本地集群部署下具备显著优势。其在高量化配置及离线环境下，能稳定生成可玩的3D游戏与交互地图，且在移动端适配、代码零修复直接可用性及视觉完整性上全面超越Claude Fable与Gemini Pro。相比之下，Kimi K.27虽在视觉推理和多轮迭代优化上表现灵活，但单次生成的稳定性与细节还原度稍逊。总体而言，开源模型在复杂代码生成上的鲁棒性已超越部分付费标杆，但本地运行的高耗时及量化导致的精度损失仍是主要短板。