如何用 GLM 5.2 Fast 在四天内完成一个月的工程工作量
作者使用 FireConnect 上的 GLM 5.2 Fast 模型，在 Claude Code 的辅助下，仅用四天时间和 218 美元的推理成本，完成了一项通常需要一个月才能完成的 GPU 调度器回收功能。文章详细介绍了问题背景、工作流程（设计、规划、实现）以及成功的关键因素：快速推理消除了上下文切换成本，低成本消除了对 token 使用的顾虑，模型质量保证了复杂逻辑的正确性。
GLM 5.2 Fast 已在 Fireworks 上发布，提供 Opus 级别的智能性能和开源模型的价格，无需合同，按 token 付费。最近，一位资深工程师利用该模型完成了一项通常需要一个月才能完成的任务，仅用了四天时间和 218 美元的推理成本。
作者 Shoucong Chen 在 Fireworks AI 负责 GPU 调度系统的开发。他想要为系统添加一项“回收”能力，其理念类似于 Linux 的页面缓存：内核将空闲内存视为浪费，用缓存填满闲置内存以加速一切，但当应用程序真正需要内存时，内核会立即归还。作者希望为 GPU 容量实现同样的特性：将闲置的 GPU 容量用于工作，同时保证受保护的任务在需要时能立刻获得优先级。
这个功能并非易事，它涉及调度逻辑中最关键的部分，需要深厚的领域知识（Kubernetes 内部机制和 Fireworks 调度细节），有多种设计方案且各有权衡，必须在并发环境下保证正确性，还需要处理大量边界情况。过去，这类工作通常需要一名工程师花费一个月的时间。
作者将项目分为三个阶段，每个阶段都让 GLM 5.2 Fast 作为合作伙伴。
设计阶段（约 1 天）：作者将 GLM 5.2 作为设计伙伴，迭代确定回收逻辑在调度路径中的位置以及如何与正常放置决策交互，最终与团队达成一致。传统上，仅此阶段就需要约两周时间：阅读代码、与人交流、研究行业解决方案、编写设计文档并运行设计评审。由于 GLM 5.2 Fast 的推理速度约为 400 token/秒，响应在几秒内完成，使得协作如同实时白板讨论，无需上下文切换。相比之下，即使使用前沿的封闭模型，这一阶段也需要两到三天，大部分时间花在等待和重新集中注意力上。
规划阶段（约 0.5 天）：作者进入规划阶段，将实施计划迭代至“可实施”状态。他采用规范驱动和测试驱动的方式，让 GLM 5.2 预先编写测试覆盖——16 个单元测试和 18 个集成测试，涵盖所有能想到的边界情况。在编写实现代码之前锁定 34 个测试，使得后续阶段可以安全地交给模型。
实现阶段（约 1.5 天）：GLM 5.2 根据规划实现了 4 个 PR，共约 3000 行代码，所有 34 个测试通过，CI 变绿。在此过程中，GLM 5.2 和 Claude Code 循环迭代，目标是所有测试必须通过，直到达成。大部分实际时间花在运行集成测试上，而非模型思考。
作者总结了成功的关键因素。首先，速度是倍增器：当响应在数秒内到达时，工作成为实时讨论，作者提出想法 A、B、C，并让模型从第一性原理挑战它们。慢速推理会打破循环——等待 15 分钟会导致注意力分散。其次，低成本消除了 token 使用的顾虑：作者不必像使用封闭模型那样自我限制使用量，从而可以全力依赖模型。最后，质量经得起考验：尽管涉及并发和边界情况的复杂调度逻辑，但强大的开源模型、测试驱动的规划和可靠的框架共同保证了质量。
最终，作者在四天内完成了通常需要一个月的工作，总推理成本仅为 218 美元。他感慨道，AI 的承诺本应是消除工程中的苦差事，但实际上许多人只是从打字变成了切换标签页、等待缓慢的代理并付出注意力切换成本。这个项目让他相信，承诺已经成真。当模型在你伸手切换标签页之前就给出答案时，你就能保持专注。四天代替一个月——这就是这种感觉。
GLM 5.2 Fast 已可通过 FireConnect 在 Claude Code 中使用，设置只需一行命令。模型 ID 为 accounts/fireworks/routers/glm-5p2-fast，运行速度比标准路径快 2 到 3 倍，保留完整上下文窗口，并大幅奖励缓存输入，这使得长时间代理编码循环变得实用且廉价。