Как сравнивать cost efficiency разных LLM провайдеров?

Краткий тезис

Сравнение cost efficiency (эффективности затрат) LLM-провайдеров — это не просто сопоставление цен за токен. Ключевые метрики: cost per 1M input + usage|output tokens (базовая цена), cost per task (с учётом реальной длины промптов), cost per good answer (с поправкой на качество) и cost + latency (Pareto frontier). Для объективного сравнения используют бенчмарки (HELM, Artificial Analysis) и собственные тесты на репрезентативной выборке задач с учётом мульти-модальности, скорости и стабильности API. В контексте Agentic RAG cost efficiency особенно важна, так как агенты делают множество вызовов LLM за один сеанс.

1. Базовые цены: cost per 1M tokens

Что это. Провайдеры публикуют стоимость за 1M входных (input) и 1M выходных (output) токенов. Обычно output дороже в 3–4 раза. Это отправная точка, но недостаточная для полной оценки.

Пример таблицы (гипотетические цены, Q2 2025):

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

2. Cost per task — учёт реальной длины промптов

Проблема базовых цен они не учитывают, что разные модели генерируют разное количество токенов на один и тот же запрос. Например, модель A может быть дешевле за токен, но писать в 2 раза длиннее, чем модель B.

Cost per task = (input токены × input price + output токены × output price) / количество задач.

Пример:

• Задача: ответить на вопрос пользователя. Средняя длина промпта: 2000 input, 500 output.
• Модель A: input $2/1M, output $8/1M → cost = 0.004 + 0.004 = $0.008.
• Модель B: input $3/1M, output $12/1M, но из-за verbosity генерирует 700 output → cost = 0.006 + 0.0084 = $0.0144.

Модель A дешевле на 45%, хотя базовая цена за output у неё ниже. Всегда считайте cost per task на вашем типовом наборе запросов.

Инструмент: провайдеры (OpenAI, Anthropic) предоставляют логи usage в API — можно посчитать средневзвешенную стоимость.

3. Cost per good answer — качество как множитель затрат

Суть дешёвый ответ, который не решает задачу, бесполезен. Нужно ввести поправку на качество.

Как измерить

1. Прогоните N запросов из вашего датасета через каждую модель.
2. Оцените ответы: вручную (краудсорсинг) или автоматически (LLM-as-judge, метрики faithfulness, relevance).
3. Определите долю «хороших» ответов (например, score ≥ 4/5).
4. Cost per good answer = cost per task / (доля хороших ответов).

Пример:

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

4. Cost + latency — Pareto frontier

Latency (задержка) часто упускают, но в real-time сценариях (чат, агенты) она критична. Дешёвая, но медленная модель может увеличить TTFB (time to first token) и ухудшить UX.

Pareto frontier отбрасываем модели, которые одновременно дороже и медленнее других. Оставшиеся образуют «фронт Парето» — каждую из них нельзя улучшить по одному параметру без ухудшения другого.

Пример двумерного графика ось X — средняя latency (мс), ось Y — cost per хороший ответ. На фронте оказываются, например, GPT-4o mini (быстрый, дёшевый, среднее качество) и Claude 3.5 Sonnet (чуть дороже, чуть медленнее, но качественнее).

Метрика для агентов latency умножается на количество вызовов (agent loops). Если агент делает 5 вызовов, а модель медленная, пользователь ждёт минуту — это неприемлемо.

5. Дополнительные факторы

5.1. Пропускная способность (throughput) и rate limits

• RPM (requests per minute), TPM (tokens per minute) — сколько запросов модель может обработать в минуту.
• Для высоконагруженных систем (например, customer support) важна не только цена, но и возможность масштабирования. Некоторые провайдеры (OpenAI) имеют tiered rate limits, другие (Anthropic) — фиксированные.

5.2. Стоимость инференса на собственных серверах (self-hosted)

• Если используете open-source модели (Llama, Mistral, Qwen) на своих GPU, cost efficiency считается через TCO (Total Cost of Ownership): аренда GPU (AWS/Google Cloud) или покупка, электроэнергия, обслуживание.
• Пример: Llama 3.1 405B на 8× H100 стоит ~$100/час. Если обрабатываете 1M запросов в день по 500 output токенов → cost per запрос ~$0.0002? Нужно считать throughput, но часто self-hosted выгоднее при >10M запросов/день.

5.3. Мультимодальность и дополнительные функции

• Если задача требует обработки изображений, аудио, видео — сравнивайте cost per image (например, OpenAI GPT-4o взимает за «image tokens»).
• Функции tool use, structured output (JSON mode) — некоторые модели поддерживают бесплатно, другие через дополнительные токены.

5.4. Стабильность API и качество сервиса

• SLA, uptime, ошибки (500, rate limit). Если модель падает в 5% запросов, приходится делать ретраи — это увеличивает effective cost.
• Скорость вывода новых моделей, смена версий. Провайдер может резко устареть модель.

6. Инструменты для сравнения

6.1. HELM (Holistic Evaluation of Language Models) от Stanford CRFM

• helm.stanford.edu
• Сравнивает модели по десяткам метрик, включая cost per query. Можно отфильтровать по сценарию (question answering, summarization и т.д.).
• Недостаток: бенчмарк статичен, не отражает вашу специфику.

6.2. Artificial Analysis

• artificialanalysis.ai
• Агрегирует цены, latency, качество (MMLU, HumanEval) от разных провайдеров в реальном времени.
• Удобная визуализация Pareto frontier.
• Подходит для быстрой ориентировочной оценки.

6.3. OpenRouter / API aggregators

• OpenRouter (openrouter.ai) даёт единый интерфейс к десяткам моделей с единой ценовой политикой — можно прозрачно сравнивать реальные cost per task.

6.4. Собственный бенчмаркинг (recommended)

Шаги:

1. Сформировать репрезентативный датасет из 100–500 запросов, типичных для вашего приложения (включая пограничные случаи).
2. Прогнать через каждую модель с единым промптом, замерить latency, input/output токены.
3. Оценить качество автоматически (LLM-as-judge, RAGAS, BLEU/ROUGE для генерации) или вручную.
4. Посчитать cost per good answer, построить Pareto frontier.
5. Принять решение на основе пороговых значений (например, cost per good answer < $0.02, latency < 2 сек).

7. Пример расчёта для Agentic RAG

Сценарий агент-помощник, который делает 3 вызова LLM за сессию: 1) разбить запрос на подзадачи, 2) извлечь ответы из документов, 3) синтезировать финальный ответ.

Параметры

• Input средний: 4000 токенов (длинный контекст RAG)
• Output средний: 600 токенов (на каждый вызов)
• Всего вызовов за сессию: 3 → 12000 input, 1800 output

Сравнение

Вывод Llama self-hosted даёт лучший cost per good сессию, но требует инженерных затрат. Если важен latency и high-quality — Claude. Если бюджет ограничен — Gemini.

Пет-проект для закрепления

Задача Разработать скрипт (Python), который сравнивает cost efficiency трёх провайдеров (OpenAI, Anthropic, Google) на наборе из 50 промптов для задачи summarization.

Инструменты Python, библиотеки openai, anthropic, google-generativeai, pandas, asyncio для параллельных запросов, tiktoken (счёт токенов).

Шаги:

1. Установить API-ключи и библиотеки.
2. Подготовить датасет: 50 текстов (новости, статьи) длиной ~2000 символов.
3. Написать функцию для запроса к каждой модели с одинаковым промптом («Summarize in 3 sentences»).
4. Измерить input_tokens, output_tokens, latency (time to first token и total time).
5. Посчитать cost per запрос (используя актуальные цены из конфига).
6. Оценить качество: использовать LLM-as-judge (GPT-4o-mini) по шкале 1–5.
7. Вычислить cost per good answer (порог >=4).
8. Построить график (matplotlib): scatter plot по осям cost per запрос (X) и качество (Y), размер точки — latency.
9. Вывести таблицу с итоговыми метриками.

Ожидаемый результат Получить понимание, какая модель оптимальна для вашего сценария. Код можно выложить на GitHub как open-source benchmark.

Связь с другими вопросами

Навигация

• Предыдущий: 782
• Следующий: 784
• Индекс: 00. Индекс разборов