Сервинг-обвязка важнее модели: как строить ИИ-инфраструктуру, которая не сломается в проде

Пока рынок гонялся за большими контекстами и рекордными бенчмарками, реальная проблема enterprise-ИИ сменилась. Вопрос «что умеет модель?» уступил место «как доставить этот интеллект стабильно, экономно и под нагрузкой?». Ответ, по мнению авторов статьи, лежит не в модели, а в serving harness — инженерной обвязке: архитектуре, управлении памятью, планировании и оптимизации. Технические руководители должны пересмотреть, куда вкладывать ресурсы.

Нет универсально лучшей модели — есть правильное решение для бизнес-задачи. Чат-боту нужна скорость, пакетному пайплайну — дешёвый ночной прогон. Архитектуру диктует workload, а не наоборот. В proof-of-concept точность затмевает всё, но в проду вылезают латентность, параллелизм, давление на GPU-память и неожиданные скачки трафика. Модель, чуть лучшая по качеству, но удваивающая стоимость инференса или не влезающая в SLA, — плохой выбор. Цель: нужная производительность за адекватные деньги.

Когда ИИ попадает в прод, решения перестают быть изолированными. Архитектура подачи влияет на память, память — на параллелизм, параллелизм — на батчинг и шедулинг, а те — на утилизацию GPU и задержки. Только после этого техники вроде квантизации или спекулятивного декодирования дают эффект. Ключевой урок: измеряйте до оптимизации, найдите главное узкое место, устраните его, измерьте снова. Не собирайте техники, как покемоны — применяйте только ту, что убирает самый жёсткий ограничитель.