llm serving

The canonical AI system-design question. The signal is covering both the model lifecycle and the serving stack at real scale, without rambling. Most candidates design only half and lose the points.

Inline completion lives or dies on tail latency: a suggestion that lands after the developer keeps typing is useless. Learn how to assemble the context window, hide model latency behind speculation and caching, and keep a tight feedback loop on acceptance rate.

Personalizing an LLM is a retrieval and memory problem, not a per-user fine-tune. Learn how to assemble user context at request time, keep long-term memory from bloating the prompt, and respect privacy and the right to be forgotten.

A writing assistant has to feel instant as the cursor moves through a live document. Learn how to separate fast deterministic checks from LLM rewrites, stream suggestions, and keep edits stable so the text does not flicker while the user types.

SSE versus WebSocket is the easy half. The half that separates candidates: a buffer-everything output filter throws away the time-to-first-token you paid a GPU to deliver, and you cannot send an HTTP error after the 200 has already flushed.

Five thousand businesses, five thousand assistants, one platform. The hard parts are tenant isolation you can defend, noisy neighbors, onboarding a tenant with zero data, and evaluating assistants you can never manually QA. Here is the control plane and the data plane.

CPU-based autoscaling that suits a web tier quietly breaks on GPU inference: the signal is wrong, and replicas need minutes to warm. The interviewer wants the signals you genuinely scale on and how you mask the cold start.