Холодный старт
Если модель тяжело стартует после рестарта, то её сложнее безопасно эксплуатировать на небольших хостах и резервных узлах.
Компактные модели
Как выбирать модели, когда бюджет по памяти и CPU ограничен.
Маленькая модель не всегда хуже. Во многих внутренних системах она оказывается устойчивее, предсказуемее и дешевле в эксплуатации, особенно если задача узкая и входные данные хорошо структурированы.
Когда компактный подход оправдан
- Нужны быстрые ответы без долгого прогрева
- Сервис работает на CPU или на небольшой виртуальной машине
- Запросы однотипны и хорошо описываются шаблоном
- Система должна переживать умеренную конкуренцию без скачков памяти
Что обычно помогает
- Квантование до 4-bit или 8-bit при приемлемом качестве
- Короткий контекст и строгий шаблон промпта
- Разделение задач: классификация отдельно, генерация отдельно
- Источники через RAG только там, где реально нужна привязка к данным
Ориентиры
Смотреть не только на качество ответа.
Поведение под нагрузкой
Хороший рабочий вариант держит латентность предсказуемой и не превращает умеренный рост запросов в каскад таймаутов.
Наблюдаемость
Чем проще пайплайн, тем легче понять, из-за чего портится ответ: из-за модели, retrieval, шаблона или структуры входных данных.
Практический вывод
Лучше несколько небольших компонентов, чем один тяжёлый центр тяжести.
В прикладной эксплуатации часто выигрывает не самая умная модель, а та, которая спокойно работает неделями, предсказуемо ест память, быстро перезапускается и не требует отдельного GPU-узла для каждого сценария.