Локальные LLM в корпоративном контуре: требования к железу

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

Для ориентира: модель на 7 млрд параметров занимает около 14 ГБ видеопамяти в FP16, ещё до учёта контекста и служебных расходов. Поэтому 24 ГБ на потребительской карте для такой модели вполне могут быть достаточны, хотя запаса на длинный контекст и параллельные запросы останется меньше. А вот для модели на 70 млрд параметров в FP16 потребуется около 140 ГБ только под веса. Между этими сценариями лежит практический вопрос корпоративного внедрения: какую модель можно разместить в контуре, с какой скоростью она будет отвечать и сколько запросов сможет обслуживать.

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

Математика видеопамяти: почему VRAM определяет успех внедрения

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

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

Для весов в FP16 или BF16 можно использовать грубый ориентир: около 2 ГБ на каждый миллиард параметров. Семь миллиардов параметров занимают примерно 14 ГБ, а 70 млрд, около 140 ГБ. Это оценка для самих весов; отдельно нужно оставить место для KV-cache, буферов и работы рантайма. У конкретной модели фактическое потребление зависит от архитектуры, реализации и настроек запуска.

VRAM нужно считать целиком: веса модели, KV-cache и служебные расходы рантайма. Число параметров показывает только часть бюджета.

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

Квантование как способ оптимизации: от FP16 до INT4

Квантование уменьшает разрядность представления весов. Это позволяет сократить их объём в памяти, но результат зависит от выбранного метода, архитектуры модели и задачи. Условно, при 8-битном хранении требуется около 1 ГБ на миллиард параметров, при 4-битном около 0,5–0,6 ГБ. Это ориентиры для оценки, а не обещание, что модель займёт ровно столько: к весам добавляются метаданные, контекстный кэш и рабочие буферы.

Q4_K_M, один из распространённых вариантов квантования в экосистеме GGUF, использует смешанное представление блоков весов. В нём для разных групп параметров применяются разные уровни точности, чтобы удержать баланс между размером и качеством. Это не «K-средняя калибровка»: буквы в названии обозначают вариант схемы квантования, а M относится к её конфигурации. Такие обозначения важны при сравнении файлов моделей, но сами по себе не гарантируют одинаковое качество у разных семейств.

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

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

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

Роль KV-cache в масштабировании контекста и потреблении ресурсов

KV-cache хранит ключи и значения механизма внимания (Key, Value), рассчитанные при обработке входного текста. При генерации модель использует эти данные повторно, вместо того чтобы заново обрабатывать весь контекст на каждом шаге. Это ускоряет работу, но требует дополнительной памяти. Чем длиннее контекст и чем больше активных запросов, тем больше становится кэш.

На его размер влияют длина контекста, число слоёв модели, размер скрытых представлений, количество голов внимания и точность хранения кэша. Поэтому универсальная оценка только по числу параметров здесь не работает: две модели одного размера могут расходовать на KV-cache разный объём памяти.

Для Llama 3.3 70B при контексте 32 тысячи токенов в FP16 приводится оценка около 20 ГБ под KV-cache; при увеличении контекста до 128 тысяч токенов оценка доходит до 80 ГБ. Это конкретный пример для определённой модели и настроек, а не правило для всех LLM. Он показывает масштаб эффекта: в таком режиме кэш может занять сопоставимый объём с весами модели, сохранёнными в 4-битном формате.

Длинный контекст расходует память даже после того, как модель поместилась в GPU. Чем больше документов и одновременных запросов, тем важнее считать KV-cache отдельно от весов.

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

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

Аппаратные конфигурации для моделей разного класса: от 7B до 70B

Ниже приведены ориентиры для весов в Q4 и FP16. Они помогают сравнить классы моделей, но не заменяют расчёт полной нагрузки: VRAM понадобится также для KV-cache, рантайма и параллельных запросов.

На практике требования к железу заметно меняются в зависимости от выбранного формата и контекста. Лёгкая модель в Q4 может запускаться на одной потребительской карте с 8–12 ГБ VRAM, если запросы короткие и не требуется большой запас под параллельную работу. Модель среднего класса в FP16 уже требует существенно больше памяти; в Q4 она доступнее, но итоговая конфигурация всё равно зависит от контекста и нагрузки.

Для 70B в Q4 ориентир по весам составляет около 40–49 ГБ. Один ускоритель с 48 ГБ может подойти для некоторых конфигураций, но запас под KV-cache и служебные расходы будет ограниченным. Карта с 80 ГБ даёт больше пространства для контекста и нагрузки. Другой вариант, распределить модель между несколькими GPU. Например, две карты по 24 ГБ способны дать нужную суммарную ёмкость при подходящем программном стеке, однако VRAM в таком случае не превращается в единый пул автоматически.

Здесь важно уточнить роль NVLink. Этот интерфейс не ограничен профессиональными видеокартами: его поддерживают, например, потребительские RTX 3090. Но наличие NVLink само по себе не объединяет память карты для любой программы. Нужно, чтобы это поддерживали GPU, серверная конфигурация и выбранный движок инференса. При отсутствии подходящего обмена модель тоже можно распределить по GPU через PCIe, однако задержки и пропускная способность межкарточного взаимодействия становятся частью расчёта.

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

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

Риски CPU Offload и критические узкие места при работе с локальными серверами

CPU offload позволяет держать часть модели в системной RAM, когда в VRAM не хватает места. Это помогает запустить модель на доступном оборудовании, но меняет профиль работы: данные приходится передавать между CPU и GPU. Пропускная способность системной памяти и PCIe обычно значительно ниже, чем у памяти GPU, поэтому offload может заметно снизить скорость генерации.

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

Большой объём RAM сам по себе не делает offload быстрым. Рабочая станция с 96 ГБ системной памяти и GPU на 24 ГБ может запустить крупную квантованную модель при подходящей конфигурации, однако скорость будет зависеть от того, сколько весов остаётся в системной памяти и как часто данные передаются через PCIe. Поэтому такой вариант стоит рассматривать как способ проверить сценарий или обслуживать нетребовательную офлайн-задачу, а не как готовую промышленную архитектуру.

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

После проверки VRAM остаются другие ограничения. В multi-GPU-системах производительность зависит от способа распределения модели и связи между ускорителями. Несколько мощных карт требуют подходящего блока питания и охлаждения; в серверной конфигурации важны также размеры корпуса, воздушный поток и возможности помещения. Если эти условия недооценить, оборудование может формально соответствовать расчётам, но не выдерживать длительную нагрузку.

Аппаратные требования для LLM включают и программную совместимость. Движок должен поддерживать конкретную архитектуру модели, формат квантования, GPU и способ распределения весов. Инструменты вроде vLLM, TensorRT-LLM и llama.cpp предлагают разные режимы инференса и управления памятью; их возможности и требования отличаются. PagedAttention, например, помогает эффективнее организовать KV-cache, но не отменяет потребности в памяти. Спекулятивное декодирование может ускорить генерацию в подходящих сценариях, однако его результат тоже зависит от моделей и нагрузки.

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

Что это значит для корпоративного внедрения

При планировании локального хостинга стоит начинать с целевой нагрузки, а не с желания взять модель покрупнее. Оценка числа параметров даёт приблизительный бюджет под веса: для Q4 можно использовать ориентир около 0,5–0,6 ГБ на миллиард параметров. Затем отдельно учитываются KV-cache, служебные расходы и запас для параллельных запросов. Размер окна контекста должен соответствовать сценарию, а не выбираться по максимальному значению, которое поддерживает модель.

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

Главное изменение в локальном инференсе происходит не в базовой арифметике, а в инструментах управления ресурсами. Квантование, оптимизация KV-cache и более эффективные движки позволяют лучше использовать имеющееся оборудование. Но они не превращают ограниченную память в бесконечную. Хорошая конфигурация начинается с честного расчёта: какие веса помещаются в GPU, сколько места заберёт контекст и какую задержку пользователи готовы принять. Именно от этого зависит, станет ли локальная модель устойчивой частью корпоративного контура или останется удачным демонстрационным запуском.