Mastery: connect the pieces

A complete explanation of Serving LLMs has four parts. First: Serving an LLM means turning model weights into a reliable, concurrent inference service. The server must load weights, tokenize requests, schedule GPU work, manage memory, stream tokens, enforce limits, and expose observable APIs under changing traffic. Second, the mechanism: Requests enter a queue, are tokenized, and are batched. Prefill processes prompt tokens in parallel; decode then generates one token per active sequence step while retaining a KV cache. Continuous batching inserts and removes sequences dynamically. Memory is consumed by weights, activations, and per-request KV state, so scheduling directly affects throughput and latency. Third, the operational controls: model precision; tensor or pipeline parallelism; batch-token limit; maximum context; concurrency; KV-cache allocation; quantization; timeout; admission control; streaming; and autoscaling target. Fourth, the evidence: Track time to first token, time per output token, end-to-end p50/p95/p99, queue time, prompt and generation tokens per second, concurrent sequences, GPU utilization, KV-cache occupancy, OOMs, and cost per million generated tokens.

Use the scenario as an oral exam: A service receives 20 short chats and one 32k-token prompt. Admission control places the long request in a separate queue so it cannot delay all chats; continuous batching keeps decode slots busy as short requests finish. Defend one design choice, then argue against it using this tradeoff: Larger batches improve GPU utilization and tokens per second but can worsen queueing and per-user latency. Quantization reduces memory and may increase throughput with possible quality loss. Longer contexts expand usefulness while sharply increasing KV memory and prefill work. Finally, identify which of these failures your design catches and which remain: out-of-memory crashes, head-of-line blocking by huge prompts, cold starts, queue growth hidden by average latency, tokenizer mismatch, incompatible quantization, overload retries, no backpressure, and benchmarking throughput at a prompt/output mix unlike production.

Mastery is not recalling every term. It is predicting consequences before running the system, noticing when evidence contradicts the prediction, and revising the design without moving the goalposts. Keep a decision record containing the workload, baseline, configuration, test set version, results, known limitations, owner, and rollback condition.

A service receives 20 short chats and one 32k-token prompt. Admission control places the long request in a separate queue so it cannot delay all chats; continuous batching keeps decode slots busy as short requests finish.

The worked number is approximate weight memory for 7B parameters at 16 bits = 7B × 2 bytes ≈ 14 GB, before KV cache and runtime overhead. State the unit and denominator whenever you report it. A percentage without a denominator can conceal a tiny sample; a latency without a percentile can conceal slow users; a similarity score without a labeled task can conceal irrelevant neighbors. Compare the observed value with a threshold chosen before seeing the final test result.

Now test the tempting shortcut. Suppose the team optimizes only the most visible metric. The result may look better while the system becomes less trustworthy. The reason is concrete: Larger batches improve GPU utilization and tokens per second but can worsen queueing and per-user latency. Quantization reduces memory and may increase throughput with possible quality loss. Longer contexts expand usefulness while sharply increasing KV memory and prefill work. This is why the decision record must include both the intended gain and the tolerated regression. If the tolerated regression is unknown, the change is not ready for a consequential workflow.

• Prefer a measured baseline over a persuasive demo.
• Keep versions, inputs, and thresholds reproducible.
• Separate syntactic success from semantic correctness and authorization.
• Escalate or abstain when evidence falls outside the contract.
• Re-evaluate when data, traffic, models, providers, or user goals change.

These rules turn the topic into an engineering decision rather than a slogan. They also make disagreement productive: another person can challenge the assumptions, rerun the evaluation, and reach a documented conclusion.

Give a three-minute teach-back with no slides. Minute one: define the technique and its boundary. Minute two: trace the mechanism using the worked case and calculation. Minute three: defend the chosen controls with evaluation evidence, then name the strongest unresolved failure. Ask the listener to change one assumption and update your recommendation aloud. You have mastered the topic when the recommendation changes for a technical reason—not because the vocabulary changed—and when you can specify the next experiment that would reduce the most consequential uncertainty.