Архитектура ИИ-систем

Вы запустили демонстрацию большой модели на ноутбуке, и она работает хорошо, но когда вы хотите превратить её в реальный продукт, возникают проблемы:

В модели слишком много параметров, чтобы поместиться на одной GPU. Что вы делаете?
Обучение занимает недели; если в середине происходит сбой, как возобновить обучение с контрольной точки?
При миллионах пользовательских запросов в день как гарантировать задержку менее 1 секунды?
Как собирать обратную связь от пользователей, чтобы модель непрерывно развивалась?

Это проблемы, которые должна решать архитектура ИИ-систем.

Демо ориентировано на то, запустится ли оно; продакшн-система — на то, будет ли она работать стабильно, эффективно и с низкими затратами.

Характеристики ИИ-систем промышленного уровня: доступность 7x24, поддержка миллионов одновременных запросов, наблюдаемость, масштабируемость, надежное аварийное восстановление и контролируемая стоимость.

Особые вызовы ИИ-систем

По сравнению с традиционными веб-сервисами у ИИ-систем есть три уникальных вызова.

Вызов 1: Неопределенный вывод

Вывод традиционных систем детерминирован — вы вводите 1+1, и он всегда возвращает 2.

Вывод ИИ-систем вероятностен — один и тот же промпт может каждый раз давать разные результаты.

Это порождает несколько проблем: как гарантировать качество вывода? Как оценивать результаты? Как обрабатывать галлюцинации?

Типичные решения: добавление стратегий сэмплирования на выходном слое, пост-фильтрация результатов, замкнутый цикл обратной связи от человека и мультимодельное голосование.

Вызов 2: Компромисс между задержкой и стоимостью

Инференс ИИ требует большого объёма вычислений, что означает естественное противоречие между задержкой и стоимостью.

Хотите скорости? Используйте больше GPU — затраты резко растут.

Хотите сэкономить? Ставьте обработку в очередь — плохой пользовательский опыт.

Суть продакшн-системы — найти баланс между SLA (соглашение об уровне обслуживания) и стоимостью.

Направление оптимизации	Распространённые методы	Эффект
Сжатие модели	Квантование, прунинг, дистилляция	Ускорение 2-4x, небольшое снижение точности
Оптимизация инференса	vLLM, TensorRT, FlashAttention	Улучшение пропускной способности в 3-10 раз
Проектирование архитектуры	Пакетная обработка, многоуровневое кэширование	Стоимость одного запроса снижена на 50%-80%

Задача 3: Построение маховика данных

AI-система не становится "готовой после запуска"; она требует непрерывных итераций.

Чем больше пользователей её используют, тем больше данных обратной связи, тем лучше можно обучить модель, и тем охотнее пользователи готовы её использовать — это и есть маховик данных.

Но раскрутить маховик непросто: как собирать эффективную обратную связь? Как размечать данные? Как продолжать обучение? Как оценивать новые версии?

На эти вопросы нет стандартных ответов, но у каждого успешного AI-продукта есть собственный дизайн маховика.

Инфраструктура крупномасштабного обучения

Обучение больших моделей с сотнями миллиардов или даже триллионами параметров требует суперкомпьютерной инфраструктуры.

Архитектура GPU-кластера

Современные кластеры для обучения ИИ обычно состоят из сотен или тысяч GPU.

Возьмём в качестве примера GPU H100: один H100 имеет 80GB памяти, вычислительная мощность — 1979 TFLOPS при точности FP8.

Но одной GPU далеко не достаточно—для обучения GPT-3 использовалось около 355 V100s и это заняло 3 месяца.

Типичная топология кластера выглядит так:

Уровень	Устройство	Способ подключения	Пропускная способность
Внутри одной машины	GPU-GPU	NVLink	900GB/s
В одной стойке	Сервер-сервер	InfiniBand	400Gb/s
Между стойками	Коммутатор-коммутатор	Инфраструктура InfiniBand	400Gb/s

Сеть — узкое место распределённого обучения. Если пропускной способности связи недостаточно, загрузка GPU может упасть с 90% до 30%, при этом большая часть времени уходит на ожидание данных.

Высокоскоростное соединение InfiniBand

Обычный Ethernet слишком медленный; в распределённом обучении используется InfiniBand.

Особенности InfiniBand: чрезвычайно низкая задержка (микросекундный уровень), чрезвычайно высокая пропускная способность и поддержка RDMA (Remote Direct Memory Access).

RDMA позволяет одному GPU напрямую читать и записывать память GPU другого сервера, не проходя через ядро операционной системы, что делает работу значительно быстрее.

Проектирование системы хранения

Обучающие данные обычно имеют объём в терабайтах или даже петабайтах, поэтому система хранения также требует тщательного проектирования.

Типичная многоуровневая архитектура хранения:

Горячие данные: SSD или NVMe, хранящие текущий обучающий батч
Тёплые данные: распределённое хранилище (например, Ceph, Lustre), хранящее полный обучающий набор
Холодные данные: объектное хранилище (например, S3), хранящее исторические данные и резервные копии

Отказоустойчивость и контрольные точки

Обучение длится недели — что, если за это время выйдет из строя GPU? Начинать заново слишком расточительно.

Решение — этоконтрольные точки: периодическое сохранение состояния модели на диск и восстановление из последней контрольной точки при возникновении ошибки.

Но у контрольных точек есть и издержки: одно сохранение может занять несколько минут и занять десятки ГБ пространства.

Обычная стратегия такова: сохранять каждые несколько сотен шагов, хранить самые последние контрольные точки и автоматически удалять старые.

Стратегии распределённого обучения

Одна GPU не может вместить большую модель, поэтому задача обучения должна быть разделена между несколькими GPU.

В основном существует три стратегии параллелизации: параллелизм данных, тензорный параллелизм и конвейерный параллелизм. Их сочетание — это 3D-параллелизм.

3D 并行策略示意图

Параллелизм данных

Самая простая и распространённая стратегия: каждая GPU хранит полную копию модели, но обрабатывает разные данные.

Например, при 8 GPU и размере батча 1024 каждая GPU обрабатывает 128 образцов.

Прямое распространение выполняется независимо, а после обратного распространения градиенты собираются и усредняются, затем модель обновляется.

Проблема параллелизма данных в том, что память всё ещё остаётся узким местом — если модель слишком велика для одной GPU, параллелизм данных бесполезен.

Оптимизация памяти ZeRO

ZeRO (Zero Redundancy Optimizer) — это улучшенная версия параллелизма данных, которая дополнительно экономит память.

При обычном параллелизме данных каждая GPU хранит полные параметры модели, градиенты и состояния оптимизатора — это избыточно.

Идея ZeRO состоит в том, чтобы разделить эти состояния между разными GPU и обмениваться ими при необходимости.

Этап ZeRO	Что разделяется	Экономия памяти
ZeRO-1	Состояния оптимизатора	~4x
ZeRO-2	Состояния оптимизатора + градиенты	~8x
ZeRO-3	Состояния оптимизатора + градиенты + параметры	Линейно от количества GPU

Настройка ZeRO с DeepSpeed проста:

{
"train_batch_size": 1024,
"train_micro_batch_size_per_gpu": 16,
"optimizer": {
"type": "Adam",
"params": {
"lr": 0.0001,
"betas": [0.9, 0.95],
"eps": 1e-8,
"weight_decay": 0.01
}
},
"zero_optimization": {
"stage": 3,
"allgather_partitions": true,
"allgather_bucket_size": 2e8,
"overlap_comm": true,
"reduce_scatter": true,
"reduce_bucket_size": 2e8,
"contiguous_gradients": true,
"stage3_prefetch_bucket_size": 1e8,
"stage3_param_persistence_threshold": 1e5,
"stage3_max_live_parameters": 1e9,
"stage3_max_reuse_distance": 1e9
},
"gradient_clipping": 1.0,
"fp16": {
"enabled": true,
"loss_scale": 0,
"loss_scale_window": 1000,
"initial_scale_power": 16,
"hysteresis": 2,
"min_loss_scale": 1
},
"checkpoint": {
"tag": "example-checkpoint",
"load_universal": true
}
}

Эта конфигурация использует ZeRO-3, который может распределять состояния модели по всем GPU, линейно уменьшая использование памяти с увеличением количества GPU.

Тензорный параллелизм

Если ZeRO всё ещё недостаточно, используйте тензорный параллелизм — разделите вычисление одного слоя между несколькими GPU.

Матричные умножения в трансформерах можно разделять по строкам или столбцам:

Разделите матрицу A по строкам на A₁ и A₂ и вычислите A₁×B и A₂×B на GPU 0 и GPU 1 соответственно
Наконец, объедините результаты

Таким образом, каждый слой требует коммуникации, но использование памяти GPU также сокращается вдвое.

Megatron-LM — это библиотека тензорного параллелизма от NVIDIA с отличной совместимостью с PyTorch.

Конвейерный параллелизм

Тензорный параллелизм — это «разделение внутри слоя»; конвейерный параллелизм — «разделение между слоями».

Например, для 32-слойной модели GPU 0 содержит первые 8 слоёв, GPU 1 — следующие 8 слоёв, GPU 2 — ещё 8 слоёв, а GPU 3 — последние 8 слоёв.

Данные проходят от GPU 0 к GPU 3, точно как на заводской сборочной линии.

Но у конвейеров есть проблема: пузырь — когда GPU 0 начинает вычисления, GPU 1-3 простаивают; когда данные доходят до GPU 1, GPU 0 снова простаивает.

Решение — разбить данные на микробатчи и заполнять их как на сборочной линии, сокращая время пузыря.

Трёхмерный параллелизм (DP+TP+PP)

Эти три стратегии можно комбинировать:

Конвейерный параллелизм: разделение слоёв модели между узлами
Тензорный параллелизм: разделение вычислений внутри слоя в пределах узла
Параллелизм данных: реплицируйте весь конвейер в большем масштабе

Например, с 64 GPU можно спланировать так:

8 стадий конвейера (PP=8)
Используйте 2 GPU для тензорного параллелизма внутри каждой стадии (TP=2)
Затем реплицируйте это 4 раза для параллелизма данных (DP=4)
Итого: 8 × 2 × 4 = 64 GPU

Это 3D-параллелизм — стандартная конфигурация для обучения современных больших моделей.

Инженерия данных

Хорошие модели требуют хороших данных — инженерия данных составляет более 60% рабочей нагрузки в системах ИИ.

Конвейер сбора и очистки данных

Обучающие данные обычно поступают из нескольких источников: веб-страницы, книги, код, диалоги и т. д.

Типичный поток обработки:

Дедупликация: Удаление дублирующихся или очень похожих документов
Фильтрация по качеству: Удаление низкокачественного, токсичного или предвзятого контента
Унификация формата: Преобразование разных источников в единый формат
Токенизация: Преобразование текста во входные последовательности модели

Дедупликация данных: MinHash LSH

Прямое вычисление попарного сходства документов слишком медленно; распространённый подход — MinHash + LSH (Locality-Sensitive Hashing).

Идея такова: превратить каждый документ в короткий «отпечаток»; похожие документы, вероятно, будут иметь одинаковые или похожие отпечатки, затем сгруппировать по отпечатку.

Пример

import hashlib
import re
from typing import List, Set, Dict, Tuple

def generate_shingles(text: str, k: int = 5) -> Set[str]:
"""Генерирует k-шинглы: последовательности из k подряд идущих слов Например "I love example tutorial", k=2 → {"I love", "love example", "example tutorial"} # Простая токенизация (в реальных сценариях можно использовать профессиональный инструмент токенизации) """
"""Генерирует сигнатуры MinHash Используйте несколько хеш-функций, каждая берёт минимальное значение # Используйте i как seed для генерации разных хеш-функций # Объедините shingle и i, чтобы получить хеш-значение """
"""
"""Сгенерировать ключи LSH с помощью метода полос Разделить сигнатуру на несколько полос, хешировать каждую полосу отдельно # Хешировать эту полосу, чтобы сгенерировать ключ """
words = re.findall(r'\w+', text.lower())
shingles = set()
for i in range(len(words) - k + 1):
shingle = ' '.join(words[i:i+k])
shingles.add(shingle)
return shingles

def minhash_signature(shingles: Set[str], num_hashes: int = 100) -> List[int]:
"""Дедуплицировать документы с помощью MinHash + LSH Вернуть список документов без дубликатов # Хранилище: ключ LSH → список индексов документов # Хранилище: индекс документа → сигнатура # Отметка: какие документы являются дубликатами # Проверить, существует ли уже похожий документ # В этой корзине уже есть документы, сравнить схожесть сигнатур по одной # Вычислить схожесть сигнатур (приближение Jaccard) # Выше порога считается дубликатом # Не дубликат, добавить себя во все корзины """
Использовать несколько хеш-функций, каждая берёт минимальное значение
"""
signature = []
for i in range(num_hashes):
# Использовать i в качестве начального значения для генерации различных хеш-функций
min_hash = None
for shingle in shingles:
# Объединить shingle и i для генерации хеш-значения
h = hashlib.sha256(f"{shingle}-{i}".encode()).hexdigest()
h_int = int(h, 16)
if min_hash is None or h_int < min_hash:
min_hash = h_int
signature.append(min_hash)
return signature

def lsh_banding(signature: List[int], bands: int = 20) -> List[str]:
"""Использовать бакетирование (Banding) для генерации LSH-ключей
Разделите сигнатуру на несколько полос и хэшируйте каждую полосу отдельно.
"""
keys = []
rows_per_band = len(signature) // bands
for i in range(bands):
start = i * rows_per_band
end = start + rows_per_band
band = tuple(signature[start:end])
# Сгенерировать ключ для хэша этой полосы
band_hash = hashlib.sha256(str(band).encode()).hexdigest()[:16]
keys.append(f"band-{i}-{band_hash}")
return keys

def deduplicate_documents(documents: List[str],
threshold: float = 0.7) -> List[str]:
"""Использовать MinHash + LSH для дедупликации документов
Возвращает дедуплицированный список документов
"""
# Хранилище: ключ LSH → список индексов документов
buckets: Dict[str, List[int]] = {}
# Хранилище: индекс документа → сигнатура
signatures: Dict[int, List[int]] = {}
# Отметить: какие документы являются дубликатами
duplicates: Set[int] = set()

for idx, doc in enumerate(documents):
shingles = generate_shingles(doc)
sig = minhash_signature(shingles)
signatures[idx] = sig
keys = lsh_banding(sig)

# Проверить, существуют ли уже похожие документы
is_duplicate = False
for key in keys:
if key in buckets:
# В этой корзине уже есть документы, сравните схожесть сигнатур по одной
for other_idx in buckets[key]:
other_sig = signatures[other_idx]
# Вычислить сходство сигнатур (приближение Жаккара)
matches = sum(1 for a, b in zip(sig, other_sig) if a == b)
similarity = matches / len(sig)
if similarity >= threshold:
# Превышает порог, считается дубликатом
is_duplicate = True
duplicates.add(idx)
break
if is_duplicate:
break

if not is_duplicate:
# Не дубликат; добавить себя в каждую корзину
for key in keys:
if key not in buckets:
buckets[key] = []
buckets[key].append(idx)

Python — это лаконичный и элегантный язык, подходящий для начинающих.
return [doc for idx, doc in enumerate(documents) if idx not in duplicates]

# ============================================
Машинное обучение позволяет компьютерам выявлять закономерности в данных.
# ============================================
if __name__ == "__main__":
документы = [
Это совершенно другая статья.,
"Добро пожаловать в пример руководства, это отличное место для изучения программирования.", # Очень похоже
"Python — это лаконичный и элегантный язык, подходящий для начинающих.",
"Python — лаконичный и элегантный язык программирования, очень подходит для начинающих.", # Очень похоже
"Машинное обучение позволяет компьютерам выявлять закономерности в данных.",
"Это совершенно другая статья.",
]

print(f"До удаления дубликатов: {len(documents)} документов")
deduplicated = deduplicate_documents(documents, threshold=0.6)
print(f"После удаления дубликатов: {len(deduplicated)} документов"\n")

print("Оставшиеся документы:")
for i, doc in enumerate(deduplicated):
print(f" [{i}] {doc}")

# Вывод:
# До удаления дубликатов: 6 документов
# После удаления дубликатов: 4 документа
#
# Сохранённые документы:
#
#
#
#

В реальном производстве используются более эффективные реализации (например, библиотека datasketch), но основная идея та же.

Формат данных: WebDataset

Небольшие наборы данных можно хранить как угодно, но наборы данных уровня терабайт требуют специального формата.

WebDataset — распространённый вариант: он упаковывает файлы в tar-архивы, каждый tar содержит тысячи образцов и поддерживает как произвольный, так и последовательный доступ.

Преимущества:

Снижает нагрузку на файловую систему (миллионы маленьких файлов работают медленно)
Поддерживает потоковое чтение, не нужно загружать весь набор данных в память
Можно загружать распределённо, при этом каждый worker читает свой tar

Дизайн маховика данных

Маховик данных — это защитное преимущество ИИ-продуктов: больше пользователей — больше данных — лучше модели — больше пользователей.

Сбор данных обратной связи от пользователей

Обратная связь бывает двух типов: явная и неявная.

Явная обратная связь: пользовательские лайки, дизлайки, правки и перегенерации
Неявная обратная связь: время удержания пользователя, копирования, репосты и длительность сессии

Явная обратная связь качественная, но её мало; неявная обратная связь обильна, но зашумлена.

Хорошая система обратной связи сочетает оба подхода — явную обратную связь используют для обучения моделей вознаграждения, а неявную — для A/B-тестирования.

Автоматизированная разметка данных

Ручная разметка слишком дорога и медленна; текущий тренд — «использовать модели для разметки моделей».

Распространённые стратегии:

Сильные модели размечают слабые: использовать данные, размеченные GPT-4, для обучения маленьких моделей
Бутстрап: использовать существующие модели для генерации кандидатов, затем вручную фильтровать
Синтетические данные: использовать модели для генерации разнообразных обучающих данных

Стратегия непрерывного обучения

Модели не «обучены раз и навсегда»; мир меняется, и модели должны меняться соответственно.

Типичный процесс непрерывного обучения:

Ежедневно собирать новые данные о взаимодействии пользователей
Раз в неделю делать небольшое обновление (SFT, дообучение с учителем)
Раз в месяц делать крупное обновление (продолжение предварительного обучения + SFT + RLHF)
Запускать A/B-тесты для каждого обновления и полностью внедрять только после подтверждения эффекта

При непрерывном обучении нужно обращать внимание на «катастрофическое забывание» — если модель обучена на слишком большом объеме новых данных, она может забыть предыдущие способности. Решение — хранить «буфер воспроизведения» и смешивать старые и новые данные в каждой сессии обучения.

Архитектура корпоративной платформы ИИ

Полноценная корпоративная платформа ИИ обычно включает следующие компоненты.

Реестр моделей и управление версиями

Чем больше моделей, тем сложнее управление — нужен централизованный реестр моделей.

В реестре должны фиксироваться:

Файлы моделей (веса, конфигурация, токенизатор)
Номера версий и журналы изменений
Источники обучающих данных и гиперпараметры
Метрики оценки
Статус развёртывания

MLflow, Weights & Biases и Hugging Face Hub — все это широко используемые инструменты.

Хранилище признаков

Многим приложениям ИИ требуется конструирование признаков — профили пользователей, историческое поведение, контекстная информация и т. д.

Хранилище признаков — это система управления признаками, которая решает несколько проблем:

Перекос между обучением и выводом: Несогласованность между признаками, используемыми при обучении и выводе
Повторное использование признаков: Разные модели могут совместно использовать признаки
Согласованность онлайн/офлайн: Признаки вычисляются офлайн, считываются онлайн с низкой задержкой

Типичная архитектура: пакетные вычисления офлайн с помощью Spark или Flink, чтение с низкой задержкой онлайн с помощью Redis или Cassandra.

Сервис онлайн- и офлайн-инференса

Инференс делится на два сценария с разными архитектурами:

Сценарий	Требование к задержке	Архитектура	Пример
Онлайн-инференс	Уровень миллисекунд	API в реальном времени + батчинг	Чат-боты, поиск
Офлайн-инференс	Уровень часов/дней	Очередь пакетных заданий	Модерация контента, генерация отчётов

Сервисам онлайн-инференса нужно учитывать:

Батчинг: объединение нескольких запросов и совместные вычисления для повышения пропускной способности
Динамический батчинг: используйте vLLM или Text Generation Inference для динамического батчинга
Кэширование: K/V Cache ускоряет авторегрессионную генерацию; результаты для популярных промптов кэшируются напрямую
Балансировка нагрузки: несколько экземпляров модели, интеллектуальная маршрутизация

Сквозной мониторинг

Проблемы ИИ-систем трудно диагностировать — нужна наблюдаемость.

Несколько аспектов мониторинга:

Системные метрики: загрузка GPU, VRAM, задержка, пропускная способность, частота ошибок
Метрики модели: длина вывода, частота повторений, распределение стоп-слов
Бизнес-метрики: удовлетворённость пользователей, коэффициент удержания, доля выполненных задач

Классический стек: Prometheus + Grafana для метрик, ELK для логов, Jaeger для трассировки.

Система оценки и бенчмарков

Как узнать, стала ли модель лучше или хуже? Вам нужна система оценки.

Бенчмарки общих способностей

Часто используемые в академической среде бенчмарки:

Бенчмарк	Содержание тестирования	Типичные задачи
MMLU	Многозадачное понимание языка	Вопросы с выбором ответа по 57 предметам
HumanEval	Генерация кода	164 задачи по программированию
MBPP	Генерация кода	974 задачи по Python
TruthfulQA	Фактологичность	817 вопросов для проверки галлюцинаций
GSM8K	Математические рассуждения	8000 задач по математике для начальной школы

Китайские бенчмарки

Высокие результаты на английских бенчмарках не означают высоких результатов на китайском; нужны бенчмарки, специфичные для китайского языка:

C-Eval: понимание китайского языка в многозадачном режиме, 13,948 вопросов с несколькими вариантами ответа
CMMLU: китайское мультимодальное понимание (в настоящее время в основном текст)
AGIEval: вопросы китайского экзамена Gaokao, вопросы экзамена на государственную службу

Настраиваемые наборы для оценки бизнеса

Публичные бенчмарки — это основа, но ваш собственный набор для оценки бизнеса важнее.

Как создать:

Собирайте реальные запросы пользователей (от сотен до тысяч)
Вручную разметьте "хорошо/средне/плохо" или оцените их
Разделите на тестовый и валидационный наборы (тестовый набор фиксирован, не трогайте его)
Запускайте его при каждом обновлении модели, чтобы видеть изменения метрик

Ваш бизнес-набор для оценки — это ваш "золотой стандарт" — он важнее любого публичного бенчмарка.

Мультитенантные сервисы ИИ

Если вы создаёте ToB-продукт, мультитенантность — неизбежная тема.

Изоляция тенантов

Изоляция имеет несколько уровней:

Уровень изоляции	Ресурсы	Преимущества	Недостатки
Физическая изоляция	Выделенные машины с GPU	Полная изоляция, безопасно	Высокая стоимость
Изоляция K8s	Выделенные Pod/Namespace	Балансирует стоимость и безопасность	Требует планирования
Логическая изоляция	Общие ресурсы, контроль прав доступа	Наименьшая стоимость	Риск утечки

Обычная стратегия: физическая изоляция для крупных клиентов, логическая изоляция для малых и средних клиентов.

Управление совместным использованием моделей и тонкой настройкой

Частое требование мультитенантности: обучить проприетарную модель на моих данных.

Архитектура должна поддерживать:

Общее хранилище для базовых моделей
LoRA-адаптер каждого арендатора хранится отдельно
Динамически загружать LoRA соответствующего арендатора во время инференса

Это экономит много памяти GPU — не нужно загружать полную модель для каждого арендатора.

Биллинг и квоты

AI-сервисы дороги, поэтому биллинг должен быть гранулярным:

Биллинг по токенам (входные и выходные рассчитываются отдельно)
Биллинг по количеству запросов
Биллинг по времени GPU (сценарии дообучения)
Ограничения квот (запросов в минуту, токенов в день)

Аварийное восстановление и высокая доступность

Системы корпоративного уровня не должны падать — требуется проектирование высокой доступности.

Развёртывание с несколькими зонами доступности

Самое базовое требование: развёртывание между AZ (зонами доступности).

Например:

Основной кластер в AZ A
Кластер горячего резерва в AZ B
Асинхронная репликация данных
Балансировщик нагрузки автоматически переключает трафик

Цель: если одна AZ выходит из строя, сервисы работают без перебоев, а данные не теряются.

Снимок модели и откат

Новые версии модели могут иметь проблемы — нужна возможность быстрого отката.

Стратегия:

Сохранять снимок модели перед каждым релизом
Хранить N последних версий
Следите за аномальными метриками и запускайте автоматический откат
Канареечный релиз: сначала переключите 1% трафика, затем разверните полностью, если проблем нет

Деградация и ограничение частоты запросов

Что, если трафик резко возрастёт? Нельзя просто допустить падение — нужен план на случай непредвиденных обстоятельств:

Ограничение частоты запросовВозвращать 429 при превышении квоты
ДеградацияИспользовать меньшую модель или возвращать кэшированные результаты
Постановка в очередьВозвращать ID задания, проверять результаты позже

Основной принцип:Плавная деградация, а не полная недоступность.

Другие расширения