Первое правило LLM-клуба: не покупай железо, пока не прижмет
Я видел десятки компаний, которые кидались покупать H100 просто потому, что "в тренде". И видел тех, кто год мучился с облаком, хотя проще было поднять Llama локально. Давайте разберемся, когда наступает тот самый порог, когда внешние API перестают быть удобными и начинают душить бизнес.
Если вы тратите на API меньше $5000 в месяц — скорее всего, менять ничего не надо. Но есть три сценария, при которых даже $1000 становятся поводом задуматься о собственном кластере. И первый из них — комплаенс.
Сценарий опасного API: Пропустили через GPT историю болезни — нарушили HIPAA. Отправили в Claude финансовую отчетность — потеряли NDA. Даже если провайдер клянется не использовать данные для обучения, кто поверит после истории с Google NotebookLM, когда адвокат лишился Gmail из-за утечки? Для таких сценариев локальный ИИ за бетонной стеной — не паранойя, а необходимость.
Три кита вашего перехода: комплаенс, задержка, вендор-лок
1 Комплаенс и приватность данных
Если ваши юристы поседели от мысли, что данные уходят к американскому провайдеру — время покупать стойку. On-premise кластер решает проблему раз и навсегда: данные не покидают периметр. Вы можете использовать гибридную стратегию: чувствительные запросы — локально, остальное — через API. Но полный контроль дает только свой кластер.
2 Задержка (latency) убивает UX
Когда каждый запрос к GPT-4o длится 3-5 секунд, а вам нужно real-time для чата поддержки или голосового ассистента — API не годятся. On-premise с квантованной моделью (например, Llama 3.1 70B в 4 бита) может выдать ответ за 500 мс. При этом вы платите только за электричество и амортизацию железа.
3 Вендор-лок и ценообразование
Помните, как OpenAI внезапно изменила тарифы на GPT-4? Или как Claude 3.5 Opus подорожал в два раза? Вы зависите от чужого прайс-листа. On-premise дает предсказуемую стоимость на три года вперед. Но только при условии, что вы правильно оценили загрузку.
Считаем: $0.01 за запрос — это много или мало?
Возьмем типичный enterprise-сценарий: 1 млн запросов в месяц к модели среднего размера (70B параметров). По текущим ценам (июнь 2026) API стоит около $0.01 за запрос (с учетом контекста в 4K токенов). Итого $10 000 в месяц. Умножаем на 12 — $120 000 в год.
Стоимость on-premise решения: два H100 (по $30 000 каждый, с учетом доставки и монтажа — $70 000), плюс ежегодное обслуживание ($10 000 на электричество/охлаждение/админа). За три года вы потратите $70 000 + 3 × $10 000 = $100 000. Против $360 000 через API. Экономия — $260 000. Но есть нюанс: окупается покупка железа только при загрузке выше 30-40%. Если ваш рейтинг использования упадет, вы останетесь с дорогим металлоломом.
| Параметр | API (год) | On-premise (3 года) |
|---|---|---|
| 1 млн запросов/мес | $120 000 | $100 000 (включая железо) |
| 5 млн запросов/мес | $600 000 | $130 000 (железо то же + доп.операторы) |
| Задержка | 1-5 с | 0.2-1 с |
Железо живет 3 года. Окупится ли?
Здесь многие ошибаются. Они смотрят на цену H100 и думают: "Куплю, и модель будет работать вечно". Нет. Через 18 месяцев выйдет B200 или что-то еще, и ваша старенькая H100 будет выдавать 20 токенов/с против 200 у нового GPU. Модели растут, требования растут.
Но есть лайфхак: квантование и автоскейлинг. Поставили vLLM или TensorRT-LLM — и маленький кластер тянет нагрузку, которая раньше требовала вдвое больше железа. А если модель не влазит в VRAM — используйте CPU+GPU гибрид или offloading, как описано в гайде по запуску LLM на домашнем железе с 192GB RAM.
Первый шаг к своему кластеру: не покупайте сервер в понедельник
Я серьезно. Сначала неделю гоняйте нагрузочные тесты на облачных инстансах (AWS p4d или Azure ND A100 v4). Замерьте peak usage, latency SLA, поведение при параллельных запросах. Потом снимите те же метрики на локальной машине с consumer GPU, запустив Ollama или VLLM. Только после этого считайте TCO.
Не советую сразу закупать 8xA100. Начните с одного сервера на 4 GPU. Выберите стратегию: будете ли вы дообучать модель (fine-tuning) или только inference. Для inference хватит H200, для дообучения — A100 80GB или H100, если бюджет позволяет.
Стратегия: гибрид или полный отказ от облака?
Полный отказ — это риск. Если ваш кластер ляжет (а он ляжет), вы останетесь без AI. Я рекомендую гибрид: 80% трафика на on-premise, 20% — через API как fallback. Так вы и деньги экономите, и SLA держите. Железо всё ещё выгодно после ценового обвала, потому что API-провайдеры не снижают цены пропорционально — они добавляют наценку за удобство.
Кстати, для сценариев с небольшим трафиком можно использовать даже старые рабочие станции: запуск современных LLM на Dell T7910 — реальность, если применить квантование.
Как не облажаться: типовые ошибки при построении LLM-инфраструктуры
Ошибка №1: Купить железо без точного профиля нагрузки. Получится, что 4 GPU простаивают 80% времени, а пиковая нагрузка всё равно не влазит.
Ошибка №2: Не закладывать сетевое оборудование. Для распределенного вывода между GPU нужен NVLink или InfiniBand, иначе узким местом станет межсоединение.
Ошибка №3: Надеяться, что одна модель закроет все сценарии. Для кодинга — DeepSeek-Coder, для чата — Llama 3.1, для RAG — Mistral. Поднимайте несколько эндпоинтов.
Обзор локальных LLM поможет не запутаться в зоопарке моделей.
А что, если не сейчас?
Если вы еще не набрали критическую массу запросов на API — не парьтесь. Берите готовые решения вроде Ollama или LM Studio для prototyping. Переход на on-premise оправдан, когда вы понимаете: "Я буду тратить >$5000 в месяц на API в течение следующих 2 лет" ИЛИ "Мои данные слишком чувствительны для облака".
Совет на прощание: никогда не покупайте GPU в одиночку. Сделайте PoC на арендованном железе, снимите метрики, покажите CFO цифры. Если он увидит, что на втором году вы сэкономите $150 000 — он подпишет чек сам.
