好吧，讓我們談談框架、庫、強化學習，以及為什麼我可能不喜歡你最喜歡的強化學習代碼庫。是的，包括那個。 強化學習的不同之處在於，算法是簡單的部分。GRPO 是一個基於某些 logprobs 的單行方程。如果你有數據，計算損失是微不足道的，然後你大概會用你選擇的反向傳播庫來使用它。 但這就是問題所在——獲取數據。這是一件麻煩的事。在常規的強化學習中，你必須進行回合，可能需要截斷一些劇集，並相應地處理結尾。如果你不想像蝸牛一樣慢，你會想要向量化環境並調整算法。如果你想做 LLM，你需要做所有讓 LLM 適合內存的無聊事務。你需要小心你的提示，為損失遮蔽正確的部分。你需要一個不錯的生成引擎（vLLM），這樣更新權重就會變得麻煩。如果你想做多代理多回合的 LLM 強化學習，那麼不如去做數獨。 雖然我們在幾乎所有與強化學習相關的事情上都有很多分歧，但我認為 @jsuarez5341 的 Pufferlib 美妙地體現了這一點。它無疑在它所做的事情上非常出色——在模擬環境中非常快速地訓練強化學習算法。 但它的大部分新穎性純粹是基礎設施。核心算法在多年來基本上沒有變化，我敢打賭它們代表的整體工程努力不到 10%。 自然，這對你需要編寫的代碼有影響，以便做任何超出運行內置示例的事情。我一次又一次發現，對於許多足夠非平凡（即：有趣）的研究問題，花費的時間相似於 (a) 從頭開始/從簡單原始構建事物，或 (b) 調整現有框架以適應瘋狂的想法。 在前者中，你專注於編寫實際邏輯。在後者中，你需要調整框架以允許你添加邏輯。我知道我更喜歡哪一種。 所有這一切都是因為算法是簡單的部分。 基礎設施才是麻煩的事。因此，每當你有機會選擇時——使用簡化基礎設施的工具，自己編寫訓練循環。不要構建框架，構建庫。你會感謝自己。 特別感謝我當年碩士的導師，他是第一個告訴我放棄 rllib，直接在 PyTorch 中自己編寫 PPO 的人。還有 @hallerite，激勵我最終寫下這篇抱怨。如果人們有需求，我可能會在未來某個時候寫一篇正式的努力帖子，附上示例。