LLM and Foundation Models for ML Engineers (2026)

The architectural trade-off space: fine-tune, prompt, RAG

Senior MLE interviews probe the three-way architectural trade-off between fine-tuning an open model, prompt-engineering a frontier API, and retrieval-augmented generation. None is the right answer in all cases; the decision depends on the problem.

A worked example. Suppose you are building a customer-support assistant for a fintech company with 5M monthly active users. Three approaches:

1. Frontier API + RAG. Anthropic Claude API + a vector DB indexing the company's help-center articles. Time to impact: 2–3 weeks. Cost: ~$15k/month at scale. Customization: prompt only.
2. Fine-tuned open model + RAG. Qwen 3 14B fine-tuned on internal support transcripts via LoRA, served via vLLM, paired with a vector DB. Time to impact: 8–10 weeks. Cost: ~$3k/month at the same scale (mostly inference compute). Customization: full.
3. Hybrid. Use the frontier API for the v0 (week 2 launch); migrate to fine-tuned open model in v1 (month 3) once the eval-set proves the open model can match. Reduces time-to-impact while controlling long-run cost.

Senior MLE recommendation: the hybrid pattern is correct in most cases. Frontier API for prototyping (you do not know what the eval-set should look like until you have a working v0); open-model fine-tune for production (cost-control + customization + data-locality). The 'never use the API; always fine-tune' opinion is junior; the 'always use the API; never fine-tune' opinion is also junior. Senior is articulating when each binds.

Fine-tuning with PEFT/LoRA: a worked code example

Fine-tuning an open foundation model with LoRA is the canonical mid-level MLE workflow in 2026. A worked example using Hugging Face transformers + peft on Qwen 3 7B for a domain-specific task:

from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments
from peft import LoraConfig, get_peft_model, TaskType
from trl import SFTTrainer

MODEL_NAME = "Qwen/Qwen3-7B"

# 1. Load the base model in 4-bit quantization for memory efficiency
model = AutoModelForCausalLM.from_pretrained(
    MODEL_NAME,
    load_in_4bit=True,
    device_map="auto",
)
tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME)

# 2. Apply LoRA — adds ~1% trainable parameters
lora_config = LoraConfig(
    task_type=TaskType.CAUSAL_LM,
    r=16,                    # rank of the low-rank decomposition
    lora_alpha=32,           # scaling factor (typically 2x rank)
    lora_dropout=0.05,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
)
model = get_peft_model(model, lora_config)
model.print_trainable_parameters()
# Output: trainable params: 41M || all params: 7.62B || trainable%: 0.54

# 3. Train with SFTTrainer (HF TRL library)
trainer = SFTTrainer(
    model=model,
    train_dataset=train_dataset,    # your formatted dataset
    tokenizer=tokenizer,
    args=TrainingArguments(
        output_dir="./qwen3-finetune",
        num_train_epochs=3,
        per_device_train_batch_size=4,
        gradient_accumulation_steps=4,    # effective batch = 16
        learning_rate=2e-4,                # higher than full fine-tune
        warmup_steps=100,
        lr_scheduler_type="cosine",
        bf16=True,
        logging_steps=10,
        save_steps=500,
        report_to="wandb",                 # log to Weights & Biases
    ),
)
trainer.train()

# 4. Save the LoRA adapter (small — ~80MB instead of ~14GB for full model)
model.save_pretrained("./qwen3-lora-adapter")

The senior MLE conversation around this code: why r=16? (Empirically a strong default; r=8 is often fine for simple tasks, r=32 for complex.) Why 4-bit quantization? (QLoRA — Dettmers et al. 2023 — reduces memory by 4x with minimal quality loss; allows fine-tuning 7B models on a single 24GB GPU.) Why target only attention projections? (Most parameter-efficient; targeting MLP layers gives marginal additional capacity at substantial parameter cost.) Why higher LR than full fine-tune? (LoRA parameters are randomly initialized; need higher LR to learn quickly.)

Real production fact: Hugging Face's peft library (github.com/huggingface/peft) is the canonical reference implementation. The library supports LoRA, QLoRA, prefix-tuning, P-tuning, and others, with consistent API across techniques.

Eval design: a senior-level worked example

Eval-set design is the load-bearing skill at AI-labs and at production-LLM teams. The bar at senior+: design an eval that captures the capability you care about, is contamination-resistant, has multiple metric dimensions, and produces actionable signal.

A worked example. Suppose you are evaluating a customer-support LLM. The naive approach: 'I tested it on 50 questions and it got 42 right.' This is junior. The senior approach:

1. Inclusion criteria. Define what makes an example a real test of the capability. For customer-support: questions that have a single correct answer, are representative of real user query distribution, and were not in the training data.
2. Multi-dimensional metrics. Factual accuracy (does the answer contain claims that match the source-of-truth). Faithfulness (does it omit critical information). Calibration (does the model express appropriate confidence). Refusal-rate (does it refuse when it should not know).
3. Adversarial / red-team examples. Jailbreak attempts. Out-of-domain queries. Queries with subtle errors that a careless model would propagate.
4. Contamination-resistance. Do not use questions that exist verbatim on public web (they might be in training data). Generate fresh questions or use a private held-out dataset.
5. Distribution-matched. The eval set should match production query distribution. If 70% of production queries are about billing, 70% of the eval set should be billing.

Real frameworks: lm-evaluation-harness (github.com/EleutherAI/lm-evaluation-harness) is the canonical open-source LLM eval framework — supports MMLU, GSM8K, HumanEval, BBH, and dozens of other benchmarks with reproducible methodology. OpenAI evals (github.com/openai/evals) is OpenAI's open-source framework. For production-specific evals, teams typically build internal eval-harnesses on top of one of these.

Failure modes of common practice: (1) evaluating only on public benchmarks (MMLU, GSM8K) — these are likely contaminated and do not reflect production performance; (2) using a single metric (accuracy) — masks calibration and faithfulness failures; (3) evaluating only on the model's strong cases — produces optimistic estimates. The Anthropic and OpenAI public model cards (anthropic.com/news, openai.com/index) are the canonical examples of multi-dimensional eval reporting at frontier-lab quality.

Inference deployment: vLLM, TGI, quantization

Inference deployment for open foundation models in 2026 happens primarily via two frameworks:

• vLLM (github.com/vllm-project/vllm). The most-deployed open-source inference framework. Supports continuous batching (the PagedAttention paper at vllm.ai), paged attention (memory-efficient KV-cache management), tensor parallelism, and quantization. Production throughput is typically 5–20x naive transformers.generate() throughput.
• TGI (Hugging Face Text Generation Inference, github.com/huggingface/text-generation-inference). The HF stack equivalent. Similar capabilities to vLLM with deeper integration into the HF ecosystem.

Quantization is the standard production technique for cost reduction. Three patterns:

1. INT8 quantization (bitsandbytes, github.com/bitsandbytes-foundation/bitsandbytes). 2x memory reduction with minimal quality loss. The standard default for 7B–13B models on consumer GPUs.
2. INT4 quantization (GPTQ, AWQ). 4x memory reduction with measurable quality loss. Required for fitting 70B+ models on single GPUs.
3. FP8 quantization (TensorRT-LLM). Hardware-accelerated on H100 and newer GPUs. Production deployments at OpenAI, Anthropic, and several FAANG inference platforms use FP8.

The senior MLE deployment conversation: 'How would you serve a fine-tuned Qwen 3 14B model at 1000 QPS p99 latency 1.5s?' Expected answer: vLLM with paged attention + tensor parallelism across 2-4 H100s, FP8 quantization for cost reduction, autoscaling based on queue depth, monitoring on per-token latency and GPU utilization. The naive answer ('use Anthropic API') is sometimes correct (depends on cost) but does not engage with the question.