The Car in My Head: A No-Nonsense Tour of the LLM Words Everyone Throws Around

The ideas and writing here are mine; I used an AI assistant to help edit and tidy it up.

For the longest time, LLM conversations felt like standing in a room where everyone spoke a dialect I half-understood. People would say "we DPO'd it after SFT," or "throw it on vLLM and run the harness," or "it's not a chatbot, it's an agent," and I'd nod along while quietly panicking. The words weren't hard, exactly. The problem was that nobody ever told me which words belonged to which part of the story.

So I sat down and forced myself to untangle it, and somewhere in the middle of that I stumbled onto a mental picture that finally made the whole thing snap into place: it's a car.

That sounds glib, but stick with me, because once I started mapping these terms onto a car, I stopped confusing them. This is that map. If you've ever felt like a tourist in your own field's vocabulary, this one's for you.

The one picture to rule them all

Here's the whole thing in a single sketch. Don't worry about the labels yet. We'll walk through each one.

                          ____________________________
                         /          CABIN             \
                        /    how you DRIVE it:          \
            ___________/     • chat  = you steer every    \___________
           /                   turn (manual)                          \
          /                  • agent = name a destination,             \
         /                     it drives itself                         \
        |   ____________                              ____________       |
        |  |  ENGINE    |   ===  power = tokens  ===> |  GEARBOX   |     |
        |  |  = the LLM |                             |  = vLLM /  |     |
        |  | (weights)  |                             |   SGLang   |     |
        |  |____________|                             |____________|     |
        |________________________________________________________ ______|
            \   __   /                                \   __   /
             \ /  \ /    fuel = data     test track    \ /  \ /
              ( O  )     dyno = the eval harness        ( O  )
               \__/      wheels = throughput & latency   \__/

             THE WHOLE CAR  =  THE HARNESS
   (everything bolted around the engine to make it actually go)

The engine is the intelligence. The gearbox makes that intelligence deliverable. And "the car" is everything you build around the engine to make it useful. Hold that thought, because it pays off at the end.

The engine: where the model actually comes from

The engine is the model itself, the giant pile of numbers ("weights") that does the thinking. But an engine doesn't appear out of thin air. It gets cast and machined in a factory long before it ends up under anyone's hood. That factory is the training process, and it runs in stages.

Pre-training is casting the rough engine block. You take an absurd amount of text (think trillions of words of web pages, books, and code) and train the model to do exactly one thing: predict the next word. Over and over, billions of times. That's it. No human grading the answers, just "guess what comes next." Out of that mind-numbing exercise, the model somehow soaks up grammar, facts, reasoning patterns, the works. What you get at the end is a base model: enormously knowledgeable, but weirdly useless. Ask it a question and it'll often just keep writing more questions, because all it learned to do was continue text, not answer you.

Mid-training is machining that rough block for a purpose. Same basic exercise, still predicting the next word, but now you feed it curated, higher-quality material: more code, more math, longer documents so it can handle bigger inputs. If pre-training is "learn language and the world," mid-training is "get sharp at the things we care about." The line between this and pre-training is genuinely blurry, and honestly different labs draw it in different places, so don't lose sleep over the boundary.

Post-training is where the engine finally learns to respond to the pedal. This is the part that turns a rambling base model into something that actually helps you, and it's two moves.

The first move is SFT, supervised fine-tuning. "Supervised" just means we show it the answers we want. You hand it thousands of examples of here's a question, here's a great response, and it learns to produce answers instead of just continuing your sentence. The mechanism is still next-word prediction under the hood; you're just feeding it the exact "right" responses to imitate. After SFT, the engine responds smoothly when you press the gas.

The second move is teaching it taste, and this is where a whole zoo of acronyms lives.

Tuning the engine on the dyno: RLHF, DPO, and friends

SFT teaches the model to give a good answer. But "which of these two answers is better?" is often a matter of preference that's hard to write down as a single correct target. So we shift to learning from comparisons. Picture an engine on a dyno, getting fine-tuned not toward some textbook ideal but toward what drivers actually like.

The original recipe is RLHF, reinforcement learning from human feedback. Humans look at pairs of responses and pick the better one. You train a separate little reward model to predict those preferences; that's the dyno's scoring sensor, rating each finished run. Then you nudge the main model to chase higher scores, while a leash (a thing called a KL penalty, tied to a frozen "reference" copy) stops it from going feral and gaming the score with gibberish. It works beautifully and it's a pain: you're juggling four models at once and the whole thing is famously twitchy to stabilize.

DPO, direct preference optimization, looked at all that machinery and basically said "what if we didn't." Someone proved you can skip the reward model and the reinforcement-learning loop entirely and just train directly on the "this one's better than that one" pairs with a simple loss. Way fewer moving parts, far more stable, and it's become the first thing most people reach for.

Then there's GRPO, which has been everywhere lately thanks to the reasoning models. It's a cousin of the classic RLHF approach, but it kills off one of the helper models, the "value model," which used to predict mid-generation how a run would turn out. Instead, GRPO just generates a batch of answers to the same prompt and grades each one against the batch average. Beat the average, get pushed up; fall below it, get pushed down. Dropping that whole extra network is a big reason it caught on.

You'll bump into a few more in this family: KTO (learns from simple thumbs-up/thumbs-down instead of matched pairs), ORPO (folds the imitation and the preference step into one), RLAIF (lets an AI do the preference-labeling instead of humans). They're all answering the same question: given that we prefer some outputs over others, how do we steer the model toward the good ones without breaking it? They just differ in how much machinery they need and what kind of feedback they eat.

The tuning chip: LoRA and QLoRA

Here's a problem. Retraining a whole model to specialize it is like pulling the engine apart and rebuilding it: expensive, slow, and easy to wreck. LoRA (short for Low-Rank Adaptation) is the tuning-chip alternative. Instead of touching the engine's millions of original parts, you clip on a tiny add-on that adjusts its behavior. You freeze the whole base model and train only a small set of new numbers, often well under 1% of the total. The result is a little file, a few megabytes, that you can snap on and off like a cartridge. Want a different specialty? Swap the chip, keep the engine.

QLoRA is the same idea with one extra bit of cleverness: it first compresses the frozen engine down to four-bit precision so it takes up barely any room, then clips the tuning chip on top. The upshot is wild: you can fine-tune a model that used to need a server rack on a single GPU in your closet. The compression costs a little fidelity, but for most jobs you'd never notice.

(One word of warning, since it tripped me up: people use "adapter" loosely to mean the LoRA file itself, but "Adapters" is also the name of an older technique that inserts little trainable layers into the model. Same family, different gadget. LoRA mostly won because its add-on can be merged back into the engine with zero speed penalty.)

The gearbox: vLLM and SGLang

A tuned engine still just spins on a bench until you connect it to a drivetrain. The gearbox is what takes that raw power and turns it into smooth motion. Crucially, it also lets you carry a whole bunch of passengers at once instead of one at a time. In LLM-land, the gearbox is your serving engine.

vLLM is the workhorse. Its claim to fame is squeezing way more simultaneous users onto the same hardware. It does that partly through a trick called PagedAttention (it manages the model's short-term memory the way an operating system manages RAM, so nothing gets wasted) and partly through continuous batching (it doesn't make a quick request wait behind a slow one; it juggles them request-by-request, every single step). The effect is a lot more throughput from the same chips.

SGLang is the other big one, and it shines when your requests overlap a lot, which is exactly what happens with agents and heavy prompting. Its trick is noticing when a hundred requests all share the same long opening and computing that part only once, reusing it for everyone. If your workload is full of repeated context, that's a huge win.

Both are excellent; they just optimize for slightly different driving conditions. And both quietly rely on a stack of efficiency tricks underneath: keeping a "KV cache" so the engine doesn't recompute everything each word (think of it as the flywheel holding momentum), quantization to run a lighter engine, speculative decoding where a little scout model guesses the road ahead so the big engine can confirm several words at once.

The dyno and the test track: the harness

So how do you know your car is any good? You put it on a dyno and run it around a test track. In this world, that's the harness. Most specifically it's an evaluation harness, a standardized rig that runs your model through a battery of benchmarks (general knowledge, grade-school math, coding challenges) so you can compare it apples-to-apples against other models. When someone says "we ran it through the harness," that's usually what they mean: the measuring rig.

"Harness" also gets used more loosely for any scaffolding you bolt around a model to make it do a measurable job, including the rig that lets a model loose on a real task and watches what happens. Which brings us to the most interesting cabin in the whole car.

The cabin: chat versus agent

Here's where a lot of the recent excitement lives, and the car analogy nails the distinction.

Chat is manual driving. You steer every single turn. You say something, the model answers, you say the next thing, it answers again. The human is in the loop constantly, hands on the wheel.

An agent is autonomy mode. You name a destination ("fix this failing test," "research these five companies and summarize them") and the car drives itself there. Under the hood it's the same engine, but now there's a self-driving brain on top that decides what to do next, takes actions in the real world, looks at the results, and keeps going until it arrives. The defining difference is simple: in chat, you drive each step; in an agent, the model does, often running many, many internal steps for a single thing you asked.

That self-driving brain runs in a loop, and the loop is almost embarrassingly simple once you see it: think, then act, then look at what happened, then think again. The model reasons about what it needs, calls a tool to get it (search the web, run some code, edit a file), reads the result, and loops back around, until it decides it's done and hands you the final answer. That "think-act-observe" cycle is the entire engine of agent behavior. The fancy stuff people build is just variations on that loop, with guardrails so it can't drive forever or off a cliff.

The "tools" are the controls the car can actually operate (the wheel, the brakes, the GPS), and giving the model access to them is what's called function calling. When you've got several of these self-driving cars working together, each specialized for a different leg of the trip, that's an agent swarm: a convoy, with one car maybe coordinating the others. And when the route gets complicated enough that you want the self-driver following an explicit map with clearly drawn junctions and U-turns rather than improvising, that's the kind of structure a framework like LangGraph gives you. It lets you lay out the agent's loop as an actual diagram of steps and decisions instead of tangled code.

So what is the car, really?

Here's the part I love. Go back to the picture. The engine is the trained intelligence. The gearbox makes that intelligence deliverable to lots of people efficiently. And the whole car, the thing you actually drive, is the harness: everything you bolt around the engine to make it go somewhere useful. Sometimes that car is a test rig you built to measure the engine. Sometimes it's a self-driver you built to send the engine off on its own. Same chassis, different purpose.

The metaphor isn't perfect, and I'll own the seams: vLLM isn't only a gearbox, it's also kind of the thing physically running the engine, so it's really an integrated powertrain. And "fuel" does double duty: in the factory the fuel is training data, but at drive time the real fuel is your prompt, the destination and passengers you load in. If you push the analogy too hard it creaks. But as a way to stop confusing training with serving with using, it's been the single most useful thing in my head.

Because that, in the end, was my whole problem. These words weren't hard. I just didn't know which of the three I was looking at. Training builds the engine. Serving runs it. Agents put it in the driver's seat. Once you can tell those apart at a glance, the dialect stops sounding like a foreign language, and starts sounding like people just talking about cars.