如何用 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 倍，保留完整上下文窗口，並大幅獎勵緩存輸入，這使得長時間代理編碼循環變得實用且廉價。