Page 8 of 8~104 min topic

Serving Large Language Models

Mastery: connect the pieces

You can explain, measure, and bound LLM serving for the multi-tenant chat API without borrowing another topic’s speech.

~13 min this pageMastery check

1Learn the idea

Read

Checklist

See it

Training time vs chat time

Training

Huge dataHeavy computeWeights

Inference

Your promptFrozen modelReply

Training = long study · Inference = quick answer from what it already learned

  1. Idea — Serving turns weights into a concurrent inference service: load, tokenize, schedule, manage KV memory, stream, enforce limits, observe.…
  2. Mechanism — Load weights into GPU/CPU memory, batch prefill/decode, manage KV cache, admit/queue requests, stream tokens, apply auth quotas.…
  3. Controls — precision/quantization, max batch tokens, max context, concurrency, KV budget, admission control, timeouts
  4. Tradeoff — Larger batches improve GPU utilization and tokens per second but can worsen queueing and per-user latency. Quantization reduces memory and may increase throughp…
  5. Failures — KV OOM; Head-of-line blocking
  6. Metrics — tokens/sec, p95 TTFT, p95 TPOT, queue time, OOM rate, cost/1M tokens
  7. Ship rule — Admit long prompts to a separate pool; keep interactive p95 TTFT under SLO at target QPS.

Neighboring layers (retrieval, serving, policy, human review) still own what LLM serving cannot on the multi-tenant chat API. Do not ask this chapter’s dial to replace permissions or source truth.

Read

Make it operational

Mastery is transfer: take LLM serving into a second scenario that is not the multi-tenant chat API and rebuild the checklist without copying sentences. If you can only recite this chapter’s examples for LLM serving, you have memorized a story, not a model.

Also pin one numeric memory from this LLM serving chapter: approximate weight memory for 7B parameters at 16 bits = 7B × 2 bytes ≈ 14 GB, before KV cache and runtime overhead That number is not decoration; it is a template for how claims about LLM serving on the multi-tenant chat API should look in design docs. Scoped specifically to LLM serving / multi-tenant chat API / mastery-connect.

Read

Common mix-ups

People confuse LLM serving with neighboring buzzwords when debugging the multi-tenant chat API. Before changing prompts, ask whether the broken stage was evidence gathering, the LLM serving judgment itself, validation, or the product action. Fixing the wrong stage creates folklore (“we tried LLM serving and it failed”) that blocks the next team on the multi-tenant chat API. Scoped specifically to LLM serving / multi-tenant chat API / mastery-connect.

Read

Rehearsal (serving-llms/mastery-connect)

Write a five-line artifact for this page: goal, inputs, check, owner, stop rule. Invent one fluent failure that the check would catch. Keep details specific to serving llms rather than generic AI advice.

Read

Rehearsal (serving-llms/mastery-connect)

Write a five-line artifact for this page: goal, inputs, check, owner, stop rule. Invent one fluent failure that the check would catch. Keep details specific to serving llms rather than generic AI advice.

Go deeper

Before you start

Why this matters

Teach LLM serving in ninety seconds using the analogy (turning a parked race car into a taxi fleet—scheduling, fuel, and queueing matter as much as horsepower), then replace the analogy with the real artifact names from the LLM serving mechanism page for the multi-tenant chat API.

In the wild

See how this idea shows up as a product and a company — then come back to the lesson. Skills transfer across vendors.

Check your understanding

Page assessment

Answer from memory. Completion is saved from this evidence, not from opening the next page.

1. What is one idea from this page you would apply, and what evidence would you check?

All responses are required.