Почему цена видеокарты ничего не решает

Расчёт локального ИИ часто начинается с неправильного вопроса: «Сколько стоит сервер с GPU?» Для бизнеса важнее другое: сколько подтверждённых операций система выполнит за месяц при требуемом времени ответа. Один и тот же ускоритель может быть выгодным при плотной очереди документов и дорогим при десяти коротких запросах в день.

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

Документация vLLM перечисляет механизмы, которые повышают загрузку инференса: continuous batching, PagedAttention, chunked prefill, prefix caching и квантизацию. Их наличие не гарантирует экономию. Они помогают только тогда, когда профиль запросов позволяет объединять работу, а бизнес согласен на соответствующий компромисс между задержкой и пропускной способностью.

Три метрики вместо одной скорости

Первый показатель — **time to first token**, время до начала ответа. Он важен для сотрудника, который ждёт подсказку в интерфейсе. Второй — **время на выходной токен**, определяющее плавность генерации. Третий — **совокупная пропускная способность**, то есть сколько запросов или токенов система обрабатывает при параллельной нагрузке.

MLPerf Inference разделяет сценарии Server и Offline именно потому, что система для интерактивного потока и система для пакетной обработки решают разные задачи. В Server запросы приходят во времени и должны укладываться в ограничения задержки. В Offline важна максимальная обработка накопленного пакета. Сравнивать результаты между этими режимами без контекста нельзя.

Для бизнеса это означает:

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

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

Что делает загрузку дорогой

В инференсе есть две разные фазы. Prefill обрабатывает входной контекст и обычно требует много вычислений. Decode генерирует ответ по одному токену и чаще ограничен пропускной способностью памяти. Длинные документы и короткие ответы создают один профиль; короткие вопросы и длинные отчёты — другой.

На стоимость влияют:

  • длина системного промпта и повторяемость его префикса;
  • размер извлечённых RAG-фрагментов;
  • средняя и пиковая длина ответа;
  • число одновременных запросов;
  • размер KV-cache для активных последовательностей;
  • квантизация весов и поддержка конкретного формата движком;
  • доля времени, когда ускоритель ждёт работу.

Continuous batching добавляет новые запросы в выполняющийся пакет и увеличивает совокупную загрузку. Chunked prefill разбивает длинные входы, чтобы лучше сочетать их с генерацией других запросов. Prefix caching экономит повторную обработку общего начала. Но слишком агрессивный пакет может ухудшить интерактивность, а большой кэш — вытеснить одновременные последовательности из памяти.

Поэтому «токенов в секунду» без размера входа, выхода, параллельности и percentile задержки — рекламная цифра, а не основание для бюджета.

Модельный расчёт для малого бизнеса

Предположим, компания рассматривает локальный сервер стоимостью 900 000 рублей. Срок расчёта — три года, остаточную стоимость не учитываем. Амортизационный компонент равен 25 000 рублей в месяц.

Добавим модельные расходы:

  • электричество и охлаждение — 6 000 рублей;
  • мониторинг, резервные копии и расходные сервисы — 7 000;
  • восемь часов инженера по 2 500 рублей — 20 000;
  • резерв на ремонты и простой — 7 000.

Итого — 65 000 рублей в месяц. Это пример, не рыночная котировка: каждая компания должна подставить свою цену оборудования, электричества и труда.

Если сервер обрабатывает 2 000 подтверждённых операций в месяц, инфраструктурная цена одной равна 32,5 рубля. При 20 000 операций — 3,25 рубля. При 200 операциях — 325 рублей. Само железо не изменилось; экономика изменилась в сто раз из-за загрузки.

Теперь добавим человеческий контроль. Пусть проверка каждой операции занимает две минуты при полной стоимости часа 1 500 рублей: ещё 50 рублей на результат. Тогда полная переменная стоимость при 2 000 операциях уже не 32,5, а 82,5 рубля. Если автоматизация экономит сотруднику десять минут стоимостью 250 рублей, чистый ресурсный эффект составляет около 167,5 рубля на операцию до учёта интеграции.

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

Где проходит граница между API и локальным контуром

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

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

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

Нельзя сравнивать API самой сильной модели с локальной маленькой моделью только по цене: качество и доля ручных исправлений будут разными. Правильный эксперимент даёт обеим системам один набор задач и измеряет принятие результата человеком.

Какие данные собрать до закупки

До запроса коммерческого предложения достаточно двух недель журналирования. Для каждого реального задания сохраняют обезличенные показатели:

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

Затем запросы группируют минимум в три класса: интерактивные, пакетные и длинноконтекстные. Среднее значение недостаточно — инфраструктуру определяют пики и 95-й percentile, а экономику часто портит редкий длинный хвост.

Отдельно фиксируют простой. Ускоритель, загруженный на 15% рабочего времени, может быть оправдан требованиями конфиденциальности или доступности, но это должно быть осознанное решение. Если таких требований нет, очередь, расписание пакетных задач или совместное использование несколькими процессами обычно выгоднее нового оборудования.

Пилот с четырьмя воротами

**Ворота 1 — качество.** На 100–300 реальных заданиях модель должна пройти порог по фактам, структуре и опасным ошибкам. Непринятый результат не считается производительностью.

**Ворота 2 — нагрузка.** Тест воспроизводит реальные длины, параллельность и пики. Замеряются p50 и p95 задержки, завершённые запросы в час и ошибки памяти.

**Ворота 3 — процесс.** Измеряется время проверки и доля исправлений. Если автоматический черновик не экономит время, более быстрый сервер не спасёт проект.

**Ворота 4 — экономика.** Сравниваются локальный TCO, API и гибрид на одну подтверждённую операцию. Добавляются сценарии 25%, 50% и 80% загрузки и резерв на рост.

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

Управленческий вывод

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

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