Глава 1 — Механика генерации токенов

Первый пост поглавного разбора LLM Primer VI: Scaling AI Systems. Глава, утверждающая, что почти каждый трудный вопрос serving-а LLM спускается к одному факту — цикл, порождающий каждый токен, ограничен пропускной способностью памяти, и дорогие вычисления, за которые вы заплатили, простаивают 99,7 процента времени.

Зачем эта глава существует

LLM в работе — это предиктор следующего токена, обёрнутый в цикл. Токены поступают на вход, распределение вероятностей следующего токена выходит наружу, один выбирается, дописывается, и цикл повторяется. Каждое интересное свойство серверного стека — батчинг, квантизация, KV-кэширование, спекулятивный декодинг, дизагрегированный serving — спускается к пристальному взгляду внутрь этого цикла. Цикл скрывает две нагрузки, которые делят один код, но нагружают железо в противоположных направлениях. Одна ограничена вычислениями. Другая — пропускной способностью. На одном и том же H100. В одном и том же прямом проходе. Точное именование этого разделения — первое движение книги, и это тот фрейм, к которому каждая последующая глава возвращается.

1.1 Авторегрессионный цикл последователен принудительно

Токен t+1 — функция каждого токена вплоть до t включительно. Модель не может предсказать t+2, пока t+1 не выбран, потому что предсказание t+2 требует, чтобы t+1 уже был во входе. Нет умного ядра, распараллеливающего генерацию двух подряд идущих токенов для одной последовательности; последовательный характер задан структурой зависимостей самой операции. Стоимость по стенным часам для N-токенной генерации равна N-кратной стоимости одного шага плюс фиксированный оверхед. Каждая оптимизация далее в книге — большие батчи, спекуляция вперёд по траектории, более дешёвая арифметика на шаг — есть частичный ответ на вопрос: «раз цикл обязан идти по одному токену за раз, как сделать каждый шаг быстрее или каждый батч шире?» У модели также нет внешнего блокнота: она думает, испуская токены. Цикл — единственный механизм, которым модель получает возможность думать дольше, и именно поэтому chain-of-thought и спекулятивный декодинг живут внутри одной и той же учётной книги.

1.2 Prefill и декодинг нагружают чип противоположно

Цикл скрывает две фазы. Prefill — первый прямой проход, поглощающий промпт пользователя в форме [batch, sequence_length, hidden_dim]. Каждое матричное умножение работает по всем позициям последовательности сразу; арифметика растёт с длиной последовательности; веса читаются из HBM один раз и применяются к многим строкам работы. Арифметическая интенсивность высока. Prefill ограничен вычислениями и получает доступ к 989 BF16 TFLOP/s H100. Декодинг — каждый последующий прямой проход. Форма входа сжимается до [batch, 1, hidden_dim]. Веса каждого слоя всё равно нужно стримить из HBM, но арифметика выполняется лишь для одной строки против них. Арифметическая интенсивность падает на три порядка. Декодинг ограничен пропускной способностью памяти. На 70B-модели в BF16 prefill на промпте в 2 000 токенов идёт почти по вычислительной крыше чипа; следующий же прямой проход — первый шаг декодинга — идёт против тех же 140 ГБ весов, чтобы выдать один токен. Чип не изменился. Изменилась нагрузка.

1.3 Один пользователь оставляет H100 простаивать на 99,7 процента

Следствие: генерация в реальном времени для одного пользователя — худший случай для фронтирного акселератора. 70B-модель в BF16 на одном H100 SXM декодит примерно 24 токена в секунду — комфортная для чтения скорость, — и HBM3 чипа с пропускной 3,35 ТБ/с полностью насыщен: он перегоняет 140 ГБ весов на каждый токен. Но на этой скорости вычислительные блоки выполняют лишь около 3,36 TFLOP/s из своих 989. Утилизация вычислений — 0,34 процента. Физически чип настроен верно; каждая SM читает и умножает на полной скорости, но тензорные ядра рассчитаны на потребление плиток из многих строк против каждой плитки весов, а прямой проход на один токен даёт им одну строку. Вычислительная ёмкость номинирована в единице (операции на загруженный байт), которую нагрузка не производит. Кто-то всё равно платит четыре-восемь долларов в час за весь чип. Экономика serving-а LLM — это экономика поиска работы для запаркованных вычислений: через батчинг, через более дешёвую пропускную способность на токен, через спекуляцию, через железо, чья точка баланса совпадает с нагрузкой.

Что подготавливает глава 1

Остальная часть книги — ответ на асимметрию, названную здесь. Глава 2 разбирает KV-кэш — структуру данных, которая позволяет декодингу избежать квадратичного пересчёта и по ходу дела становится крупнейшим единичным потребителем VRAM в serving-кластере. Главы 3 и 4 обходят аппаратную подложку через призму пропускная-против-вычислений. Главы 5 и 6 уменьшают бремя пропускной способности на токен через уменьшение самих весов. Глава 7 обходит батчинг как рычаг системного уровня, превращающий bandwidth-bound простой в пропускную способность. Главы 8 и 9 меняют форму работы страничным управлением KV и спекулятивным декодингом. Каждое движение читается как попытка заполнить простой, только что измеренный этой главой.

Дальше — Глава 2: Проблема KV-кэша. Рабочее пространство, делающее декодинг экономически возможным, и формула памяти, объясняющая, почему serving-кластеры заканчивают VRAM раньше вычислений.