Testes de carga e planejamento de capacidade
Aprenda a simular tráfego realista contra um aplicativo de LLM, encontrar seu ponto de ruptura e planejar a capacidade para que a produção permaneça rápida e dentro do orçamento sob carga.
Testes de carga e planejamento de capacidade é uma aula grátis de LLM Apps in Production (RAG + Vector DB + Caching) no CoddyKit. Esta é a aula 4 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de LLM Apps in Production (RAG + Vector DB + Caching), e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de LLM Apps in Production (RAG + Vector DB + Caching) inclui 4 aulas no total.
Partes desta aula ainda não foram traduzidas e aparecem em inglês.
Why Load Test LLM Apps?
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.
Key Metrics
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
Open vs Closed Load Models
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.
Realistic Workloads
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.
Percentile Latency in Code
Averages lie; percentiles tell the truth about tail latency.
def percentile(values, p):
s = sorted(values)
idx = int(round((p/100) * (len(s)-1)))
return s[idx]
lat = [120, 130, 140, 900, 150]
print('p95 =', percentile(lat, 95))Finding the Breaking Point
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.
Estimating Required Capacity
Use Little's Law: concurrency = arrival rate x average latency. Estimate how many concurrent slots you need for peak traffic.
def concurrency(rps, avg_latency_s):
return rps * avg_latency_s
print('Need', concurrency(50, 2.0), 'concurrent slots')Accounting for Provider Limits
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.
Headroom and Autoscaling
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.
Soak and Spike Tests
Beyond steady ramps, run:
- Soak — sustained load for hours to catch leaks
- Spike — sudden surge to test autoscaling reaction
From Test to Plan
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.
Quick Check
Test your understanding of capacity planning.
Recap
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.
Aprenda LLM Apps in Production (RAG + Vector DB + Caching) com um tutor de IA — grátis
Escreva e execute código real no seu navegador, obtenha ajuda instantânea de um tutor de IA 24/7 e continue de onde parou na web ou no app.
- Cursos
- 12
- Aulas
- 48
Perguntas Frequentes
A aula “Testes de carga e planejamento de capacidade” é grátis?
Sim — o texto completo de “Testes de carga e planejamento de capacidade” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de LLM Apps in Production (RAG + Vector DB + Caching), atualize para CoddyKit PRO. O curso de LLM Apps in Production (RAG + Vector DB + Caching) inclui 4 aulas no total.
O que vou aprender em “Testes de carga e planejamento de capacidade”?
Aprenda a simular tráfego realista contra um aplicativo de LLM, encontrar seu ponto de ruptura e planejar a capacidade para que a produção permaneça rápida e dentro do orçamento sob carga. Você pratica LLM Apps in Production (RAG + Vector DB + Caching) com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.
Preciso ter experiência prévia para começar LLM Apps in Production (RAG + Vector DB + Caching)?
Nenhuma experiência prévia é necessária. LLM Apps in Production (RAG + Vector DB + Caching) no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 4 de 4.
Quanto tempo leva a aula “Testes de carga e planejamento de capacidade”?
A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.
Posso escrever e executar código nesta aula de LLM Apps in Production (RAG + Vector DB + Caching)?
Sim. Cada aula de LLM Apps in Production (RAG + Vector DB + Caching) inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.
Todas as aulas deste curso
- Dimensionamento Horizontal de Componentes RAG
- Observabilidade: Registros, Métricas e Rastreamento
- Alertas e Resposta a Incidentes em Operações de LLM
- Testes de carga e planejamento de capacidade