Page 4 of 8~104 min topic

Serving Large Language Models

Weigh the tradeoffs

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.

~13 min this pageTradeoffs

1Learn the idea

Read

The live tension

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

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.

Translate into user impact on the multi-tenant chat API when tuning LLM serving. Which error class costs more—missed catches, slower answers, higher spend, or privacy exposure? That ranking picks the default more honestly than a blog’s recommended settings for LLM serving.

Read

Numbers that force honesty

approximate weight memory for 7B parameters at 16 bits = 7B × 2 bytes ≈ 14 GB, before KV cache and runtime overhead Scoped specifically to LLM serving / multi-tenant chat API / tradeoffs.

If the aggressive LLM serving setting wins the headline metric while breaking a protected slice or blowing the latency budget on the multi-tenant chat API, it is not a win. Record intended gain and tolerated regression together for LLM serving.

Read

Make it operational

Revisit the LLM serving tradeoff when traffic shape changes on the multi-tenant chat API. A setting that was right at low volume can fail when a new language segment or document length appears. Tradeoffs expire; re-measure on a calendar, not only on incidents.

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 / tradeoffs.

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 / tradeoffs.

Read

Rehearsal (serving-llms/tradeoffs)

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/tradeoffs)

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

For the multi-tenant chat API, name one regression you will tolerate when pursuing the main benefit of LLM serving, and one regression that is stop-ship.

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.