cHHillee 与 Toulme 激辩 Tinker 后训练服务护城河
9 月 22 日，Thinking Machines 相关人士 PatrickToulme 在 X 上向 cHHillee 发问：是什么阻碍从业者把所有后训练需求交给 Tinker——速度、成本、可扩展性、正确性还是灵活性？Tinker 的愿景是为（几乎）所有人的后训练 ML 基建服务。这一提问引发了两人当日的多轮公开辩论。
已确认
- cHHillee 认为后训练即服务对 AI 能力进步相当有韧性，未来模型（如他所转述的「GPT-bel 一下午写出」情景）难以取代它；最显然的价值是 GPU 租用不可替代。
- 两人达成共识的一点：租 GPU 是对抗竞争者的护城河；分歧在于 Thinking Machines 的 MFU 调优工具是否构成护城河——Toulme 认为不构成，今天确实需要大量调参工时，但这不算壁垒；cHHillee 同样不认为 kernel 层面的 MFU 优化是显著优势，主张 ML 基建的真正价值在于需求聚合，例如对 Kimi K3 这类模型，最高效方案可能涉及特定部署方式。
- cHHillee 认为软件层面的护城河在 RSI（递归自我改进）面前不具持久性，而 Tinker 是 RSI 的完美基础设施：理想的自动研究循环需要不受自身算力约束、即时弹性扩缩、迭代周期极短，Tinker 恰好满足。
- 针对「想自持 post-training 代码」的顾虑，cHHillee 回应称用 Tinker 仍可拥有自己的 post-training 代码库和算法，它只是抽象掉 trainer 层面。
为什么重要
- 这场辩论直接触及后训练即服务商业模式的核心问题：价值到底在算力资源、软件工具还是需求聚合。
- 开发者 silvertsuki 的第一手反馈给出了不采用 Tinker 的实际原因：成本高，且多数用户无论好坏都想自己掌握 post-training 代码。这提示 Tinker 若要实现「包办所有人后训练基建」的愿景，需在定价与代码自主性认知上解决疑虑。
- cHHillee 提出的 RSI 视角为该类服务提供了另一个想象空间：AI 自我改进循环对弹性算力和短迭代周期的需求，恰好是 Tinker 类平台的目标场景。
2026-09-22 ~ 2026-09-22 · 8 条相关
一手来源
- Tinker 想包办所有人的后训练 ML 基建,从业者为何不用引发讨论 — PatrickToulme ·
- cHHillee:RL 后训练即服务难被未来模型取代,GPU 租用不可替代 — cHHillee ·
- 开发者谈为何不用 Tinker 做后训练:成本高且想自持代码 — silver__tsuki ·
- 【源头】Tinker 想包办所有人的后训练 ML 基建,从业者为何不用引发讨论 — PatrickToulme · 2026-09-22
- 【源头】cHHillee:RL 后训练即服务难被未来模型取代,GPU 租用不可替代 — cHHillee · 2026-09-22
- Toulme:租 GPU 算护城河,MFU 调优软件算不上 — PatrickToulme · 2026-09-22
- 【源头】开发者谈为何不用 Tinker 做后训练:成本高且想自持代码 — silver__tsuki · 2026-09-22
- cHHillee 谈 Tinker 护城河:软件调优非壁垒,算力聚合才是 — cHHillee · 2026-09-22
- cHHillee:软件护城河难敌 RSI,ML 基建价值在需求聚合 — PatrickToulme · 2026-09-22
- cHHillee 力挺 Tinker:托管训练也能拥有自己的 post-training 代码 — cHHillee · 2026-09-22
- cHHillee:Tinker 是 RSI 的完美基础设施,可无限弹性伸缩 — cHHillee · 2026-09-22