Себестоимость AI: считать нужно принятые задачи, а не только токены

Дешёвый токен ещё не означает дешёвую автоматизацию. В счёт входят повторные попытки, инструменты, простаивающая мощность и проверка человеком. Разумная единица сравнения: задача, завершённая вовремя и принятая по заранее установленным правилам. Октябрьские материалы четырёх компаний показывают, почему одинаковая ценовая таблица не даёт одинаковой себестоимости.

Cloudflare описала оптимизацию своего процесса AI-ревью кода, сообщив о снижении своего счёта на 68%. Это результат конкретной инфраструктуры компании. Spotify разобрала работу с TensorRT-LLM для генеративных рекомендаций, где характер декодирования влияет на эффективность. Liquid AI 13 октября представила LFM2.5-24B-A2B для локальных агентов. GitLab 13 октября описала учёт и ограничение AI-кредитов. Проценты этих компаний нельзя складывать или переносить на один чужой проект.

Сначала определить, что считается результатом

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

Для пилота полезно делить все расходы процесса на число принятых результатов. В числитель входят inference, внешние инструменты, вычислительная инфраструктура и исправление ошибок. В знаменатель не попадают формально завершённые запуски с неверным результатом. Неудачи при этом продолжают увеличивать затраты.

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

У оптимизации есть порядок

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

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

Локальный MoE-запуск требует отдельной осторожности: число активных параметров не равно размеру всех весов, которые нужно разместить. К ним добавляются память контекста, конкурирующие запросы и эксплуатационный запас. Устройство, успешно выполнившее демонстрацию, не обязательно выдержит рабочую очередь.

Условный расчёт процесса, а не модели

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

Команда сравнивает маршрутизацию с единой моделью на том же наборе документов. Она учитывает, сколько случаев ошибочно признано простыми, как часто происходит повторная обработка и сколько времени уходит на проверку. Экономия на первой ветке может исчезнуть, если ошибки обнаруживаются только на последней.

После пилота ограничение бюджета остаётся нужным, но оно должно приводить к понятному поведению. Задачу можно отложить или передать оператору с объяснением. Молчаливое переключение на другой уровень качества нарушит условия сравнения и ожидания пользователя.

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

Статья об AI в обработке данных объясняет, где оставить проверку результата. Кейс финансовых данных и AI-чат-бота даёт прикладной контекст. Для обсуждения экономической модели достаточно начать с типов задач, допустимой задержки и правил приёмки.