Финал первого кластера. Когда понимаешь, как устроен запрос, как управлять формой, способом мышления и температурой — остаётся главное решение AI-инженера: какую модель брать под задачу.
Модели делятся на три условных tier'а: маленькие (быстрые, дешёвые, простые задачи), средние (рабочая лошадь, 80% случаев), большие (сложное, дорогое, медленное). «Лучшая» модель — не самая мощная, а та, что даёт достаточное качество при приемлемой цене и скорости для конкретной задачи. Сегодня учимся выбирать осознанно, а не «возьму GPT-4, пусть будет».
У каждого крупного провайдера есть линейка моделей: от маленькой и дешёвой до большой и дорогой. Это не «плохая → хорошая». Это разные инструменты для разных задач — как канцелярский нож, столовый и охотничий: каждый подходит под своё.
В чём сильны: простые узкие задачи. Классификация, извлечение полей, переформулирование, простое суммирование, перевод. Когда задача чётко описана и не требует сложных рассуждений.
В чём слабы: многошаговые задачи, тонкие нюансы, неоднозначные ситуации, креатив высокого уровня, сложный код.
Когда брать: массовые вызовы (тысячи в день), требования к скорости, ограниченный бюджет. Часто 80% качества топовой модели за 5-10% цены.
В чём сильны: универсалы. Хорошо справляются с большинством практических задач — диалоги, генерация текста, анализ, программирование среднего уровня, многошаговые рассуждения с CoT.
В чём слабы: очень сложные задачи (математические доказательства, дизайн систем уровня senior-инженера), задачи с очень длинным контекстом без подготовки.
Когда брать: дефолт для большинства AI-приложений. Стартуй отсюда, спускайся вниз только если упрёшься в цену, поднимайся вверх — если в качество.
В чём сильны: сложные многошаговые рассуждения, программирование высокого уровня, аналитика данных, агентские задачи с tool use, всё что требует «думать долго и качественно». Reasoning-модели (o1/o3) встроенно делают расширенное CoT.
В чём слабы: массовые задачи (дорого), задачи требующие низкой latency (медленно).
Когда брать: когда цена ошибки сильно выше цены запроса, когда задача правда сложная, когда меньшие модели не справились. Не «по умолчанию», а как осознанное решение.
Маленькая модель — это не «упрощённая большая». Это другой инструмент. Для классификации тысячи отзывов в день большая модель не «лучше» — она просто разорит тебя.
Когда выбираешь модель — оцениваешь её не по одному «качеству», а по четырём независимым осям. Часто они в противофазе друг другу.
Не «качество модели вообще», а именно на твоём классе задач. Модель, которая разносит математику, может буксовать на креативном письме. Модель, идеальная для русского языка, может хуже работать на узких технических терминах.
Как оценивать: публичные бенчмарки (MMLU, HumanEval, GPQA и т.д.) полезны как ориентир, но не заменяют тестирование на твоих реальных задачах. Сделай 10-20 типичных запросов для своей задачи и прогони на разных моделях — это даст реальное представление.
Помни: конкретная модель ≠ конкретный бенчмарк. Модель может топить в общем рейтинге, но быть лучшей на твоей нише.
Две разные метрики, часто путают:
Маленькие модели быстрее по обеим метрикам. Reasoning-модели в Tier 3 могут «думать» 30-60 секунд до первого токена — для интерактивных приложений это часто неприемлемо.
Что измерять: сделай 20 одинаковых запросов и посмотри медиану и 95-й перцентиль latency. Среднее обманывает — там бывают отдельные «зависшие» запросы.
Цена считается по двум ставкам: input (что ты отправил) и output (что модель сгенерировала). Output обычно в 2-4 раза дороже input — это важно, когда ты делаешь длинные ответы.
Разница между tier'ами — до 50-100 раз. Это не «чуть дороже», это разные порядки. Если ты делаешь 100 000 запросов в день, переход с маленькой на большую — это разница между $30 и $3000 в день.
Что не учитывают новички: неявная стоимость растёт от длины системного промпта (он отправляется в каждом запросе), истории диалога (тоже отправляется заново — см. День 1), CoT-рассуждений (это всё выходные токены).
Сколько токенов модель может «увидеть» за один раз. У современных моделей — от 8K (маленькие старые) до 200K-2M (топовые с длинным контекстом). 1K токенов — примерно 750 слов на английском, 500 на русском.
Большое окно — это не «всегда лучше». У моделей с очень длинным контекстом есть феномен «потерянного в середине»: они хуже помнят то, что лежит в середине большого промпта. Слишком длинный контекст ухудшает качество.
Практическое правило: бери модель с окном, которое заметно больше твоего обычного запроса, но не сильно. Если у тебя 10K-20K, не бери 2M — потеряешь на качестве и заплатишь за хранение.
Худшая стратегия — «возьму самую большую, пусть будет». Лучшая — пройти простой алгоритм. Можно за полчаса.
Завязка на одного провайдера — простота интеграции, единый API, единый биллинг. Минусы — зависимость от их доступности, цен, политик модерации.
Альтернатива — маршрутизатор (OpenRouter, LiteLLM): единый API, через который ты ходишь к десяткам моделей разных провайдеров. Можешь переключаться между ними без переписывания кода, делать fallback'и («если OpenAI лежит — иду на Anthropic»).
Для обучения и небольших проектов — оставайся на одном провайдере, не усложняй. Для прода — серьёзно подумай о маршрутизаторе.
Возвращаемся к развилке из Дня 0 — но теперь с пониманием tier'ов. Локально работают в основном модели Tier 1 и младший Tier 2. Топовые модели запустить локально невозможно (нужны кластеры с десятками GPU).
Поэтому если задача требует Tier 3 уровня — у тебя нет выбора кроме облака. Если задача справляется Tier 1-2 — можешь рассматривать локальный вариант. Дни 26-30 курса — про это подробно.
Бенчмарки публичны и красивы, но они тестируют общие способности. На твоей конкретной задаче лидер бенчмарка может оказаться хуже, чем «средняя» модель. Бенчмарки — это первый ориентир, не финальный ответ. Тестируй на своих кейсах.
Провайдеры обновляют модели, иногда тихо. «gpt-4» вчера и сегодня — могут вести себя по-разному. Это известная боль продакшен-AI-систем.
Что делать: использовать версионированные имена моделей (например, gpt-4o-2024-11-20 вместо просто gpt-4o), мониторить качество регрессионными тестами, иметь регулярные «evals» — наборы типичных запросов, на которых ты проверяешь, что после обновления модель ведёт себя нормально.
У каждой модели свои особенности: одна хороша на русском, плоха на коде; другая наоборот. Одна точна по фактам, другая склонна выдумывать. Это никогда не написано в маркетинговых описаниях — узнаётся только тестированием на твоём классе задач.
Полезная практика: для каждой используемой модели держать у себя короткий список «что она делает плохо», который ты пополняешь по мере столкновений. Это помогает не наступать на одни и те же грабли.
«Возьму GPT-уровня — поймёт мой кривой промпт». Иногда правда: большая модель прощает больше. Но часто хороший промпт с маленькой моделью работает лучше, чем плохой с большой. И стоит в десятки раз дешевле.
Промпт-инжиниринг и выбор модели — это взаимозаменяемые рычаги до определённой степени. Часто разумнее провести час над промптом, чем переходить на модель, которая в 50 раз дороже.
Возьми среднесложную задачу — «Объясни, как работает HTTPS, на уровне инженера среднего звена, в одном абзаце». Прогон в плейграунде через маленькую (gpt-4o-mini / claude-haiku), среднюю (gpt-4o / claude-sonnet), большую (gpt-5 / claude-opus). Сравни три параметра: полнота, ясность, скорость. На какой модели ответ уже достаточно хорош?
Задача: «Классифицируй отзыв: позитивный / негативный / нейтральный. Ответь одним словом». Прогон 20 разнотипных отзывов через маленькую и большую модель. Сравни точность и стоимость. На простых задачах разница в качестве — пренебрежимо мала. Разница в цене — в 50 раз. Это твой урок про «не нужно молоток для гвоздя».
Задача со сложной логикой: «Реши задачу про переливание из трёх ёмкостей: А=8л, Б=5л, В=3л. В А налито 8л воды. Получи ровно 4л в одной из ёмкостей. Опиши шаги.» Прогон через маленькую и большую. С большой вероятностью маленькая ошибётся, большая решит. Это твой урок про «не каждую задачу можно сэкономить».