Подбор оборудования для локальных моделей перед переходом на on-prem

Почему локальные пилоты рано проваливаются

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

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

Давление со стороны приватности часто усугубляет ситуацию. Команда слышит «нам нужно это on-prem» и сразу идет покупать оборудование. Это кажется осторожным шагом, но при этом пропускается скучная математика, от которой зависит, будет ли пилот удобным в работе. Подбор оборудования для локальных моделей начинается именно с этого, а не с спора о бенчмарках моделей.

Чаще всего первым ограничением становится память. Команды сравнивают модели по качеству и игнорируют, сколько VRAM или системной RAM им нужно на практике. Потом модель едва помещается, загружается медленно или требует сильной квантизации, из-за которой меняются скорость и качество ответа. К тому моменту, когда люди это замечают, доверие уже начинает падать.

Одновременные запросы вредят даже больше, чем память. Один пользователь может спокойно ждать 10 секунд во время теста. Но если на ту же машину одновременно обращаются пять человек, это превращается в очередь. Ответы замедляются, потом люди обновляют страницу, потом очередь становится еще хуже. Через неделю команда говорит, что пилот «не сработал», хотя на самом деле проблема была в мощности.

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

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

Какие цифры нужно собрать сначала

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

Начните с той модели, которую вы действительно хотите запускать, а не с той, что хорошо выглядит на графике бенчмарка. Модель на 7B, модель на 34B и модель на 70B требуют очень разного оборудования. Запишите точное название модели, квантизацию, которую вы планируете использовать, и то, нужна ли вам одна модель или небольшой набор для разных задач.

Затем измерьте размер сообщений. Вам нужны средняя длина запроса и средняя длина ответа для реальной работы, а не выдуманного демо. Бот поддержки с запросами на 300 токенов и ответами на 150 токенов — это совсем не то же самое, что помощник по документам, который читает 8 000 токенов и выдает 1 000 токенов в ответ. Эти длины влияют на память, скорость и на то, сколько пользователей вы сможете обслужить одновременно.

Число пользователей тоже часто сбивает команды с толку. Не считайте всех, кто вообще может пользоваться инструментом за день. Считайте самый загруженный час. Если за день в систему заходят 60 человек, но одновременно задают вопросы только 8, ориентируйтесь именно на это окно. Если 3 из этих пользователей обычно отправляют следующий запрос еще до того, как закончится первый ответ, тоже отметьте это. Это и есть планирование одновременных запросов, и оно меняет требования к оборудованию сильнее, чем многие ожидают.

Дальше отметьте, каким задачам нужны быстрые ответы. Какие-то задачи могут подождать 20 секунд. Другие начинают ощущаться сломанными, если занимают больше 2–3 секунд. Помощник для программиста, инструмент живого чата и ночной классификатор документов не должны иметь один и тот же целевой показатель скорости. Для каждой задачи поставьте рядом допустимое время ответа.

И наконец, перед покупкой серверов установите два денежные лимита: жесткий потолок на оборудование и жесткий потолок на резервное облако. Резервное облако — это работа, которую вы отправляете в облако, когда локальная система перегружена, недоступна или слишком медленная. Простая запись вроде «12 000 долларов заранее, максимум 1 500 долларов в месяц на резервное облако» задает пилоту реальную границу и рано останавливает самообман.

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

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

Первый кусок фиксированный: веса модели. Когда вы выбираете размер модели и уровень квантизации, файл весов занимает примерно одинаковый объем VRAM каждый раз при загрузке. Модель на 7B может поместиться на сравнительно скромной карте, а более крупная модель может съесть почти всю 24-гигабайтную GPU еще до того, как хоть один пользователь отправит запрос.

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

Что занимает память кроме самой модели

Обычно бюджет памяти состоит из четырех частей:

• веса модели
• кэш на каждый запрос
• накладные расходы сервера инференса
• операционная система и инструменты мониторинга

Команды часто считают только первый пункт и недооценивают все остальное. На бумаге это выглядит мелочью, а на практике — болью.

Представим, что у вас GPU на 24 ГБ. Веса модели занимают 14 ГБ. Еще 1,5–2 ГБ нужны для среды выполнения, драйверов и стека обслуживания. Если каждый активный запрос использует примерно 3,5 ГБ кэша на вашей целевой длине контекста, может показаться, что вы сможете обслуживать двух человек одновременно. На деле же один дополнительный буфер, чуть более длинный запрос или фрагментация памяти могут убрать этот второй слот.

Поэтому подбор оборудования для локальных моделей требует большего, чем карточка модели и спецификация GPU. Вам нужен безопасный запас. Если по расчетам требуется 23,5 ГБ на карте с 24 ГБ, памяти вам не хватает.

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

Хорошо работает простое правило: сначала закладывайте фиксированную загрузку модели, потом добавляйте реалистичное потребление кэша для одновременных запросов, а затем оставляйте запас на всплески. Без этого буфера небольшая ошибка в накладных расходах превращается в неудачные запросы, принудительные ограничения контекста или в минус одного пользователя от обещанного количества.

Почему одновременность меняет ответ

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

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

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

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

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

Средние значения за день скрывают эту проблему. Если системой пользуются 20 сотрудников в течение дня, это звучит легко. Но если шесть из них заходят с 9:00 до 9:20, именно этот короткий интервал решает, будет ли пилот удобным.

Проще всего думать так:

• Считайте пользователей в час пик, а не общее число пользователей.
• Разделяйте чат-сессии и фоновые задачи.
• Предполагайте, что у части людей будут более длинные и тяжелые запросы.
• Оставляйте запас на всплески и повторы.

Oleg часто видит это в небольших командах, которые переводят ИИ-нагрузки on-prem. Первое демо работает на одной машине, потом начинается реальное использование, и появляется очередь. Если людям приходится ждать ответа 20 или 30 секунд, они перестают доверять инструменту. Обычно именно в этот момент становится нужно либо резервное облако, либо больше GPU, либо другой план запуска.

Сколько на самом деле стоит резерв

Локальная система редко справляется с каждым запросом. Какие-то запросы длятся дольше ожидаемого, какие-то пользователи вставляют огромные документы, а трафик может внезапно вырасти на час. Когда это происходит, облачная модель часто становится предохранительным клапаном, даже если команда не планировала этого заранее.

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

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

Облачный резерв также защищает пилот от заметных задержек. Пользователи обычно прощают редкое переключение на другую модель. Но они не прощают систему, которая зависает на 45 секунд или уходит в таймаут, когда инструментом одновременно пользуются несколько человек. Иногда небольшой ежемесячный счет за облако — это просто страховка от плохого первого впечатления.

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

Приватность не всегда мешает резерву. Многие команды по-прежнему могут отправлять в облако низкорисковые задачи, если сначала уберут имена, email, номера счетов или внутренние идентификаторы. Так можно обрабатывать сводки, черновики и классификацию, а чувствительные записи оставлять локально.

Перед тем как утверждать покупку оборудования, запишите пять цифр:

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

Простой пример хорошо показывает компромисс. Если один дополнительный сервер стоит 1 500 долларов в месяц, а резервное облако для редких всплесков обходится в 220 долларов, дешевый ответ очевиден. Если перегрузка растет каждую неделю и счет за облако достигает 1 200 долларов, тогда уже начинает иметь смысл расширять локальную мощность.

Простой процесс подбора

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

Начните с одной пары моделей

Выберите одну модель для основной задачи и один резервный путь. Привяжите обе к одной и той же задаче, например к внутреннему чату, поиску по документам или черновикам ответов поддержки. Если ваша первая модель — локальная модель 7B или 8B, в качестве резерва может быть облачный API или более маленькая локальная модель, которая отвечает медленнее, но все же работает.

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

Дальше запишите бюджет памяти простыми словами. Считайте три корзины: веса модели, KV-кэш и системные накладные расходы. Веса — это базовая цена загрузки модели. KV-кэш растет вместе с длиной контекста и числом активных запросов. Системные накладные расходы покрывают ОС, движок инференса, мониторинг и запас прочности, чтобы машина не жила весь день на 99% памяти.

Если у GPU 24 ГБ VRAM, не планируйте использовать все 24 ГБ. Оставляйте запас. Команды, которые его пропускают, обычно винят модель, хотя реальная проблема — давление на память.

Оцените обе схемы по цене

Задайте реальную цель по пиковой одновременности, прежде чем что-то считать. Не спрашивайте, сколько людей вообще может пользоваться системой. Спросите, сколько человек будут обращаться к ней одновременно в самый загруженный час. Для внутреннего пилота на 20 сотрудников это число может быть 2–4, а не 20.

Потом сравните два бюджета. Первый — полностью локальный: сервер, GPU, электричество, время на настройку и время на поддержку. Второй — смешанный: меньшая локальная машина для обычной работы плюс облачный резерв для всплесков, длинных запросов или сбоев модели. Смешанные схемы на бумаге выглядят менее «чистыми», но в начале обычно тратят меньше денег.

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

Если пилот спокойно выдерживает ваш час пик, можно с уверенностью покупать больше оборудования. Если нет, вы поняли это дешевым способом.

Реалистичный пример пилота

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

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

Для скромного пилота может хватить одного сервера с одной GPU и достаточным объемом системной RAM, чтобы удерживать модель, кэш контекста и остальной стек. В обычный будний день такое решение может работать вполне нормально. Три агента отправляют черновики, каждый ждет 5–12 секунд, и никто не жалуется. Сырая скорость модели выглядит прилично, но лучший признак проще: очередь остается короткой.

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

Этот же пилот все равно может провалиться в конце месяца. Объем обращений растет, больше агентов работает одновременно, и одновременность на короткое время подскакивает с трех до семи или восьми. Сервер не стал медленнее. Очередь стала длиннее. Агент, который ждет черновик 50 секунд, часто перестает пользоваться инструментом, даже если модель сама по себе генерирует быстро, когда наконец начинает.

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

Ошибки, которые сжигают бюджет

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

Именно поэтому подбор оборудования для локальных моделей проваливается, когда он начинается с «нам нужна модель 70B», а не с «какие задачи люди будут выполнять весь день?». Меньшая модель с правильным окном контекста часто лучше, чем более крупная, которая заставляет постоянно урезать контекст, повторять попытки или придумывать неудобные обходные пути.

Еще одно дорогое предположение — что каждому пользователю нужна отдельная GPU. У большинства команд это не так. Им нужна общая мощность для запросов, которые накладываются в загруженные периоды. Если доступ есть у 40 человек, но одновременно модель спрашивают только 4, покупка оборудования «на 40 пользователей» — это не безопасность, а расточительство.

О расходах, о которых забывают

Оборудование — это только часть счета. Команды забывают про хранилище для файлов моделей, быстрые локальные диски для кэширования, мониторинг, резервные копии, обновления драйверов и время поддержки, которое нужно, чтобы стек оставался живым. Пилот может выглядеть дешевым в таблице, а потом начать съедать деньги, когда инженеры каждую неделю тратят часы на исправление таймаутов, разрастания логов или сломанных развертываний.

Решения по приватности вызывают еще одну утечку бюджета. Некоторые руководители воспринимают приватность как выбор «да» или «нет» и переносят каждую задачу on-prem. Это кажется аккуратным, но часто делает расходы выше. Многие компании могут держать чувствительные запросы локально, скрывать или маскировать рискованные данные и отправлять низкорисковые задачи в облачные модели, когда спрос растет. Такой микс обычно дешевле, чем подбирать локальное оборудование под худший час месяца.

Один показатель быстро ловит эти ошибки:

• стоимость одного завершенного задания
• среднее время ожидания в часы пик
• объем памяти на реальной длине контекста
• часы поддержки в неделю
• расходы на резерв, когда локальной мощности не хватает

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

Быстрая проверка перед покупкой

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

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

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

Потом проверьте простой стресс-сценарий: что если количество запросов удвоится на один час? Если ответ такой: «мы поставим их в очередь и согласимся на более медленные ответы», это нормально. Если ответ: «мы не можем замедляться», вам может понадобиться больше памяти GPU, второй узел или путь облачного всплеска.

Короткая проверка перед покупкой помогает:

• Измерьте самые загруженные 15 минут, которые вы ожидаете в первый месяц.
• Запишите полный объем памяти, а не только веса модели.
• Решите, что произойдет во время часового всплеска трафика.
• Отметьте, какие задачи можно безопасно переводить в облако.
• Назовите человека, который отвечает за патчи, мониторинг и поломки оборудования.

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

И наконец, посчитайте человеческую сторону. Кто-то должен ставить патчи драйверов, следить за состоянием дисков, менять вышедшие из строя детали и держать запасную мощность наготове. Если за это никто не отвечает, ваши on-prem AI costs уже выше, чем показывает таблица. Oleg Sotnikov часто помогает командам проверить именно этот разрыв до того, как они зафиксируют деньги в оборудовании.

Что делать дальше

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

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

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

Держите небольшой облачный резерв, пока использование стабилизируется. Это дает вам запас прочности, когда спрос резко растет, модель падает или более длинный запрос пробивает локальную память. Это также дает чистое сравнение для on-prem AI costs, а не догадки после того, как серверы уже куплены.

Каждую неделю смотрите на одни и те же цифры:

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

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

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

Если вам нужен второй взгляд перед следующими тратами, Oleg Sotnikov может проверить математику по оборудованию, стоимость резервного облака и рамки запуска как fractional CTO. Такой внешний аудит часто обходится дешевле, чем одна неверная покупка сервера.

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