Page 5 of 8~104 min topic

Serving Large Language Models

Anticipate failure modes

Name failures by their mechanism in LLM serving on the multi-tenant chat API, not with a generic hallucination label.

~13 min this pageFailure modes

1Learn the idea

Read

Response design

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

For each severe LLM serving failure on the multi-tenant chat API, define stop condition, safe state, owner, and lasting prevention. Rollback only works if prior prompts, indexes, and models remain available. “Send to a human” needs queue capacity and context—not just a button name.

Run one tabletop on the multi-tenant chat API for LLM serving: inject a defect, verify detection, contain, recover, and keep the blameless trace.

Read

Make it operational

After the tabletop, store the injected LLM serving defect for the multi-tenant chat API as a regression fixture. If the same failure later reaches users silently, your detection story was aspirational. Detection without a fixture tends to rot for LLM serving.

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 / failure-modes.

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 / failure-modes.

Read

Rehearsal (serving-llms/failure-modes)

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/failure-modes)

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/failure-modes)

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/failure-modes)

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

Invent an incident for the multi-tenant chat API involving LLM serving. What earliest signal should fire before users complain?

KV OOM

Detect with long context kills node. Respond by cap context; isolate long jobs.

Head-of-line blocking

Detect with one 32k prompt stalls chats. Respond by separate queues.

Quota bypass

Detect with noisy neighbor. Respond by per-tenant admission.

Quant regression

Detect with quality cliff after int4. Respond by gold suite per build.

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.