LLM Engineer
"LLM engineer" is used to mean two quite different jobs: an applied AI engineer at some companies, and a model-adjacent specialist doing fine-tuning, serving, and inference optimization at others. This page separates them, gives you the questions to ask so a job posting stops being ambiguous, and covers what each version pays.
Typical Pay (US)*
$180kmedian** AI-estimated from general U.S. labor-market patterns — not measured data from the U.S. Bureau of Labor Statistics or any official source. Real pay varies widely by location, employer, experience, and timing.
Outlook
No federal occupation code exists for this title; the nearest occupational context is Computer and Information Research Scientists (15-1221), with an estimated median near $145,000, estimated growth around 9.5% annually, and estimated automation exposure of 0.15. Demand is real but thinner and more concentrated than for AI engineering — it clusters at labs, inference providers, and companies whose economics force them to run their own weights. AI absorbs the boilerplate here too: training scripts, serving configs, and benchmark harnesses are all generatable. What stays valuable is empirical judgment about a system nobody has a clean theory for — deciding whether a quality drop after quantization matters for your users, whether a fine-tune beats better retrieval, and where the actual bottleneck sits in a GPU pipeline. Expect the title itself to keep drifting; the underlying skills will not.
What does a LLM Engineer do?
At the specialist end, an LLM engineer works close to the model rather than purely on top of it. That means fine-tuning — supervised fine-tuning, LoRA and QLoRA adapters, preference tuning — on a dataset you had to build and clean yourself. It means inference: running open-weights models on your own hardware with vLLM, SGLang, or TensorRT-LLM, tuning batching and KV-cache behavior, quantizing to int8 or 4-bit and measuring exactly what quality you traded for the throughput. It means context engineering at scale, where the question is not "what prompt works" but how to keep 200,000 tokens of retrieved material coherent, cached, and affordable across millions of calls. It means owning tokens-per-second, cost-per-million-tokens, and time-to-first-token as engineering targets with your name on them.
The honest problem with this page is that the title is not used consistently. At many companies — probably most — an "LLM engineer" posting describes exactly what the market elsewhere calls an AI engineer: building product features with a hosted model, retrieval, tool calling, and evaluation, with no training or serving work at all. At a smaller set of companies, usually ones running their own inference or shipping open-weights models, it means the specialist work above. Both are real jobs. Only one of them requires GPU-level knowledge, and applying to the wrong one wastes everybody's time.
So ask. In a screen, four questions resolve it almost immediately. Do you serve your own model weights, or call a provider API? Has anyone on the team shipped a fine-tune to production in the past year, and what did it improve? Who owns GPU capacity and inference cost? What does a typical week look like — feature work, or throughput and quality work? Two API answers and it is an AI engineering role with a fashionable title; two weights-and-GPU answers and it is the specialist version.
Pay skews highest of the AI-adjacent titles precisely because the specialist version is scarce. Very few engineers can do serving performance work and dataset curation and evaluation, and the ones who can are usually already employed by labs or inference providers. The boundaries with neighboring roles: a machine learning engineer trains and productionises models generally, including classical ML on tabular data; an AI engineer builds applications on models someone else trained; an MLOps engineer owns the platform and reliability layer rather than model behavior. LLM engineering is the narrow, deep slice where the model's own weights and runtime are yours to change. It suits people who enjoy profiling and benchmarking as much as building, and who can sit with a two-week experiment that might return nothing. It suits you less if you want to ship user-visible features often.
A day in the life
- Profile a serving deployment and find that continuous batching is idle-waiting because max sequence length was set for the worst case
- Quantize a 70B model to 4-bit, then run your own evaluation suite to measure exactly which task categories degraded
- Curate 3,000 fine-tuning examples by hand, discard 600 of them as contradictory, and get a better result from the smaller set
- Compare a LoRA fine-tune against a well-designed prompt on the same eval set, and conclude the prompt wins for now
- Cut time-to-first-token by restructuring requests so the shared system prefix hits the provider's prompt cache
- Argue against self-hosting for a workload whose volume does not yet justify the GPU reservation and on-call burden
- Write the post-mortem for an inference outage caused by a KV-cache memory ceiling nobody had load-tested
How to become a LLM Engineer
- 1
Become an AI engineer first
~9 monthsAlmost nobody enters this role directly. Build applications on hosted models, learn retrieval and evaluation, and get a feel for where model behavior actually breaks in production.
- 2
Learn transformer internals well enough to reason about cost
~3 monthsAttention, the KV cache, tokenization, context window mechanics, and why memory rather than compute is usually the constraint at inference time. Depth here is what separates the two versions of this title.
- 3
Run open-weights models yourself on real hardware
~2 monthsServe a model with vLLM or SGLang on a rented GPU, benchmark throughput and latency honestly, then quantize it and measure what quality you lost.
- 4
Do one fine-tune end to end, including the dataset
~2 monthsBuild and clean the data, train a LoRA adapter, evaluate against a strong prompted baseline, and be able to say plainly whether it was worth it. Dataset quality is the whole skill.
- 5
Build an evaluation suite you would defend in a review
~2 monthsTask-level graded sets, regression tracking across model versions, and cost-per-correct-answer as a first-class metric. This is the deliverable specialist teams complain they cannot hire for.
- 6
Target employers where the specialist version genuinely exists
~3 monthsInference providers, open-weights companies, labs, and high-volume products with real unit-economics pressure. Screen every posting with the API-versus-weights questions before investing in the process.
Skills that matter
Learn the actual skills
Mochivia's structured roadmap walks you from fundamentals to job-ready — 15 minutes a day.
See the Roadmap