Сколько видеокарт нужно, определяет реальная нагрузка

Для 200 сотрудников не нужны 200 видеокарт. В большинстве офисных сценариев разумная начальная точка - две серверные видеокарты по 48 ГБ, если проверенная на ваших задачах модель класса 14B работает в 4-битном или 8-битном формате. Одна такая карта годится для пилота, две дают отдельные реплики для нагрузки и обслуживания. Если качество требует модели класса 32B в BF16, расчет быстро вырастает до двух карт по 80 ГБ на одну реплику и четырех для отказоустойчивой пары.

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

Двести учетных записей не создают двести одновременных запросов

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

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

Для первого приближения полезна формула Литтла:

среднее число занятых запросов = запросов в секунду × среднее время обслуживания

Допустим, в самый напряженный пятиминутный интервал активны 30 из 200 сотрудников. Каждый отправляет запрос в среднем раз в 90 секунд, а сервер генерирует ответ 12 секунд. Тогда средняя занятость равна 30 / 90 × 12 = 4 последовательностям. Среднее не покрывает всплески, поэтому для теста я заложил бы 8 одновременных последовательностей и отдельно воспроизвел момент, когда несколько человек вставляют длинные документы.

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

Профиль запроса надо зафиксировать до выбора железа

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

Первый профиль - короткий вопрос с поиском: около 1 500 входных токенов после добавления системной инструкции и найденных фрагментов, до 250 токенов ответа. Второй - сводка документа: 6 000-10 000 токенов на входе и 500 на выходе. Третий - продолжение длинного диалога, где история постепенно растет. Четвертый - редкий тяжелый запрос, например сопоставление нескольких положений. Числа здесь служат шаблоном измерения, а не нормой для вашей организации.

Для каждого профиля запишите:

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

Не смешивайте время до первого токена и полное время ответа. Длинный текст может печататься 20 секунд и ощущаться нормально, если первые слова появились через две секунды. Ответ на короткий вопрос, который молчит десять секунд и затем выводится мгновенно, воспринимается хуже. Я обычно задаю отдельные цели, например p95 до первого токена не более трех секунд и p95 интервала между токенами не более 80 миллисекунд. Это пример договора об уровне сервиса, а не обещание конкретного ускорителя.

Обрезка истории часто экономит больше, чем переход на следующую карту. Ассистенту не всегда нужен весь диалог. Сводка старых реплик, ограничение числа найденных фрагментов и запрет бесконтрольного вложения файлов уменьшают вход, KV-кеш и время предварительной обработки. Но нельзя просто обрезать все до 2 000 токенов: юридические и технические ответы потеряют основание. Лимит выбирают по проверке качества на реальных задачах.

Память занимают веса, KV-кеш и рабочий запас

Модель, которая едва загрузилась в память ускорителя, еще не готова обслуживать пользователей. Видеопамять делят веса, KV-кеш активных последовательностей, временные тензоры, графы выполнения и сам сервер инференса. Оставлять запас нужно не из суеверия: пиковая операция или более длинный пакет может завершить процесс с ошибкой нехватки памяти.

Грубая оценка весов проста:

память весов ≈ число параметров × бит на вес / 8

У модели 14B теоретический минимум весов равен примерно 28 ГБ в BF16, 14 ГБ при 8 битах и 7 ГБ при 4 битах. Реальный файл и занятая память будут больше из-за коэффициентов квантования, служебных данных, отдельных слоев в более высокой точности и буферов среды выполнения. Для 32B получаются примерно 64, 32 и 16 ГБ до накладных расходов. Поэтому фраза «32B в INT4 помещается в 24 ГБ» может быть верна для одного формата и ложна для другого.

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

KV на токен = 2 × слои × KV-головы × размер головы × байт на элемент
общий KV = KV на токен × активные токены всех последовательностей

Пара множителей 2 означает ключ и значение. Параметры надо брать из config.json именно выбранной модели, а не из похожего семейства. Например, конфигурация Qwen2.5-14B-Instruct указывает 48 слоев, 8 KV-голов и скрытый размер 5120 при 40 головах внимания. Размер одной головы равен 128. При BF16 кеш на токен получается 2 × 48 × 8 × 128 × 2 = 196 608 байт, около 0,1875 МиБ. Восемь последовательностей по 4 000 занятых токенов потребуют примерно 5,9 ГиБ KV-кеша. Для Qwen2.5-32B-Instruct с 64 слоями при остальных указанных величинах это около 0,25 МиБ на токен, или примерно 7,8 ГиБ для того же пакета.

Эта проверка делает различие, которое часто теряют в обсуждении квантования. Квантованные веса не гарантируют столь же компактный KV-кеш. Сервер может хранить кеш в FP16, BF16 или поддерживаемом FP8 независимо от формата весов. Сначала уточните kv_cache_dtype и поддержку выбранного ускорителя, затем считайте. FP8 может сократить кеш, но его влияние на качество и совместимость проверяют, а не предполагают.

Документация vLLM прямо описывает gpu_memory_utilization как долю памяти для весов, активаций и KV-кеша, а при вытеснении запросов советует уменьшить число последовательностей или пакет токенов либо добавить память через больший тензорный параллелизм. Это полезнее рекламной таблицы совместимости: сервер сам сообщает, сколько блоков кеша создал и начались ли вытеснения. Нулевая ошибка загрузки говорит только о старте процесса.

Размер модели меняет качество и топологию

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

Практически классы выглядят так:

Таблица не заменяет проверку. NVIDIA в матрице поддержки NIM указывает 80 ГБ для H100 и A100, 48 ГБ для L40S и 24 ГБ для A10G, а для непроверенных сочетаний называет оценки, не гарантии. С этим уточнением я согласен. Одинаковый объем памяти не делает карты равными по пропускной способности памяти, вычислениям низкой точности, охлаждению и режиму круглосуточной работы.

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

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

Допустимое время ответа превращается в поток токенов

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

Среднюю потребность в выдаче можно оценить так:

выходных токенов в секунду =
запросов в секунду × среднее число выходных токенов

Если пиковые 20 запросов в минуту возвращают по 250 токенов, средняя потребность равна примерно 83 выходным токенам в секунду. Покупать конфигурацию, которая показала 85 токенов в секунду в лаборатории, нельзя. Распределение запросов неровное, длинные входы конкурируют за вычисления, а служебные вызовы добавляют работу. Для первичного теста я умножаю наблюдаемый пик хотя бы на 1,5 и прогоняю отдельный резкий всплеск. В этом примере цель стенда будет не ниже 125 токенов в секунду при соблюдении задержки, а не просто максимальное число токенов без ограничения очереди.

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

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

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

Расчет для 200 сотрудников дает диапазон, а не одно число

Возьмем организацию с 200 сотрудниками, где ассистент ищет по внутренним документам и готовит черновики. В пиковые пять минут активны 30 человек. Система получает 20 видимых запросов в минуту, а на каждый видимый запрос приходится в среднем 1,2 вызова модели с учетом переформулирования поиска. Итого 24 вызова в минуту, или 0,4 вызова в секунду.

Пусть измеренный профиль дает 2 500 входных токенов на вызов в среднем, 6 000 на p95 и 250 выходных токенов. Среднее время активной генерации - 12 секунд. Формула Литтла дает 0,4 × 12 = 4,8 одновременно занятых последовательностей. Для всплеска стенд должен выдержать 8, а проверка перегрузки - 12. При восьми последовательностях и среднем занятом контексте 3 000 токенов модель 14B из предыдущего примера потребует около 4,4 ГиБ KV-кеша в BF16.

Предположим, оценка качества показала, что 14B-модель в проверенном 4-битном формате подходит для 92 из 100 контрольных заданий, а оставшиеся восемь должны уходить человеку. Это не статистика рынка, а пример приемочного порога. Ее веса займут ориентировочно 8-10 ГБ вместе с накладными данными конкретного формата. На карте 48 ГБ остается достаточно места для кеша, временных буферов и умеренного роста контекста. Память здесь не главный риск, им становится поток вычислений.

Требуемая средняя выдача равна 0,4 × 250 = 100 токенов в секунду. С коэффициентом 1,5 тестовая цель составляет 150 токенов в секунду при p95 времени до первого токена в пределах принятой цели. Если одна карта дает это на смешанном профиле, две независимые карты разумно развернуть как две реплики. Балансировщик делит запросы, а одна реплика переживает обслуживание второй в деградированном режиме. Получается две карты, а не потому, что сотрудников 200.

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

Теперь заменим модель на 32B BF16. Только веса требуют около 64 ГБ до накладных расходов. Одна карта на 80 ГБ может загрузить сборку, но запас под 6-8 ГиБ кеша, буферы и пики окажется тесным. Две карты по 80 ГБ в тензорной параллели дают рабочую реплику с запасом, а производственная пара таких реплик требует уже четыре карты. Вот почему решение о качестве модели должно предшествовать спецификации сервера.

Разумный старт зависит от цены ошибки

Для обычного внутреннего помощника я бы начал с двух карт по 48 ГБ и 14B-модели в проверенном квантованном формате. Это не самый маленький работающий стенд, зато он позволяет сравнить одну и две реплики, пережить обслуживание и получить честные данные о пике. Если бюджет пилота ограничен, одна карта на 48 ГБ допустима, но ее нельзя выдавать за готовую производственную схему.

Для справочного ассистента с короткими ответами может хватить двух карт по 24 ГБ, по одной на реплику, если 7B-8B модель проходит проверку качества и каждая карта выдерживает половину пика. Для сложного анализа документов, где 32B дает подтвержденное преимущество, рассмотрите два других старта: две карты по 48 ГБ с проверенной 4-битной моделью как независимые реплики или четыре карты по 80 ГБ для двух BF16-реплик по две карты. Сравнивать надо стоимость всего сервиса, а не цену одной карты.

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

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

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

Стенд должен воспроизводить очередь, а не один красивый запрос

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

Минимальный план испытаний состоит из пяти прогонов:

1. Один короткий запрос измеряет лучшую интерактивную скорость и обнаруживает ошибки шаблона.
2. Постоянная расчетная нагрузка в течение 30 минут показывает устойчивый поток и нагрев.
3. Смешанный набор коротких и длинных входов воспроизводит офисный профиль.
4. Двукратный всплеск проверяет очередь, тайм-ауты и восстановление после пика.
5. Отключение одной реплики показывает, что оставшаяся система действительно принимает запросы.

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

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

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

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

Производственная конфигурация шире числа GPU

Ускорители не исправят медленное хранилище модели, нехватку оперативной памяти, слабую сеть или питание без резерва. Сервер должен загрузить веса, пережить перезапуск и отвести тепло при постоянной нагрузке. Проверьте объем RAM, скорость локального накопителя, линии PCIe, совместимость карт с корпусом, мощность блоков питания и фактический тепловой режим стойки.

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

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

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

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

Решение о покупке помещается в одну расчетную ведомость

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

Порядок расчета такой:

1. вызовы/с = активные пользователи × действий/с × вызовов на действие
2. занятые последовательности = вызовы/с × длительность генерации
3. требуемый decode = вызовы/с × выходные токены
4. память = веса + KV активных токенов + измеренные буферы + запас
5. карты на реплику = максимум требования по памяти и теста производительности
6. всего карт = карты на реплику × число независимых реплик

Строка 5 не выводится из теоретической пиковой производительности. Ее заполняет результат стенда. Строка 6 зависит от допустимого простоя: для пилота множитель может равняться одному, для рабочего сервиса обычно нужны минимум две независимые реплики. Если модель растянута на две карты, для пары реплик множитель дает четыре карты.

Для приведенного профиля ответ прост: одна карта 48 ГБ доказывает работоспособность 14B-модели, две карты 48 ГБ образуют разумный производственный старт, если каждая реплика проходит смешанный тест. Для 32B BF16 разумный старт может составить четыре карты 80 ГБ, потому что одна реплика занимает две. Между этими точками есть варианты с 4-битной 32B, картами другого класса и маршрутизацией двух моделей.

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