VRAM (видеопамять)

VRAM — это выделенная память с высокой пропускной способностью, размещённая прямо на GPU; во время обучения или инференса в ней лежат веса модели, активации, возникающие при прохождении данных через сеть, и KV-кэш, накапливаемый за одну генерацию. Её объём — жёсткое ограничение, а не вопрос предпочтений по производительности: если рабочий набор не помещается, модель на этом устройстве не запустится вовсе, и никакое терпение этого не компенсирует. Именно эта бинарность объясняет, почему VRAM оказывается первым числом, которое команды проверяют, оценивая, можно ли разместить конкретную модель с открытыми весами на своём или арендованном железе, и почему облачные GPU-инстансы принято тарифицировать и выбирать по объёму памяти больше, чем по любой другой отдельной характеристике. Отсюда же растут два самых распространённых обходных приёма во всём стеке: квантизация, уменьшающая занимаемый весами объём за счёт снижения числовой точности, и параллелизм модели, разделяющий одну модель между несколькими GPU, чтобы её удержала их суммарная память. Две детали регулярно подводят людей. Требования к VRAM не масштабируются строго линейно от числа параметров при фиксированной точности: память под активации, накладные расходы фреймворка и прежде всего KV-кэш, растущий одновременно с длиной контекста и размером батча, существенно добавляются к голому объёму весов, — поэтому модель, которая на бумаге вроде бы впритык помещается, чаще всего не помещается, стоит начать обслуживать реальный параллельный трафик на длинном контексте. И достаточный для загрузки модели объём VRAM не гарантирует приемлемой скорости. Пропускная способность памяти и вычислительная производительность — независимые свойства карты, так что GPU с щедрым объёмом, но скромной пропускной способностью загрузит крупную модель и всё равно будет медленно выдавать токены. Это частый и дорогой сюрприз при выборе железа по одной лишь ёмкости. KV-кэш заслуживает отдельного упоминания: именно он масштабируется вместе с вашим трафиком, а не с выбором модели, и именно он ломает планирование ёмкости, сделанное на тихой машине разработчика. Веса — фиксированная стоимость с момента выбора модели; кэш — переменная, растущая с каждым параллельным пользователем и каждым дополнительным токеном контекста. А значит, развёртывание, спокойно работавшее в тестах, способно упереться в потолок памяти под продакшн-конкурентностью на длинных контекстах, притом что в самой модели ничего не изменилось. Планируйте ёмкость по худшему реалистичному сочетанию длины контекста и конкурентности, а не по одним весам. Если цифры не сходятся, порядок рычагов примерно такой: квантизовать веса, ограничить или резюмировать контекст, снизить предельную конкурентность на устройство и только затем делить модель между GPU — параллелизм добавляет накладные расходы на обмен и операционную сложность, которых предыдущие варианты не несут.