Главное

Сравнивайте cloud, hybrid и on-prem на трёхлетнем TCO и делите его на успешные полезные задачи, а не на токены. Низкая цена inference невыгодна, если модель чаще ошибается или простаивает.

Самый опасный расчёт private AI помещается в одну строку: «сервер стоит X, значит через Y месяцев он дешевле API». В этой формуле сервер работает круглосуточно, никогда не ломается, не требует инженеров, идеально загружен и через три года остаётся современным.

Реальный TCO начинается там, где заканчивается цена GPU.

Что включить в расчёт

1. Инфраструктура

GPU, CPU, RAM, быстрые диски, сеть, стойка, резервное питание. Если нужен SLA, одной машины недостаточно: обслуживание и отказ не должны останавливать процесс.

2. Электричество и охлаждение

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

3. Программный стек

Драйверы, inference runtime, gateway, аутентификация, observability, vector database, storage, backup, сканирование образов. Часть компонентов бесплатна по лицензии, но не бесплатна в эксплуатации.

4. Люди

Platform/DevOps, ML/LLM engineering, security, support и владелец продукта. Даже если обязанности распределены между существующей командой, это время с альтернативной стоимостью.

5. Обновления и eval

Новая модель не должна автоматически заменять старую. Нужны загрузка и проверка артефактов, совместимость, контрольный набор, нагрузочный тест, rollout и rollback.

6. Резерв и простой

Если сервер загружен на 20%, вы платите за оставшиеся 80%. Если загрузка выросла в три раза на неделю, on-prem не становится эластичным сам. Нужно заранее покупать запас либо иметь overflow в cloud.

7. Риск и стоимость ошибки

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

Формула, которую можно положить в таблицу

Для горизонта в три года:

TCO = CAPEX + энергия + размещение + лицензии + эксплуатационная команда + обновления + резерв + стоимость простоев + стоимость ручной проверки + выход/утилизация

Затем делите не на число токенов, а на объём успешных задач:

стоимость полезной задачи = TCO / количество задач, прошедших quality gate

Если одна архитектура отвечает дешевле, но чаще отправляет результат на ручную переработку, цена запроса вводит в заблуждение.

Три профиля нагрузки

Редкие и непредсказуемые запросы. Cloud часто выгоднее: вы не держите дорогой резерв ради нескольких пиков.

Стабильная высокая загрузка. On-prem может выиграть, если оборудование действительно используется, модель достаточно качественная, а операционная команда уже существует.

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

Не переносите вывод одного профиля на другой.

Проведите замер, а не спор

До закупки выполните короткий sizing-пилот:

  1. Соберите распределение длины входа и выхода.
  2. Зафиксируйте одновременные запросы и допустимую очередь.
  3. Измерьте p50/p95 latency, throughput и ошибки на нужной модели.
  4. Прогоните eval качества.
  5. Смоделируйте обычный день, пик и отказ узла.
  6. Посчитайте utilization и headroom.

NVIDIA публикует отдельные sizing-рекомендации для enterprise RAG именно потому, что итог зависит от модели, retrieval, параллелизма и профиля запросов. Универсальной цены «одного on-prem AI» нет.

Скрытые статьи расходов

  • Переезд на новую GPU-архитектуру или несовместимый runtime.
  • Хранение нескольких моделей и версий индексов для rollback.
  • Закрытый registry и проверка supply chain.
  • Нагрузочные тесты после каждого существенного изменения.
  • Удалённый доступ поддержки без превращения его в дыру.
  • Восстановление после сбоя диска или ошибочной переиндексации.
  • Compliance и внутренние согласования.
  • Secure disposal накопителей и моделей в конце цикла.

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

Как сравнивать предложения подрядчиков

Попросите один и тот же трёхлетний шаблон:

  • ожидаемая нагрузка и рост;
  • модель и измеренное качество;
  • необходимое железо и резерв;
  • SLA и окно обновлений;
  • роли и часы сопровождения;
  • стоимость лицензий и внешних API;
  • RTO/RPO;
  • план расширения и exit plan.

Предложение «купите две карты и всё заработает» не дешевле. Оно просто переносит неизвестные расходы на период после договора.

Когда TCO всё равно не главный критерий

Если политика данных исключает внешнюю обработку, вы выбираете среди допустимых private-архитектур, а не сравниваете их с запрещённым cloud. Если бизнес не может содержать нужную команду, технически дешёвый on-prem может быть операционно невозможным.

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

Сравнение

Статьи TCO

БлокЧто считать
ИнфраструктураGPU, CPU, RAM, storage, сеть, резерв
ЭксплуатацияDevOps/ML/Security, обновления и мониторинг
НагрузкаUtilization, пики, очередь, overflow
РискПростои, ручная переработка, отказ и exit

Что проверить

Как сделать sizing-пилот

  1. Снять распределение длины входа и выхода.
  2. Зафиксировать одновременность, очередь и SLA.
  3. Измерить p50/p95 latency, throughput и ошибки.
  4. Прогнать eval качества и профиль отказа.
  5. Посчитать обычный день, пик и отказ узла.

Как мы подходим к задаче

Мы не выдаём цену одного GPU за экономику private AI. Сначала считаем рабочую нагрузку, качество, резерв, обслуживание и стоимость полезной задачи; только потом сравниваем допустимые контуры.

Источники и ссылки