Self-hosted LLM или API: как сравнить полную стоимость команды

1. Сначала зафиксируйте workload и границу качества

Выберите 3–5 задач, которые действительно повторяются:

• классификация документов по фиксированной schema;
• поиск ответа по внутренней базе знаний;
• review кода с запуском теста;
• генерация структурированного отчёта;
• пакетная обработка запросов в фоновом job.

Для каждой задачи запишите размер входа, ожидаемый выход, число запусков в обычный день, пиковое число параллельных запросов и критерий приёмки. Например: JSON проходит validator; ответ содержит ссылки на исходные документы; исправление проходит конкретный тест. Без этой границы дешёвый, но неприемлемый результат будет выглядеть победителем.

Для API-ветки BetterToken можно использовать как измеримый пример pay-as-you-go доступа: Dashboard показывает время, модель, HTTP-статус, input, output, cache Token и списание. Сверьте актуальные модели и ставки, затем откройте Workspace и перенесите фактические метрики пилота в таблицу. BetterToken не является self-hosted платформой и не обслуживает вашу локальную инфраструктуру; это только одна из API-веток сравнения.

2. TCO self-hosted: считайте больше, чем GPU

Используйте период не короче полного рабочего цикла команды: хотя бы несколько обычных дней и один ожидаемый пик. Формула для периода:

self_hosted_tco =
  hardware_amortization
  + hosting_and_electricity
  + storage_and_network
  + engineer_time
  + monitoring_and_security
  + backup_or_overflow
  + incident_cost

Hardware и мощность

Записывайте цену фактически выбранной конфигурации, срок амортизации и доступную память. Не используйте сумму из поста как benchmark: она может не включать серверный корпус, сеть, резервирование, доставку и местные тарифы. Проверяйте, помещается ли нужная модель и контекст в память без изменения качества или задачи.

Инженерное время

Ведите журнал часов по категориям: установка runtime, загрузка и проверка модели, настройка serving, обновления, профилирование, очереди, наблюдаемость, контроль доступа и разбор инцидентов. Умножайте часы на внутреннюю стоимость команды только в своей модели расчёта; статья не подставляет чужую ставку.

Безопасность и данные

Self-hosted может дать команде больше контроля над размещением данных, но сам факт локального запуска не создаёт безопасность автоматически. Учитывайте обновления ОС и runtime, секреты, сетевую сегментацию, audit logs, резервные копии и доступ администраторов. Отдельно фиксируйте требования, которые запрещают отправку определённых данных во внешний API: это ограничение может быть важнее цены.

Простой и резерв

Записывайте минуты недоступности и число необработанных задач. Для критического workflow задайте fallback: второй локальный узел, очередь до восстановления или разрешённый API для нечувствительных запросов. Стоимость резерва входит в TCO, даже если он используется редко.

3. TCO API: Token — только первая строка

Для API сначала нормализуйте usage по схеме конкретного provider. Не прибавляйте cache Token второй раз, если они уже входят в input.

api_tco =
  uncached_input_cost
  + cache_read_cost
  + cache_write_cost
  + output_cost
  + retry_cost
  + integration_and_operations
  + incident_or_fallback_cost

23 августа 2026 года публичные данные BetterToken для claude-sonnet-5 в группе Claude показывали $1.36 за миллион входных Token и $6.80 за миллион выходных Token. Для запуска без кэша со 100 000 входных и 20 000 выходных Token это $0.272. Пример привязан к модели, группе и дате: перед пилотом повторно проверяйте текущую страницу, а cache read/write считайте по фактической usage schema и текущим ставкам.

В API-ветке также измеряйте время интеграции, обработку 401/429/5xx, retry с ограничением, очередь, наблюдаемость и проверку результата. Не закладывайте «нулевую эксплуатацию»: клиент и бизнес-логика остаются у команды.

4. Постройте модель обычной и пиковой нагрузки

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

1. Обычный: типичный поток рабочей недели.
2. Пиковый: заранее заданная параллельность и пакет задач без искусственного отключения проверок качества.

Записывайте p50 и p95 времени выполнения, долю принятых результатов, число ошибок, повторы, длину очереди и время человека. Эти показатели не становятся обещанием будущей стабильности; они описывают только ваш пилот и его конфигурацию.

5. Проведите обратимый пилот

Не переносите весь продукт первым шагом. Выберите один сценарий, сохраните общий интерфейс приложения и поместите provider за адаптером. Тогда переключение ветки не потребует переписывать бизнес-логику.

Порядок пилота:

1. Зафиксировать входы, критерии качества и запрещённые данные.
2. Запустить обе ветки на одинаковой выборке.
3. Измерить обычную и пиковую нагрузку.
4. Посчитать Token, инфраструктуру и часы команды за один период.
5. Проверить отказ: недоступный локальный узел и недоступный внешний API.
6. Повторить ключевые задачи после изменения конфигурации.

Не отправляйте в отчёт API Key, .env, приватные prompts или полный чувствительный ответ. Для сравнения достаточно безопасного ID сценария, модели, времени, Token, статуса и результата проверки.

6. Критерий выбора и выхода

Self-hosted чаще имеет смысл, когда контроль размещения данных обязателен, workload достаточно устойчив, а команда готова владеть эксплуатацией. API чаще подходит, когда нагрузка меняется, нужен быстрый старт или инфраструктурная команда не должна обслуживать модельный runtime. Смешанная схема подходит, когда чувствительные задачи остаются локально, а разрешённый пик или отдельные сценарии уходят в API.

До начала запишите stop-условия:

• остановить self-hosted пилот, если он не проходит качество, пик или требования обновления в доступные инженерные часы;
• остановить API пилот, если обязательные данные нельзя передавать внешнему Endpoint или бюджет на принятую задачу неуправляем;
• пересчитать обе ветки после смены модели, ставки, аппаратной конфигурации или workload;
• не выбирать меньшую сумму, если она достигнута ухудшением результата или отсутствием резерва.

Итоговый артефакт — не спор «свой сервер против облака», а таблица TCO с датой, конфигурацией, качеством, пиком и ответственным владельцем. Она позволяет пересмотреть решение без миграции вслепую.

Источники

• BetterToken: актуальные модели и цены API
• BetterToken Docs
• BetterToken Public Pricing API, claude-sonnet-5 повторно проверен 23 августа 2026 года
• BetterToken Product Fact Sheet, версия от 31 июля 2026 года