DeployedInference Engineer vs ML Engineer vs AI Engineer
One builds the model, one consumes it, one serves it. Of 120 live Applied AI Engineer postings, four mentioned any serving vocabulary at all.
These three titles are used interchangeably in job postings and are not interchangeable jobs. They sit at three different points in a model’s life: one builds the model, one builds a product around it, and one makes it serve. The skills overlap far less than the titles suggest.
The shortest version: an ML Engineer produces a model. An AI Engineer consumes one. An Inference Engineer serves one. Everything below follows from that.
The one number that settles it
Rather than argue from definitions, we read the postings. Of a 120-posting sample of live Applied AI Engineer roles on this board, four mentioned any inference or serving vocabulary at all — vLLM, SGLang, TensorRT, KV cache, quantization, speculative decoding, CUDA, or throughput and latency targets. That is 3%.
Meanwhile 45% of the same postings mention training or fine-tuning. So the role sitting closest to inference in the org chart — the AI engineering role that works with models daily — almost never touches the serving layer, and is nearly fifteen times more likely to talk about training than about serving.
Two jobs that share a floor, a manager, and a vocabulary of “LLMs” have a 3% overlap in the technical vocabulary that matters. They are not variants of one another.
Side by side
| ML Engineer | AI / Applied AI Engineer | Inference Engineer | |
|---|---|---|---|
| Where the model comes from | You build or fine-tune it | You call someone else’s | It arrives finished; you serve it |
| Measured on | Model quality — accuracy, eval scores | Product outcomes — does the feature work | Latency, throughput, cost per token |
| Typical day | Data, training runs, evaluation | Retrieval, prompts, agents, product code | Serving stacks, profiling, quantization |
| Closest neighbour discipline | Research and data science | Product engineering | Systems and performance engineering |
| Customer contact | Rare | Often — 85 median on this board | Rare |
| GPU knowledge needed | Enough to train | Usually none | Central to the job |
“85 median on this board” is the median customer-facing score, 0–100, across the Applied AI Engineer sample described in the Method section. ML Engineer is not classified on this board; that column is definitional.
ML Engineer: you produce the model
The oldest of the three titles, and the vaguest, because it predates the current wave and got stretched over it. Classically it means training: assembling data, running training or fine-tuning jobs, building evaluation, and shipping a model artefact that did not exist before.
The confusion is that many companies now use “ML Engineer” for anyone who works near a model, including people who only call APIs. Read the requirements rather than the title: if there is no training data, no evaluation harness, and no talk of model quality, it is not really this job whatever the header says.
AI Engineer: you build the product around the model
The newest title, and the one absorbing most of the industry’s hiring. The defining characteristic is that the model is a dependency, not a deliverable — you call it, and your job is everything around the call: retrieval, context assembly, prompt and agent design, tool integration, evaluation of the system rather than the model, guardrails, and the ordinary product engineering that carries it.
On this board these roles score a median of 78 for coding intensity, 85 for AI/LLM usage, and 85 for customer-facing work — a product engineering job in every structural sense, applied to models. That last number is the one people miss: this is largely a customer-facing discipline, which is exactly why it sits alongside Forward Deployed Engineering on this board rather than alongside research.
“Applied AI Engineer” usually means this with the customer-facing part made explicit. Applied AI Engineer roles are the largest and fastest-growing category here.
Inference Engineer: you make it serve
The model exists and works; the problem is that serving it under real traffic is too slow, too expensive, or too fragile. The work runs from the serving stack down to the GPU kernel, and it is measured in numbers the rest of the business can read: time to first token, p99 latency, tokens per second per GPU, cost per million tokens.
This is systems and performance engineering that happens to have a model in it. The nearest adjacent discipline is not data science — it is the kind of low-level backend and hardware-aware work that existed long before LLMs did. That is why the transition into it from ML engineering is harder than people expect, and the transition from systems engineering is easier. What an inference engineer actually does covers the day-to-day in detail.
Which one is the posting in front of you?
- Does it mention training data or an evaluation set for a model? ML Engineer.
- Does it mention retrieval, agents, prompts, or a product surface? AI / Applied AI Engineer.
- Does it name a latency or cost target, or a serving framework? Inference Engineer.
- Does it mention GPUs? Weak signal on its own — all three touch them. What matters is whether the GPU is where the work happens or just where the model runs.
Which one should you aim at?
A rough guide, given they compete for overlapping candidates:
- From product or backend engineering, AI Engineering is the shortest move — the model is an API and the rest is engineering you already do.
- From systems, performance, HPC, or graphics, inference is a far more natural fit than either of the others, and the scarcity of people who can read a GPU profile is real.
- From data science or research, ML Engineering is the continuous path; inference is close to a career change.
The market is not symmetrical, either. AI Engineering roles are abundant — 374 live on this board as this was written. Inference roles are rarer and concentrated in a small number of employers, which cuts both ways: fewer openings, less competition per opening.
Method
The measured figures come from a 120-posting sample of live Applied AI Engineer roles on DeployedJobs, read through the public API on 20 August 2026 — 120 of the 374 live at the time. Scores are the classifier’s per-dimension medians, 0–100, assigned by reading each description rather than its title. The vocabulary counts search each posting’s description, tech stack, and required skills for twelve serving and inference terms (vLLM, SGLang, TensorRT, KV cache, quantization, speculative decoding, tokens per second, time to first token, p99 latency, Triton, CUDA) and for training and fine-tuning terms respectively.
Two columns of the comparison table are definitional rather than measured, and it would be wrong to imply otherwise. ML Engineer is not a category on this board — model training and research are deliberately out of scope, so there are no postings to measure. And Inference Engineer has no live postings yet: the role was added to the taxonomy days before this was written, and the column describes the role as defined rather than as observed. Both will be revisited once there is data behind them.
Browse Forward Deployed Engineer jobs
Get new deployed-engineering roles in your inbox each week: