cHHillee and Toulme Debate Whether Tinker's Post-Training Service Has a Moat

On September 22, PatrickToulme, associated with Thinking Machines, asked cHHillee on X: what stops practitioners from handing all their post-training needs to Tinker — speed, cost, scalability, correctness, or flexibility? Tinker's vision is to serve as post-training ML infrastructure for (almost) everyone. The question triggered multiple rounds of public debate between the two that day.

Confirmed

• cHHillee argues post-training-as-a-service is quite resilient against AI capability progress: future models (as in the scenario he relayed of "GPT-bel writing one in an afternoon") won't easily replace it; the most obvious value is that GPU rental is irreplaceable
• One point of agreement: renting GPUs is a moat against competitors; the disagreement is whether Thinking Machines' MFU tuning tooling constitutes a moat — Toulme thinks it doesn't, since massive tuning hours are indeed needed today but that's not a barrier; cHHillee likewise doesn't see kernel-level MFU optimization as a significant edge, arguing the real value of ML infrastructure lies in demand aggregation — for a model like Kimi K3, the most efficient solution may involve specific deployment approaches
• cHHillee believes software-level moats won't hold up against RSI (recursive self-improvement), and Tinker is perfect RSI infrastructure: an ideal automated research loop needs to be unconstrained by its own compute, scale elastically on demand, and iterate extremely fast — exactly what Tinker offers
• Addressing concerns about "wanting to own your post-training code," cHHillee responded that with Tinker you can still own your post-training codebase and algorithms; it only abstracts away the trainer layer

Why it matters

• The debate cuts to the core question of the post-training-as-a-service business model: where does the value actually lie — compute resources, software tooling, or demand aggregation
• First-hand feedback from developer silvertsuki gives practical reasons for not adopting Tinker: high cost, and most users want to keep their post-training code in-house, for better or worse. This suggests that to realize the vision of "handling everyone's post-training infrastructure," Tinker must address concerns around pricing and code ownership perceptions
• cHHillee's RSI framing offers another way to think about such services: an AI self-improvement loop's need for elastic compute and short iteration cycles is precisely the target scenario for Tinker-like platforms

2026-09-22 ~ 2026-09-22 · 8 related posts

• [source] Tinker aims to handle posttraining ML infra for everyone — what's holding users back? — PatrickToulme · 2026-09-22
• [source] cHHillee argues posttraining-as-a-service is resilient: GPU rentals can't be replaced — cHHillee · 2026-09-22
• Toulme: renting GPUs is a moat, MFU-tuning software is not — PatrickToulme · 2026-09-22
• [source] Why devs skip Tinker for posttraining: cost and owning your own code — silver__tsuki · 2026-09-22
• cHHillee: MFU tuning isn't a moat, but demand aggregation in ML infra is — cHHillee · 2026-09-22
• Software moats won't survive RSI — ML infra's value is demand aggregation, says cHHillee — PatrickToulme · 2026-09-22
• cHHillee defends Tinker: you can own your post-training codebase, only trainer and sampler are abstracted — cHHillee · 2026-09-22
• cHHillee: Tinker is perfect infra for RSI—elastic, unbounded compute — cHHillee · 2026-09-22