Пост Куда пропала дешевая память?

Куда пропала дешевая память? Можно даже расширить вопрос - и дешевые SSD? Про видеокарты все понятно, сначала крипта, потом AI. Геймерам остается только покупать приставки. Учитывая их железо не удивлюсь, если ими в ноль торгуют, отбивая деньги на играх. Но вернемся к разработке. Ответ легко найти в интернете - виноват AI. Первая связь, которая приходит на ум - видеокартам нужна память. А для видеопамяти хотя и используется специальный тип памяти HBM, но эта память, как и ОЗУ, и чипы в SSD часто производят на одних и тех же фабриках. И понятно что сейчас там фокус на память для видеокарт. Давайте прикинем, сколько памяти нужно для развёртывания LLM модели? Модель - это набор векторов, вектор - набор float чисел. Количество параметров модели = количеству этих чисел. Каждому сгенерированному токену (это несколько символов) тоже соответствует вектор, эти вектора сохраняются в KV кэше чтобы не пересчитывать заново. Сразу важная ремарка - скорость ответа LLM критична к скорости работы с памятью. Поэтому целевой кейс - модель и ее KV кэш находятся в памяти видеокарты, т.к. она самая быстрая. Еще момент - кэш сессионный, нельзя смешивать данные разных пользователей. Т.е получаем формулу: V = Vllm + Vkv * sessions + Vsys Vllm - объем памяти для модели, Vkv - для кэша, sessions - число одновременных сессий, Vsys - системная память, как некий аналог - в JVM приложении выделяется фиксированная область памяти для JIT компилятора. Можно перенебречь, это единицы Гб. По умолчанию 2 байта на число. Тогда для к примеру Qwen-3-Coder-Next со 80B параметров Vllm = params x bytes = 80 x 10^9 × 2 = 160 Гб где params - количество параметров модели bytes - размерность одного числа, 2 байта. 160 Гб - уже неплохо. Локально не запустим) Перейдем к KV кэшу. Типовое число одновременных сессий зависит от мощности GPU. Цель - максимальная утилизация мощности GPU. Ограничение - размер памяти. Пока будем считать для одной сессии. Вторая важная переменная - размер контекстного окна модели. Это и есть размер кэша. У Qwen - 256k. К слову, максимум на данный момент - 1 млн. Тут надо понимать, что декларируемый размер окна - теоретический максимум и частично маркетинг. Как говорится - должен, но не обязан) Для чатов и для code агентов с условно безлимитными подписками провайдеру не выгодно давать полное окно в 1 млн токенов, и скоро станет ясно почему. Хотя при оплате за токены получить его можно. Поэтому наш пример можно считать типовым. Далее KV - это key и value. Почему кстати key и value - почему не просто вектор? Модель при генерации очередного токена использует все ранее сгенерированные токены. key определяет вес (важность) данных в старом токене для генерации нового, а value - это собственно сами данные. Этот механизм называется Attention. А общая формула для кэша такая: Vkv = sessions × context х размер токена = sessions × context × ( 2 × bytes × layers х hidden ) layers и hidden - число слоев и размер вектора - это представление символа внутри движка инференса. Слой можно представить как этап конвейера генерации символов. Примерно можно считать, что первые этапы отвечают за лексику и синтаксис, последние - за смысл. Числа отличаются от модели к модели, значения для Qwen Coder - 48 и 2048 соответственно. bytes такой же, как и для модели - 2 байта, float. Итого получаем: Vkv = 1 х 256 000 х 2 × 2 × 2048 × 48 = 100 Гб Тут уже прикольно, что токен "кот" в LLM превращается в 400kB. gif-ки с котиками они там что ли хранят (шутка) Итого 260 Гб памяти на одну клиентскую сессию на не самой сильной модели. Ага, вот куда вся память делась!) Попросил ты такой перевести LLM страничку на русский и сожрал 260 Гб... Тут может возникнуть вопрос - а как оно вообще работает?) Условный Claude Opus вообще ни в одну видеокарту не влезет. Там по оценке 5 триллионов параметров, т.е. в 50 раз больше, и пропорционально увеличившийся KV кэш. Ответ: оптимизации. Кажется среди AI инженеров сейчас много хороших оптимизаторов)