Перейти к основному содержимому
Основной•8–14 часов

Лаборатория AI Capacity, Cost & Chaos

Проверьте AI workload под нагрузкой: concurrency, бюджеты tokens/tools, очереди, backpressure, 429/5xx/timeouts, load shedding, degraded mode и стоимость успешной верифицированной задачи.

capacity planningautoscalingочередиbackpressurefailure injectionAI unit economics

Сценарий

Задача

AI endpoint стабилен под демо-нагрузкой, но production traffic имеет всплески arrival rate, длинные contexts, параллельные tool calls и provider quotas. Простое CPU autoscaling не решает token throughput, задержку очереди, 429, retry amplification или рост стоимости. Постройте capacity model, которая измеряет успешно верифицированные задачи, а не только число запущенных pods.

Пошаговое выполнение

1. Постройте workload model

Результат: Capacity planning учитывает AI-specific demand, а не среднее число HTTP requests.

Задачи

  • →Измерьте arrival rate и burstiness
  • →Соберите распределения input/output tokens
  • →Зафиксируйте tool-call fan-out и самую медленную dependency
  • →Разделите user-facing, batch и high-priority workloads

Проверки

  • ✓P95/P99 workload отличается от среднего случая
  • ✓Неизвестные quota или provider limits помечены как риск
  • ✓Priority policy не допускает starvation критических задач

2. Установите budgets и scaling signals

Результат: Autoscaling реагирует на saturation, queue и token throughput, а не только CPU.

Задачи

  • →Определите concurrency ceiling
  • →Установите token/tool/time budgets
  • →Добавьте queue age/depth и saturation signals
  • →Рассчитайте стоимость успешной верифицированной задачи

Проверки

  • ✓Исчерпание бюджета завершает или деградирует задачу контролируемо
  • ✓Scaling signal имеет causal relation к bottleneck
  • ✓Failed или unsafe tasks не считаются успешными

3. Проведите chaos/load tests

Результат: Известные overload и dependency failures имеют предсказуемую системную реакцию.

Задачи

  • →Инжектируйте 429/5xx/timeouts
  • →Задержите tool/retrieval dependency
  • →Создайте burst long-context requests
  • →Проверьте retry amplification и queue recovery

Проверки

  • ✓Нет infinite retries или unbounded queue growth
  • ✓Load test не обходит tenant/risk limits
  • ✓Recovery не создаёт второй spike через synchronized retries

4. Проверьте graceful degradation

Результат: При дефиците capacity система сокращает функциональность, а не контроль.

Задачи

  • →Протестируйте load shedding
  • →Используйте lower-cost/fallback model только для eligible tasks
  • →Отключите non-essential tools
  • →Зафиксируйте recovery и normal-mode re-entry criteria

Проверки

  • ✓Fallback проходит минимальный eval contract
  • ✓Degraded mode не повышает autonomy
  • ✓Normal mode возвращается только после стабилизации dependencies

Критерии приёмки

  • Workload model содержит burst, token, tool, queue и provider-quota характеристики
  • Capacity policy имеет bounded concurrency/token/tool/time budgets и explicit autoscaling signals
  • Chaos suite покрывает 429, 5xx, timeout, slow dependency, quota exhaustion и retry amplification
  • Есть load shedding/degraded mode с неизменными authority и privacy boundaries
  • Стоимость оценивается как cost per successful verified task, а не cost per request