AI Infrastructure & Platform Engineer
LLMOps + GPU / Cloud Ops — the combined role
One workspace for a single job: stand up, tune, monitor, and maintain a self-hosted + cloud LLM serving stack for a team that ranges from engineers to PhDs. It pulls together the hands-on GPU/LLMOps lab track, the concept decks behind the vocabulary, and the cert paths that feed the role — so nothing gets lost.
The honest read: the gap most people have here isn't the concepts — it's having run it. The lab track is built to close exactly that, and it's designed free-tier-first: roughly 6 of 8 labs run on a consumer 16GB GPU at $0, and you rent a data-center GPU only for MIG, multi-GPU tensor parallelism, and A100-scale numbers — a few hours of cloud time, not a whole weekend of rentals.
The role at a glance
verified July 2026Hands-on GPU / LLMOps lab track
the centerpieceTen runnable runbooks. Each opens as a raw markdown file you run the commands from in your editor. The badge says where it runs: Local-free on your own card, Cloud · free tier (Modal credits), or Rented GPU for the data-center-only labs. Start at 00, then do V (the biggest gap-closer) — Lab 01 first if you want the cheapest possible first touch of a real GPU.
Proves: You rent GPUs cost-consciously — smallest GPU that fits, rent-run-teardown in one sitting, verify the meter is off.
no GPU — read first
- ›Modal vs RunPod vs Vast, and when to use each
- ›The golden rules that prevent a surprise overnight bill
- ›A one-command sanity check for GPU + Docker + NVIDIA runtime
Proves: Roughly 6 of 8 labs run free on a consumer 16GB GPU; rent only for MIG, multi-GPU, and A100-scale numbers.
runs on your own card
- ›What fits 16GB (7B at 4-bit with KV-cache headroom)
- ›Docker+WSL2 GPU passthrough that matches the cloud labs
- ›The one honest scale-not-skill limitation to name in an interview
Watch first
Proves: You deploy vLLM as infrastructure-as-Python — GPU type, image, and autoscaling as decorators — and understand cold starts + scale-to-zero.
cloud, free tier
- ›Serve Qwen2.5-7B behind an OpenAI-compatible endpoint
- ›Observe cold-start vs warm latency and the cost of a pinned warm container
- ›When serverless beats an always-on box or a K8s node pool
Proves: The single biggest gap-closer: turns "I read about vLLM" into "I ran it" — serving, tensor parallelism, quantization, KV/batch tuning, and a benchmark sweep.
mostly local; 2-GPU step needs cloud
- ›Read a vLLM startup log: KV-cache blocks + GPU-memory-utilization
- ›Watch VRAM drop across FP16 vs AWQ vs FP8
- ›Benchmark tokens/sec, TTFT, p99 across a request-rate sweep
Watch first
Proves: You've served the same model on both engines and can speak to the trade-off from having run it — RadixAttention, structured output, peers not tiers.
runs on your own card
- ›RadixAttention: automatic KV reuse across shared prefixes
- ›Benchmark both engines apples-to-apples on one GPU
- ›When to reach for SGLang vs vLLM
Watch first
Proves: You stand up real GPU observability and read it — FB_USED vs FB_FREE for memory pressure, compute-bound vs memory-bound, what to alert on.
runs on your own card
- ›DCGM exporter needs --gpus all + SYS_ADMIN
- ›Import the community DCGM dashboard (ID 12239) and watch it move under load
- ›In K8s the GPU Operator ships this as a DaemonSet
Proves: You've enabled MIG on a real A100, carved isolated instances, and served a model pinned to one slice — the hardware-isolation claim, defensible.
A100/H100 only — rent it
- ›MIG (hardware isolation) vs time-slicing (oversubscription)
- ›Profile naming (1g.10gb …) and pinning by MIG-UUID
- ›How the GPU Operator makes slices schedulable in K8s
Watch first
Proves: You've run NVIDIA's prepackaged NIM microservices and Triton — the batteries-included, supported serving path — so the NIM/Triton claims are real.
Triton local; many NIMs need a data-center GPU
- ›NIM = prebuilt, GPU-optimized, OpenAI-compatible microservices from nvcr.io
- ›NGC account + API key is the real gate
- ›Triton vs NIM vs vLLM — packaging, optimization, lock-in
Watch first
Proves: The LLMOps + Cloud-Infra-Ops centerpiece: schedule a vLLM pod against nvidia.com/gpu on a real GPU node and curl the endpoint.
local k3s/kind, or managed GKE
- ›GKE GPU node pool path (closest to most JDs) or local k3s + device plugin
- ›Request GPU as a pod resource limit
- ›The NVIDIA device plugin / GPU Operator wiring
Watch first
Proves: The "tuning" skill made explicit: which vLLM knob to turn, when, and how to read the result — the loop of change-one-knob, benchmark, decide.
method matters, not scale — runs local
- ›The three things competing for VRAM (weights, KV-cache, overhead)
- ›Each vLLM knob and when to turn it up vs down
- ›Throughput vs TTFT vs TPOT vs p50/p99 — what you're optimizing
Watch first
Runbooks open as raw markdown — run the commands from your editor. Every provider API, image tag, and cloud flag moves fast; each runbook tells you to verify against current docs rather than trusting a hardcoded value.
Concept decks
the vocabulary + depthThe reading behind the labs — drill these so you can explain weights vs vectors, tokenization → attention → decoding, PagedAttention/KV-cache, MIG/DCGM, and the GCP ramp out loud.
Watch first
Watch first
Watch first
Watch first
Watch first
Watch first
Watch first
Watch first
Skill map — where to practice each thing
role skill → the repA study routine
sustainableCert & skill paths that feed this role
go deeperPrivate interview prep
owner onlyThese are personal, sign-in-gated prep workspaces — they map a specific job description and resume to the content above. Linked here for completeness; they show a lock unless you own them.