การทดสอบโหลดและการวางแผนความจุ

LLM apps behave differently under load than typical web services: token generation is slow, requests are long-lived, and upstream provider rate limits add a hard ceiling.

Load testing reveals how your system degrades before real users do.

Track these under load:

• Throughput — requests or tokens per second
• Latency percentiles — p50, p95, p99
• Error rate — timeouts, 429s
• Time to first token for streaming

Two ways to generate load:

• Closed — fixed number of virtual users, each waits for a response before sending the next
• Open — requests arrive at a fixed rate regardless of responses

Open-model tests better expose queue buildup.

Use realistic prompts. A test with tiny prompts hides cost; production prompts include long retrieved context. Sample real queries and vary input length to mimic actual token distributions.

Averages lie; percentiles tell the truth about tail latency.

Ramp the request rate gradually until latency or error rate crosses your SLO. That inflection point is your saturation capacity. Run below it in production with headroom.

Use Little's Law: concurrency = arrival rate x average latency. Estimate how many concurrent slots you need for peak traffic.

Your effective capacity may be capped by the LLM provider's tokens-per-minute and requests-per-minute limits, not your servers. Plan around those quotas and request increases ahead of launches.

Run at a target utilization (often 60-70 percent) so spikes do not immediately saturate. Configure autoscaling on a leading signal like queue depth, since CPU is a poor proxy for LLM load.

Beyond steady ramps, run:

• Soak — sustained load for hours to catch leaks
• Spike — sudden surge to test autoscaling reaction

Turn results into a capacity plan: peak rps, required concurrency, provider quota needs, scaling rules, and a cost estimate. Re-test after major changes since model and prompt changes shift the numbers.

You learned to load test LLM apps with realistic workloads, track latency percentiles and error rate, find the saturation point, and size capacity with Little's Law. Account for provider quotas, keep headroom, autoscale on queue depth, and run soak and spike tests.