5.2 Выводы: как выбирать модель

Во-первых, универсальных моделей не существует

даже GPT-4o, который закрывает большинство задач, может проигрывать специализированным моделям в узких областях.

Например, в математических рассуждениях DeepSeek часто оказывается точнее, а в код-генерации Claude нередко обходит OpenAI. Поэтому ваша первая задача - чётко определить домен: если это работа с русскими текстами, GigaChat Ultra даст лучшее качество, чем любая англоцентричная модель, просто потому что обучался на других данных.

Во-вторых, качество модели не линейно зависит от размера.

Бывает, что 7-миллиардная модель, дообученная на узкой задаче, бьёт 70-миллиардную «универсалку».

Например, специализированный медицинский ассистент на базе LLaMA 7B может отвечать точнее, чем GPT-4 в той же области, просто потому что его обучали на правильных данных. Не гонитесь за цифрами параметров - гонитесь за метриками на ваших данных.

В-третьих, open-source не значит бесплатно.

Когда вы берёте LLaMA или Mistral, вы экономите на токенах, но платите инженерным временем. Развёртывание, оптимизация, дообучение, поддержка - всё это требует людей, а люди стоят денег. На малых объёмах API почти всегда выгоднее и быстрее. Переход на свою инфраструктуру имеет смысл только тогда, когда вы точно знаете, что будете генерировать миллионы токенов в день.

Ещё два критерия, которые часто упускают из виду, - compliance и latency. Если ваш продукт работает в Европе, модель должна соответствовать GDPR. Если данные нельзя передавать за пределы страны - API американских провайдеров отпадают автоматически. А latency (скорость первого токена) критична для чат-ботов и голосовых ассистентов: если модель думает дольше секунды, пользователь уходит. Для таких сценариев локальные open-source модели часто выигрывают даже у самых быстрых API.

И наконец, никогда не верьте одному бенчмарку.

Модели «заучивают» тесты, и то, что она победила в MMLU, не гарантирует, что она хорошо напишет письмо клиенту. Создайте свой тестовый набор из 50–100 реальных примеров - тех, с которыми модель столкнётся в продакшене. Прогоните всех кандидатов, сравните результаты руками. Да, это займёт день-два, но эти инвестиции окупятся сторицей, когда вы не попадёте в ловушку маркетинговых цифр.

5.3 TCO: сколько на самом деле стоит владение моделью?

Когда вы выбрали модель по таблице и матрице, начинается самое интересное - разговор с финансовым директором. «Почему GPT-4o такая дорогая?» - спросит он. «А почему open-source модель якобы бесплатна, но требует трёх инженеров в штат?» - добавит он. Здесь в игру вступает TCO - совокупная стоимость владения (Total Cost of Ownership).

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

Сценарий А

Использование API (GPT-4o, Claude, GigaChat)

Это самый простой способ начать. Вы платите только за то, что используете, и не думаете об инфраструктуре.

Статьи расходов

Стоимость токенов

входные + выходные. Например, GPT-4o стоит $5 за 1M входных и $15 за 1M выходных токенов.

Кэширование

если вы повторяете одни и те же запросы, можно кэшировать ответы и экономить.

Ретриалы

при сбоях API запросы могут дублироваться, увеличивая счёт (автоматические повторные вызовы при ошибках)

Плюсы

· Нулевые капитальные затраты (CAPEX)

· Не нужно нанимать ML-инженеров

· Масштабируется автоматически

Минусы

· Высокая стоимость на больших объёмах

· Зависимость от вендора

· Данные уходят вовне (не всегда допустимо)

Формула для оценки

Стоимость_месяц = (входные_токены × цена_входа + выходные_токены × цена_выхода) × количество_запросов

Пример

1 млн запросов в месяц, средний промт 1000 токенов, ответ 500 токенов = ~$7500–10 000 в месяц.

Сценарий Б

Аренда GPU под open-source модель (LLaMA, Mistral, Qwen)

Вы берёте готовую open-source модель и разворачиваете её на арендованных серверах (AWS, GCP, Azure, Selectel).

Статьи расходов

· Аренда GPU: например, A100 (80GB) - $1–3 в час, H100 - $3–8 в час.

· Хранение: веса модели (десятки GB), плюс данные.

· Сетевая пропускная способность: если модель публичная.

· Инженерное время: развёртывание, оптимизация, поддержка.

Плюсы

· Данные не уходят вовне

· Полный контроль над моделью

· На больших объёмах дешевле API

Минусы

· Нужны инженеры в штате

· CAPEX (или долгосрочные контракты)

· Сложность масштабирования

Формула для оценки

Стоимость_месяц = ( GPU _цена × 24 × 30) + (инженеры_месяц) + (сеть_месяц)

Пример

4 × A100 (16 часов в сутки) = ~$5800 в месяц + инженер $5000–8000 = $11–14 тыс. в месяц. На 10 млн запросов это уже дешевле API.

Сценарий В

Своя инфраструктура (on-prem)

Вы покупаете серверы, ставите их в дата-центр и обслуживаете сами.

Статьи расходов

· Оборудование: серверы с GPU (например, 8 × H100 - $300–400 тыс.)

· Амортизация: 3–5 лет

· Электричество, охлаждение, стойка-место

· Инженеры: админы, ML-инженеры, DevOps

· Резервирование: железо ломается

Плюсы

· Полный контроль

· Самое дешёвое на огромных объёмах

· Данные не уходят никуда

Минусы

· Огромные CAPEX

· Долгий запуск (закупка, монтаж)

· Риск устаревания оборудования

Формула для оценки (3 года)

CAPEX = оборудование

OPEX _месяц = ( CAPEX / 36) + электричество + инженеры + обслуживание

Пример

8 × H100 ($350K) + инженеры = ~$18–20 тыс. в месяц на 3 года. На 50 млн+ запросов это единственно разумный вариант.

Цифры в таблицах могут казаться абстрактными. Давайте посмотрим на график пересечения затрат. Он показывает, при каком объеме запросов аренда GPU становится выгоднее API, а покупка своего железа (On-Prem) окупает капитальные затраты.

Рисунок. График TCO: API vs GPU vs On-Prem

Точки пересечения - это ваши точки безубыточности. Если вы генерируете меньше 1 млн запросов в месяц, API почти всегда выгоднее из-за отсутствия CAPEX. Но как только вы пересекаете красную линию, аренда GPU начинает экономить бюджет. On-Prem имеет смысл только на огромных масштабах.

Сравнительная таблица TCO (условные цифры)

Важное дополнение

Приведённые в таблице цифры для on-prem предполагают, что вы уже достигли масштаба, при котором покупка оборудования имеет смысл. Для малых объёмов (менее 100 000 запросов в месяц) on-prem никогда не окупится. CAPEX на серверы с GPU (сотни тысяч долларов) придётся амортизировать за 3–5 лет, и при низкой нагрузке оборудование будет простаивать 95% времени. API или аренда GPU в таком масштабе всегда выгоднее - вы платите только за то, что используете, и не думаете об амортизации. On-prem становится разумным выбором только тогда, когда вы твёрдо уверены, что будете генерировать миллионы запросов в месяц и ваши инженеры готовы заниматься железом.

Неочевидные затраты, о которых забывают

1. Дообучение (fine - tuning)

Даже если вы берёте open-source модель, вам почти наверняка придётся её дообучать под свою задачу.

Это стоит денег:

· Аренда GPU на время обучения

· Сбор и разметка данных

· Эксперименты (каждая неудачная попытка - деньги)

2. Версионирование моделей

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

3. Compliance и безопасность

· Проверка модели на уязвимости

· Аудит ответов

· Защита от инъекций

4. Мониторинг и observability

· Сбор метрик (латентность, качество ответов)

· Детекция аномалий

· Логирование для налоговой

Инженерный чек-лист: как считать TCO под свой сценарий

· Оцените среднюю длину промта и ответа в токенах

· Оцените количество запросов в день/месяц

· Выберите 2–3 модели-кандидата

· Посчитайте стоимость по API (если есть)

· Оцените стоимость аренды GPU (инстансы с нужной памятью)

· Прикиньте, сколько инженеров потребуется (и есть ли они)

· Учтите стоимость данных (сеть, хранение)

· Добавьте 30% на непредвиденные расходы

· Прогоните тест на 1000 реальных запросов, замерьте latency и качество

Только после этого принимайте решение

Вывод

API - идеально для старта и экспериментов. Аренда GPU - золотая середина для средних объёмов. On-prem - удел гигантов или тех, кому нельзя отдавать данные наружу. Ваш выбор зависит не только от цены за токен, но и от скрытых затрат, которые всплывают через полгода.