LLM Post-Training: When to Own Your Model

LLM post-training is everything you do to a model after its base training so it behaves the way your product needs: supervised fine-tuning on examples you curate, preference tuning on the signals your users already give you, reinforcement learning against a reward you write yourself, and distillation to make the result cheap enough to serve. Most explainers on this keyword stop at that list. The question a founder actually has is the one underneath it: is any of this mine to do, in what order, and what does getting the order wrong cost me.

Lin Qiao has a useful vantage point on that question. She is co-founder and CEO of Fireworks AI, and before starting the company in 2022 she led PyTorch at Meta, running an organization of more than 300 engineers in AI frameworks and platform, the group behind Caffe2 and then PyTorch. Fireworks now runs the tuning and serving workloads for a large number of companies doing exactly this, which means she sees the same mistakes repeat. At a Sequoia Capital event on owning your own intelligence, opened by Sonya Huang, she gave the fifteen minute version of the pattern, and then took the question most of the room appeared to be sitting on: whether it was too early for them.

Her starting premise is not technical. "Every single company exists for a reason because they focus on solving a unique problem in a special way," she says, and the problem with renting all of your intelligence is that the special part gets averaged away. "Today, if you build on top of off-the-shelf API, then you really need to think about how you keep that special taste judgment and unique part forward."

That is the real subject of post-training. Not benchmark points. Taste, encoded somewhere a competitor cannot copy.

What post-training actually buys

Two things, and neither of them is a leaderboard position.

The first is a moat, in the narrow sense that your product gets harder to clone. Qiao is blunt about how cheap cloning has become now that a screenshot is enough of a spec: "it's very easy to clone and copy application as is." Your interface is not defensible. The thing that is hard to copy is the accumulated judgment about what a good answer looks like in your domain, and post-training is how that judgment stops living in a prompt file and starts living in weights. This is the same argument as building a competitive moat in AI, applied one layer down.

The second is unit economics, and for most companies it arrives first. Qiao's claim from the Fireworks vantage point is that a post-trained model can cut serving cost by five to ten times, which means the same budget carries five to ten times the traffic. Treat that as a vendor's range rather than a law, but the direction is well attested: the more successful your AI feature is, the worse your cost of goods gets. Qiao says the squeeze is not just a startup problem. At large companies, "their CFO is blocking their AI feature launch because of the cost." If your inference cost per active user is rising faster than your revenue per active user, you have a post-training question whether or not you wanted one.

Sonya Huang of Sequoia Capital, who opened the same event and whose firm is an investor in Fireworks, framed the ownership question with a crypto borrowing: "Not your weights, not your product." Her own-versus-rent test has four factors. How big a line item is this in your cost of goods. Is latency a P0 for this surface. Can you now beat a closed model on your own narrow domain. And is the data you would train on genuinely proprietary to you. Her examples are instructive because they split inside a single product: coding agents are still mostly rented, because you want strong out-of-the-box performance and latency is not a P0, while tab autocomplete mostly runs on models companies own, because it is called constantly and speed is the product.

She also put a boundary on the whole idea, which is worth repeating because the enthusiasm around sovereign AI tends to drop it: "we are definitely not telling our companies to get off Opus or GPT." Owning intelligence is not binary. Running entirely on closed APIs is, in her words, "a higher floor, but it's a lower ceiling." Most companies should want the higher floor until a specific surface justifies the climb.

The ladder, and the rung you are probably on

The most useful thing in Qiao's talk is that she does not sell post-training as a starting point. "I don't think you should jump into post training right away," she says, and then lays out the progression she sees working, roughly in order of how much it costs you to try. Her own progression runs as far as reinforcement learning. We have added distillation as a sixth rung because it is the fix she gives for the symptom that only shows up once a model is already good, which is that it costs too much to serve.

1. Prompt the model as it is. Few-shot, no training, minutes of work. This is where you find out whether the idea has any legs.
2. Ground it in your data with retrieval. RAG plus real context engineering, measured in hours. This is where most products should live for a long time, and we have argued the full version of that case in RAG versus fine-tuning: retrieval is the cheaper first move and it stays the right answer longer than founders expect.
3. Supervised fine-tuning. You now have data from your own product, and you use it to fix how the model behaves rather than what it knows.
4. Preference tuning. The thumbs up and thumbs down your users were already giving you become the training signal for your product's taste. DPO is the common technique here.
5. Reinforcement learning. You stop correcting behavior and start building genuine specialty in one domain, whether that is legal, finance, healthcare, customer support, recruiting, marketing or sales.
6. Distillation. The model is good but too slow or too expensive, so a large teacher trains a small student you can actually afford to serve.

Qiao's analogy for the middle of that ladder is learning: supervised fine-tuning is reading the literature that tells you what is correct, preference tuning is developing your own taste for how you want to approach a problem, and reinforcement learning is the years of practice that make someone an accountant or a dentist rather than a generally educated person.

The practical read is that steps 1 and 2 are product work you should already be doing, steps 3 and 4 need a product that has users, and step 5 needs a reason. Skipping to step 5 because RL is the interesting part is how teams burn a quarter and a budget and end up back at a prompt.

Match the technique to the symptom

This is the part worth keeping. Qiao maps each technique to the specific failure it fixes, which turns an intimidating menu into a diagnosis. If you cannot name your symptom, you are not ready to pick a technique.

Symptom	What it means	The fix
The model does not know a fact, and the fact changes often	A knowledge gap, not a behavior problem	Retrieval, not training
The output format or behavior is wrong	The model does not know your conventions	Curate data, then supervised fine-tuning
The answers are fine but not in your product's voice or judgment	A taste gap	Preference tuning on real user signals
The model is simply weak at the specific hard thing you do	A capability gap in your domain	Reinforcement learning
Quality is there but it is too slow or too expensive to serve	An economics problem, not a quality one	Distillation to a smaller model

The most expensive mistake on this table is treating row one as a training problem. Fine-tuning a model to memorize facts that change weekly buys you a model that is confidently out of date, and you pay for the privilege twice.

Data quality is a product-team job

Everyone nods at data quality and then ships volume anyway. Qiao is direct that volume is the wrong instinct: "the quantity is not the most important. Actually, quality is the most important." Throwing a large pile of production logs into a training run is one of the reliable ways to spend money and get nothing.

The interesting claim is organizational. Asked who should judge whether training data is good, her answer is not the ML team: "who's the best judge of data quality? It's actually your product team." Before generative AI, product and research were separate organizations that negotiated across an interface. Post-training collapses that, because the person who can tell a good answer from a plausible one is the person who understands the customer, not the person who understands the optimizer. "Intelligence is derivative of data," as Qiao puts it, and your data is only as good as the taste of whoever curated it. If you are building the data layer that makes AI work, the staffing implication is that your best product thinker now has a second job.

Huang's keynote lands in the same place from the org chart side. Her advice is not to hand sovereign AI to the existing AI platform team, because this is not a platform services capability, and to keep the team small and separate. Harvey, she notes, has published a substantial amount of research with a team of seven.

Your evals are the judgment you are trying to encode

You cannot post-train toward a target you have not defined, which makes evals the actual first step rather than a later chore. Qiao's description of the current state of practice in the room got a laugh because it was accurate: "a lot of evals is a vibe evaling." Founders look at an output and decide whether it is good.

Her point is that the vibe check is not worthless. It is judgment, which is exactly the asset you are trying to encode, and the work is to make it repeatable: "that judgment you convert into systemic evaluation." She frames it as ordinary engineering discipline rather than research, since "this is no different from traditional software development where you have your unit test, integration test to ensure quality." Our longer treatment of how to build that suite is in LLM evaluation for founders.

Huang is harsher about how much of this gets skipped, and honest about why: "it is unglamorous work. It is not fun work, but the more that you do up front, the better positioned you are for everything after."

There is a second reason to own your measuring stick, which is that you will otherwise be reading someone else's. Qiao cites Doximity, a Fireworks customer, as having topped a Stanford and Harvard clinical safety benchmark. The underlying study is more specific than that summary. NOHARM, built by researchers at Stanford University School of Medicine and Harvard Medical School, scored 24 systems against 1,100 tasks drawn from real physician-to-specialist consultations and graded by a panel of 29 board-certified physicians. On the rate of potentially severe harmful errors, four specialized clinical tools finished in a statistical tie for first: AMBOSS LiSA at 2.9 percent, Doximity Ask at 4.8 percent, OpenEvidence at 5.1 percent and Glass Health at 5.4 percent. Every generalist model in the study scored worse on that measure. Doximity separately reports that it led the physician-rated real-world sample. Not one of those statements is false, and not one of them is the flat claim that Doximity topped the benchmark. A benchmark result is a sentence, and the sentence is chosen by whoever is selling it. Your own eval is the only one written to answer your question.

Two failure modes that quietly burn the budget

Qiao spent a good share of her time on the ways teams spend money on post-training and get nothing back. Two are worth internalizing before you start.

Reward hacking and sloppy environments. When you reach reinforcement learning, you build a simulation of the work and a reward that scores it. If the simulation does not reflect reality, the model hill-climbs on your bad proxy. Her example is the cleanest version of this failure anyone has: a model asked to produce code that minimizes compilation errors learned to emit no code at all. Zero lines compile perfectly. The lesson she draws is a posture, not a technique: "try not to let the model outsmart you."

The encouraging half is that writing rewards is a skill founders already have. "You write rewards in code," she says, and the way to think about them is as rubrics that score a result across several dimensions, blended with weights that are specific to you. For a recruiting agent, her rubric scores a candidate on more than one dimension at once, whether they are relentless and how fast they ship, and she says a different company will pick different criteria and blend them differently. That blend is the part nobody else can copy. Her claim is that the barrier here is lower than it looks, because "this whole reward engineering is very similar to software engineering." If you are weighing whether to build the world your agent trains in, we have gone deeper on cost and verifier design in RL environments explained for founders.

The handoff from training to serving. This one is unglamorous and it is where a successful training run goes to die. A model is a very large pile of matrix multiplications, and the result depends on the libraries, the numerics and the optimizations used to compute them. Move a model from a training stack to a serving stack without aligning the two and quality drops, or precision is lost, and the drop is invisible unless you are measuring for it. Qiao's framing is that training is not the end of the experiment: the verdict is whether product metrics move once the model is actually serving traffic, which means an A/B test, not a benchmark table.

When to start: after product-market fit, not before

The sharpest question in the room came from an attendee from Vercel, and it was the right one. Is post-training driven by cost, by usage, or by the benchmark win, and is a two percent bump worth the investment and the maintenance.

Qiao's answer separates two phases that SaaS treated as one. "Product market fit doesn't really mean you have a durable scalable business." In her model you reach product-market fit on frontier APIs precisely so you do not have to think about any of this, and then post-training becomes the tool for the second phase, when the questions change to keeping your edge and surviving your own cost structure.

The non-obvious reason the order matters is that the data arrives in the right sequence. Before product-market fit, the traffic through your product is thin and unrepresentative, so the data you would train on encodes guesses. After it, volume and quality rise together and the exhaust from your own product becomes the fuel. Post-training early does not just cost more than it returns. It trains on the wrong thing.

Cursor is her example of a company that started early and made it work, and it is worth looking at closely because the details are public rather than anecdotal. Cursor started down this path at the beginning of 2025, Qiao says, for a reason that was strategic rather than technical: "they really want to control their destiny of the supply of the model." Its own technical reports describe Composer 2 as continued pretraining on a code-heavy mixture over an open base model, followed by large-scale reinforcement learning in environments that emulate real Cursor sessions, with real-time RL from live user interactions on top.

That last layer comes with a caveat Cursor states itself, in a separate Sequoia clip on the limits of learning from live traffic: "the model has to meet some kind of bar to even be put into online RL." If the model is not good, nobody uses it, and nobody generates the feedback the loop needs. Online learning cannot create a model from nothing, only improve one that already clears the bar. As Cursor puts it, "It's kind of like cherry on top to really get this super delightful experience." The same constraint governs every continual learning story: the flywheel needs a product people already use.

So Cursor is not a counterexample to the product-market-fit rule. It is a company that had enormous engagement first and then went down the ladder, and it took a dedicated research effort to do it. Qiao also names Factory, the Sequoia-backed coding agent company valued at five billion dollars as of September 2026, and Genspark, whose deep research and slide generation agents she says run slightly ahead of a frontier model at a materially lower cost. The pattern across her examples is consistent: real traffic first, then ownership.

Her bet on where this ends is worth sitting with: "in the future there could be millions of specialized models. One application per use case."

What owning weights changes about your security posture

This part gets left out of technical explainers, and it changes your risk register more than it changes your stack.

Three things move. Your training data becomes a production asset, which means the pile of customer interactions you were loosely retaining is now a production dataset, often a regulated one, with a provenance question attached, and any synthetic data you generate to enrich it inherits whatever the generator was trained on. Your eval suite and your reward functions become the crown jewels, because they encode the judgment that is the whole point of the exercise, and they are small files that are easy to walk out of the building. And your weights are now exfiltratable intellectual property living in your own infrastructure rather than someone else's, which is the trade you asked for, but it is a trade: you have taken custody of the thing you did not want a vendor to hold.

The upside is control that closed APIs cannot give you. You can decide where the model runs, what it retains, and what leaves your boundary. If a regulated customer asks where their data goes during inference, owning the serving stack turns a vendor question into an answer you control. Just budget for the obligation along with the GPU hours.

What to do this week

1. Name your symptom. Take the table above and write down which row your biggest quality complaint belongs to. If it is row one, a knowledge gap on facts that change, close the tab on post-training and fix retrieval.
2. Check the cost curve, not the cost. Plot inference spend per active user over the last three months. If it is rising while revenue per active user is flat, you have an economics problem that distillation or a tuned smaller model solves and prompt work does not.
3. Write ten evals from real customer cases. Not synthetic ones. Ten cases where you can state why the good answer is good. This is the asset every later step depends on, and it is useful even if you never post-train.
4. Find out whether you have usable data yet. Pull a week of production traffic and have your best product person grade fifty outputs. If they cannot tell good from bad quickly, the problem is your definition of good, not your model.
5. Decide own versus rent per surface, not per company. Take the four factors from Huang's framework (cost, latency, achievable performance, and how proprietary the data is) and run them across each AI surface in your product. Most will come back as rent, and one or two may come back as own. That list is your roadmap.
6. If you are pre product-market fit, write down the trigger instead. Pick the condition that would make post-training worth it, whether a cost-of-goods threshold or a quality ceiling you keep hitting, and get back to finding customers.

Post-training is how you keep your taste once the model is doing the talking, but it is a second-phase tool. The first phase is still finding someone who wants the thing. Our course, the AI Operating System for Startups, covers how to sequence these decisions across product, engineering and cost so you reach for an expensive tool at the point it actually pays, not the point it becomes interesting. For the wider map of where this sits, start with AI for startups.

Sources

• Post-Training Is How You Keep Your Taste, Lin Qiao at Sequoia Capital, the talk and audience Q&A this article distills.
• How Companies Are Building Their Own Intelligence, Sonya Huang's keynote from the same Sequoia event, for the own-versus-rent framework, the team and legibility advice, and the limits of the sovereign AI pitch. Huang notes in the talk that she is not technical and offers the framework as an opinionated starting point.
• Cursor on why online RL is just the cherry on top, Sequoia Capital, for the constraint that online learning needs an already-good model.
• Cursor's own technical write-ups on how Composer is trained: the Composer 2 technical report and improving Composer through real-time RL.
• Background on Lin Qiao and Fireworks AI: the Fireworks team page and her LinkedIn profile. Sequoia's Sonya Huang independently describes Qiao as the former leader of PyTorch on her own firm profile, and Sequoia lists Fireworks among its portfolio companies.
• On the clinical benchmark result: the NOHARM study itself, First, do NOHARM, Becker's Hospital Review's ranking of all 24 systems by severe-harm rate, and Doximity's own announcement, which reports a different cut of the same study.
• Company background: Factory via Reuters and Genspark.