Полный процесс инференса LLM: предзаполнение, декодирование, кэш KV и выбор примеров

От нажатия клавиши до потокового токена

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

Часть 1 — Два типа задач, а не один

Вопрос 1. Что происходит между нажатием клавиши Enter и первым словом?

Честный описательный путь обработки:

1. Входные данные. Приходит строка в формате UTF-8, например "Что такое гравитация?". Система обслуживания обычно помещает ее в шаблон чата с специальными токенами для сообщений системы, пользователя и ассистента.
2. Токенизация. Текст разбивается на части меньшего размера, которые затем преобразуются в целочисленные идентификаторы. На этом этапе происходит лишь обработка строк — нейронные сети еще не задействованы.

Вставка результатов поиска. Каждый идентификатор выбирает строку из матрицы эмбеддингов E ∈ ℝ^(V × d_model), в результате чего формируется тензор размером (seq_len, d_model). Позиционный сигнал добавляется здесь или позже внутри механизма внимания (RoPE).

Заполнение предварительными данными. Каждый токен запроса проходит через все N слоев трансформера одновременно. Каждый слой сохраняет свои проекции K и V в кэш KV. Этот этап ограничен вычислительными ресурсами.

Голова модели языка. Только скрытое состояние последней позиции проецируется на размер словаря (~128K логитов).

Отбор вариантов. Функция Softmax преобразует логиты в распределение; политика (жадный выбор, top-k, top-p, температура и т. д.) выбирает один идентификатор.

Цикл декодирования. Этот идентификатор добавляется, встраивается и снова передается через стек вместе с кэшем KV — по одному новому токену на шаг — пока не срабатывает правило остановки.

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

Время до появления первого токена практически всегда соответствует этапу предзаполнения. Всё, что происходит после этого, — это декодирование.

Вопрос 2. Почему инференс называют двумя разными видами работ?

Предзаполнение и декодирование находятся по противоположным сторонам модели roofline.

Узкое место FLOPs / вычисления Ширина полосы памяти Интенсивность арифметики Высокая ~1–2 FLOPs/байт при обработке пакета 1 Между токенами Полностью параллельно Строго последовательно Фактор задержки TTFT TPOT / ITL Масштабируется с Длиной промпта Длиной вывода MFU (пакет 1) Часто 40–60% Часто 1–5%

При предзаполнении веса загружаются один раз и применяются к тысячам векторов токенов. При декодировании те же веса загружаются заново для одного вектора — гигабайты данных перемещаются ради миллионов операций FLOPs. GPU ожидает данные с HBM.

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

Вопрос 3. Какие показатели задержки имеют значение, и какие параметры на них влияют?

• TTFT — в основном связано с предзаполнением; увеличивается с длиной запроса (и ещё больше, когда доминирует механизм внимания). Полезны кэши префиксов, предзаполнение по частям, ускоренная обработка механизма внимания и более короткие запросы.
• TPOT / ITL — в основном связано с декодированием; примерно равно bytes_per_step / bandwidth. Полезны квантизация, технологии GQA/MQA, спекулятивная декодирование и более мелкие модели.
• End-to-end ≈ TTFT + TPOT × количество токенов в выводе.
• Пропускная способность (токены/секунда/GPU) — показатель, характеризующий работу всей системы; большие группы запросов повышают её, но обычно снижают TPOT на уровне отдельного пользователя.

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

Вопрос 4. Почему декодирование нельзя параллелизовать, как предварительное заполнение?

Генерация является авторегрессивной: каждый новый токен зависит от всех предыдущих. При предварительном заполнении уже известен весь запрос, поэтому позиции можно вычислять совместно под действием причинно-следственной маски. При декодировании «будущее» ещё не существует.

Экспериментальное декодирование — это обходной путь: сначала делаются недорогие предположения, затем они проверяются в одном параллельном проходе — тем самым последовательная зависимость превращается в параллельную проверку (Часть 8).

Часть 2 — Этапы один и два: подача текста

Вопрос 5. Что такое токен — и почему целые слова или сырые символы являются неправильными крайностями

Токен — это подсловный атом из фиксированного словаря. Чистые крайности не сработают:

• Словари слов не имеют ограничений; опечатки и редкие названия превращаются в <UNK>, что уничтожает информацию и приводит к перегрузке таблицы вкладок.
• Словари символов позволяют избежать ситуаций OOV, но удлиняют последовательности в 4–5 раз, что снижает эффективность квадратичного внимания и заставляет ранние слои заново анализировать морфологию.

Субслова находят компромисс: распространённые слова остаются целыми; редкие формы разделяются на осмысленные фрагменты; ничто по-настоящему не считается OOV.

Вопрос 6. Как обучается BPE?

Метод кодирования парами байт начинается с символов (или байтов) и постоянно объединяет наиболее частые соседние пары до достижения желаемого размера словаря. Результаты объединений хранятся в виде отсортированного списка. Во время инференса применяются те же объединения слева направо. Обучение основано на статистике количеств, а не на градиентном спуске — однако полученная структура сегментации влияет на всё последующее обработание.

В7. BPE против WordPiece против Unigram / SentencePiece

• BPE — слияние на основе частоты; декодирование является детерминистичным при наличии таблицы слияний.
• WordPiece (эпоха BERT) — похожее слияние, но оцениваемое по вероятности; часто использует маркеры продолжения ##.
• Unigram / SentencePiece — начинает с большого набора кандидатов и удаляет элементы с помощью униграмматической МЛ; может генерировать варианты сегментации и корректно обрабатывать необработанные байты/Unicode без языкоспецифичных предтокенизаторов.

Современные серийные ЯЗЫКИ склоняются к вариантам BPE или SentencePiece на уровне байтов.

В8. Почему BPE на уровне байтов?

Работа с необработанными байтами гарантирует, что каждая строка будет кодироваться — нет проблем с Unicode. Словарь всё равно учится распознавать распространённые многобайтовые элементы, поэтому английский язык остаётся эффективным, в то время как редкие письменности грациозно переходят на байтовые альтернативы.

В9. Почему модели путаются при подсчёте букв в слове «strawberry»?

Потому что модель никогда не видит символы; она видит идентификаторы токенов. Если «strawberry» представляет собой один или два токена, запрос «посчитай буквы r» предполагает наличие структуры, которая уже удаляется на первом слое. Для задач на уровне символов требуется либо токенизатор, сохраняющий символы, либо внешний инструмент.

В10. Имеют ли сами по себе идентификаторы токенов какое-либо значение?

Нет. Идентификатор — это лишь индекс в таблице эмбеддингов данной модели. Идентификатор 100 в одном токенизаторе не связан с идентификатором 100 в другом. Никогда не используйте токенизаторы из разных моделей вместе.

В11. Особенности токенизаторов в производственных условиях

• Шаблоны чатов и специальные токены должны соответствовать данным, использованным при обучении.
• Пробель в начале строки часто становится отдельным токеном — " Hello" ≠ "Hello".

При подсчёте символов вместо токенов может происходить бесшумное опускание системных инструкций.

Многоязычные альтернативы в виде байтов увеличивают длину и затраты.

Специальные токены для изображений/аудио меняют правила пакетирования.

Вопрос 12. Компромиссы между размером словаря

Больший размер V сокращает последовательности и способствует поддержке многих языков, но увеличивает параметры эмбеддингов и головы нейросети (V × d_model для каждого) а также затраты на декодирование с использованием функции softmax. Типичные значения в современных решениях составляют от 32K до 150K; при превышении этого порога возрастают затраты на память и пропускную способность при снижающейся эффективности.

Вопрос 6. Как на самом деле обучается BPE

Кодирование пар байтов используется как метод сжатия, применяемый для формирования словаря:

1. Начинают с базовых символов (для BPE на уровне байтов — все 256 байтов).
2. Выражают корпус в виде последовательностей этих символов.
3. Подсчитывают соседние пары; выбирают наиболее часто встречающиеся.

Слияние этой пары в новый символ, добавление его в словарь и запись правила слияния с указанием приоритета.

Повторять процесс до достижения целевого размера (например, ~100K–128K в современных стеках).

Результаты: карта символ→ID и упорядоченный список слияний. При кодировании во время повторного выполнения модели слияния происходят жадным образом в этом порядке — детерминированно, без использования алгоритма поиска кратчайших сегментов в целом.

Нюанс: слияния оптимизируют частоту использования, а не лингвистические аспекты. Токен ing формируется из-за его частого использования; морфологическая красота является второстепенной.

Вопрос 7. BPE против WordPiece против Unigram / SentencePiece

• BPE (GPT, Llama): слияние на основе частоты; детерминированное кодирование.

WordPiece (эпоха BERT): похожий алгоритм цикла, но выбирает объединения, которые максимизируют вероятность данных обучения в рамках униграмм-модели, оценивая степень информативности пары как вместе, так и раздельно.

Unigram LM (часто с использованием SentencePiece; класс T5/Gemma): начинает с большого количества токенов и удаляет те, чьё удаление наименее снижает вероятность. Правдоподобностная сегментация позволяет использовать регуляризацию субсловами (выбор альтернативных способов разделения в процессе обучения).

SentencePiece — это библиотека, способная выполнять алгоритмы BPE или Unigram. Её практическое преимущество заключается в обработке необработанных символов с использованием видимого маркера пробела, что делает токенизацию обратимой и свободной от предварительной обработки пробелов — что критически важно для китайского, японского и тайского языков.

Q8. BPE на уровне байтов важен потому что…

Для обозначения символов Unicode потребуется около 150 тыс. начальных символов, и всё равно понадобится <UNK>. Использование байтов UTF-8 означает, что любая строка — эмодзи, кириллица, повреждённые байты — может быть закодирована. Нет проблем с выходом за пределы диапазона.

Затраты: эмодзи могут потребовать несколько токенов; нелатинские алфавиты часто требуют в 2–4 раза больше ресурсов для передачи того же значения, поэтому пользователи, использующие неанглийские языки, раньше сталкиваются с ограничениями по количеству запросов и объёму контекста. Более крупные словари (с увеличением от 32 тыс. до 128 тыс. символов) существуют отчасти для снижения этого разрыва в эффективности.

Вопрос 9. Почему вопрос «Сколько букв “r” в слове strawberry?» не сработает

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

Вопрос 10. Идентификаторы токенов по отдельности

Идентификатор — это индекс в таблицах конкретной модели. Сравнение идентификаторов разных токенизаторов бессмысленно. Даже «специальные» идентификаторы различаются между разными семействами токенизаторов.

Вопрос 11. Проблемы, возникающие в производстве

Обязательно согласовывайте шаблон чата для обучения с набором специальных токенов. Пробель в начале строки часто считается настоящим токеном. При подсчёте символов API, который взимает плату за токены, молча обрезает инструкции. Мультимодальные сентинел-токены меняют способ упаковки данных. Ключи к кэшу должны включать версию токенизатора. Неправильная обработка символов BOS/EOS нарушает условия остановки и проверку значений logprob.

Вопрос 12. Компромиссы между размером словаря

Больший размер V сокращает длину последовательностей и способствует мультимодальной упаковке, но увеличивает размер параметров эмбеддингов и головы нейросети, а также затраты на вычисления функции softmax при декодировании. При размере свыше ~100K–200K обычно приходится платить за память и пропускную способность ради незначительного улучшения качества, если только это не требуется для поддержки многих языков.

Часть 3 — Эмбеддинги

Вопрос 13. Эмбеддинги: метод gather или matmul

Поиск по строке эквивалентен умножению вектора one-hot на E. Метод gather использует специальные ядра; математический алгоритм остаётся линейным.

Вопрос 14. Контекстуальные эмбеддинги или нет?

Строки входных данных являются без контекста. Контекст формируется за счёт внимания между слоями. Эмбеддинги, получаемые при поиске, обычно представляют собой более глубокие состояния, а не строки входной таблицы.

Вопрос 15. Связывание весов

Для экономии параметров веса эмбеддингов делятся с головой LM (производится транспонирование) — это распространённый подход в более мелких моделях. В крупных LM часто отказываются от такого связывания ради лучшего качества. Связанные головы не представляют собой дополнительную независимую матрицу d × V.

Вопрос 16. Информация о позиции

Абсолютные эмбеддинги добавляют векторы для каждого индекса. RoPE поворачивает значения Q/K, так что относительные смещения отражаются в оценках и способствуют кэшированию KV-пар. Альтернативами являются схемы относительных смещений; RoPE доминирует в новых LLM.

Вопрос 17. RoPE и расширение для длинных контекстов

Относительная геометрия RoPE позволяет делать более точные прогнозы, чем примитивные абсолютные таблицы. Расширения (интерполяция положений, масштабирование с учётом NTK, YaRN и т. д.) пересчитывают частоты вращения, что обеспечивает стабильность при работе с более длинными контекстами без необходимости повторной обучающей выборки.

Вопрос 18. Коэффициент √d_model

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

Часть 4 — Блок трансформера

Вопросы 19–23. Механизм внимания (расширенно)

x → MultiHeadSelfAttention → Add & Norm → FFN → Add & Norm → out

Attention(Q, K, V) = softmax(QKᵀ / √d_k) V

Запросы ищут, ключи объявляют, значения доставляют. Функция Softmax над масштабированными значениями формирует веса смешивания. Результат делится на √d_k, чтобы оценки не достигали предела по мере увеличения ширины. Множество голов обеспечивает разнообразие подпространств. Причинные маски записывают значение −∞ в запрещенные будущие состояния, так что сумма значений Softmax становится ровно нулевой — однако нули в маске все равно могут проникать. Во время чистой декодировки с использованием кэша набор ключей не содержит позиций будущего, поэтому маска является имплицитной; тем не менее для предзаполнения все равно требуется маскировка (или причинный ядро).

Q24–Q26. Формы, стоимость, остатки

Каждая проекция имеет размер примерно d × d (с изменениями в рамках GQA). FFN занимают большую долю параметров благодаря увеличению размерности примерно в 4 раза. Затраты на обработку внимания растут по закону O(n² d), тогда как для FFN — по закону O(n d²). Для коротких промптов важны ограничения на веса и FFN; при длинных контекстах доминируют механизмы внимания и память типа KV. Остаточные вычисления позволяют обучать сложные структуры, создавая «шоссе для градиентов» и добавляя дополнительные корректировки.

Q27–Q30. Нормирование, ширина FFN, активации, MoE

RMSNorm не включает этап центрирования по среднему значению и дешевле LayerNorm. Предварительное нормирование обеспечивает стабильность очень глубоких сетей по сравнению с классическим последовательным нормированием. Широкие FFN (примерно в 4 раза) повышают емкость обработки токенов между модулями смешивания внимания. Нелинейные функции предотвращают коллапс стеков линейных слоев; SwiGLU показал хорошие результаты во многих экспериментах с LLM. MoE направляет токены к нескольким экспертным FFN, что позволяет параметрам расти быстрее, чем количество FLOPs на токен — это метод с высокой нагрузкой на память и низкой нагрузкой на вычисления.

Q31–Q32. Глубина/ширина и варианты механизмов внимания

Глубина способствует повторному смешиванию данных; ширина обогащает их характеристики. Лаборатории выбирают подходы в зависимости от объема данных и ограничений кластеров. MHA хранит значения K/V для каждого элемента; MQA использует одни и те же значения K/V для всех запросов; GQA делятся ими внутри группы; MLA дополнительно сжимает эти значения K/V. Рост затрат на обслуживание стимулировал развитие индустрии в этом направлении.

Часть 5 — Кэш KV

Вопрос 33. Что такое кэш KV, и почему только K и V?

На этапе декодирования t поступает новый токен. Его запрос q_t должен учитывать ключи и значения для позиций 1..t. Ключи и значения для 1..t−1 зависят только от предыдущих токенов и фиксированных весов. Принцип причинности гарантирует, что появление токена t не может изменить уже существующие тензоры K/V — они являются неизменяемыми, — поэтому они вычисляются один раз и сохраняются.

Запросы различаются: для текущего шага вам нужен только q_t. Более старые запросы уже дали более старые результаты и больше никогда не будут прочитаны, поэтому кеширование Q — это расточительство памяти.

Без кэша генерация токена t потребует перезапуска всего префикса — работы, которая резко увеличивается с длиной. С кэшем внимание на каждом шаге является линейным от текущей длины, а FFN фактически выполняет постоянное количество операций на каждый новый токен. Генерация становится линейной от количества шагов декодирования вместо квадратичной от количества проходов.

Q34. Определите размер кэша KV с использованием реального числа

KV bytes = 2 (K and V)
         × n_layers
         × n_kv_heads × d_head
         × seq_len
         × batch_size
         × bytes_per_element

Используем структуру GQA класса Llama-3–70B: восемьдесят слоев, восемь голов ключей/значений, по сто двадцать восемь измерений на каждую голову, хранящихся в двухбайтовых числах с плавающей точкой.

Умножьте эти факторы: два тензора (K и V) × восемьдесят × восемь × двадцать восемь одной десятой × два байта дают примерно 320 КБ на каждый токен каждой динамической последовательности.

Если рассматривать диалог из 8 тысяч токенов, объем данных составит около 2,6 ГБ на одного пользователя. При контексте в 128 тысяч токенов по той же формуле получается несколько десятков ГБ — этого достаточно, чтобы один разговор занял значительную часть устройства класса H100 еще до учета весов модели.

Сценарий без GQA (64 головы KV): показатель для 8 тысяч токенов возрастает до примерно ~21 ГБ на последовательность. GQA определяет разницу между десятками одновременных пользователей и всего несколькими.

Веса представляют собой фиксированную плату, уплачиваемую один раз. Кэш KV — это нес ограниченная плата за каждого пользователя и каждый токен. Он определяет максимальный размер пакета, что в свою очередь влияет на пропускную способность и, как следствие, на стоимость обработки миллиона токенов. Именно поэтому в диаграммах его обозначают как основное ограничение памяти.

Вопрос 35. Почему декодирование ограничено объёмом памяти — арифметика

Рассмотрим модель размером 70 млрд параметров в формате fp16, обрабатывающую один токен за раз:

• Объём данных: ~140 ГБ весов плюс несколько ГБ кэша KV ≈ 142 ГБ.
• Количество операций FLOP: ≈ 2 × 70e9 × 1 = 140 GFLOPs.
• Интенсивность: ≈ 1 FLOP/байт.

Видеокарта H100 обеспечивает пропускную способность памяти HBM около 3,35 ТБ/с и производительность в формате fp16 около 1000 TFLOPs. Точка, в которой вычислительная мощность уступает пропускной способности памяти, наступает при значении нескольких сотен FLOP/байт. При интенсивности 1 FLOP/байт используется лишь крошечная доля максимальных вычислительных ресурсов — видеокарта в основном выполняет функцию переноса данных между памятью и процессором.

Время обработки ≈ 142 ГБ / 3,35 ТБ/с ≈ 42 мс → примерно 24 токена/с только за счёт пропускной способности. В реальных системах показатели находятся в пределах двукратного диапазона от этой оценки, что свидетельствует о сильном влиянии правил, связанных с пропускной способностью.

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

Вопрос 36. Если группировка в пакеты «бесплатна», почему не использовать пакеты размером 512?

Потому что каждая последовательность занимает своё пространство в памяти KV, а объём кэш-памяти растёт пропорционально размер пакета × длина последовательности:

GPU memory = model weights + KV cache + activations + fragmentation overhead

Пример: 140 ГБ весов на двух устройствах H100 (по 160 ГБ) оставляет примерно 20 ГБ для кэша. При пропускной способности 320 КБ/токен это даёт примерно 65 тыс. токенов в целом для пакета. Шестнадцать пользователей с контекстом размером 4 КБ уже исчерпывают этот лимит.

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

Вопрос 37. PagedAttention и проблема фрагментации

Примитивные серверы выделяют по каждому запросу непрерывный блок памяти KV длиной до max_seq_len. Этот подход имеет два недостатка:

• Внутренняя фрагментация — при обработке текста длиной 100 токенов, требующего 4096 слотов, большая часть выделенной памяти остается неиспользованной.
• Внешняя фрагментация — освобождаемые участки памяти разного размера оставляют «дыры», в которые невозможно разместить новые блоки.

Уровень неэффективности использования памяти в примитивных механизмах выделения часто составляет 60–80% от общего объема памяти KV.

PagedAttention (популяризированный vLLM) воспроизводит концепцию виртуальной памяти ОС: блоки фиксированного размера (например, 16 токенов) вместе с таблицей блоков, которая соотносит логические позиции с физическими блоками в любой части пула. По мере увеличения длины генерации выделяются новые блоки.

Преимущества:

• Снижается фрагментация → на одних и тех же GPU можно обрабатывать в 2–4 раза больше одновременных последовательностей.
• Общее использование префикса / копирование при записи — множество запросов с одним системным промптом делят физические блоки до тех пор, пока их суффиксы не станут разными; это идеально подходит для агентов, инструкций RAG и задач с небольшим количеством примеров.
• Лучи и параллельные образцы делят общий префикс вместо того, чтобы копировать его.

Ценой являются косвенные операции и ядро внимания, которое собирает данные из неконтигуентных блоков.

Вопрос 38. Статическое vs непрерывное группирование

Статическое группирование ждет, пока заполнится группа запросов, выполняет все последовательности одновременно с учетом самой длинной из них, и дополняет ее недостающими данными. Короткие запросы ждут длинных; GPU тратит ресурсы на обработку этих дополнительных данных.

Непрерывное (итерационное) группирование пересоздает группу запросов на каждом шаге декодирования: завершенные последовательности удаляются, появляются новые, и GPU работает только с актуальными данными. Разброс задержек снижается, а производительность значительно растет — это стандарт современных движков (vLLM, TensorRT-LLM и т. д.).

Вопрос 39. Предзаполнение по чанкам и разделение этапов предзаполнения и декодирования

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

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

Вопрос 40. Сокращение объёма KV за пределами GQA

Среди способов оптимизации:

• MQA / GQA / MLA — использование меньшего количества или сжатых структур KV.
• Квантизированные кэши (в стиле INT8/FP8/NF4) — обеспечивают практически безубыточную передачу данных K/V.
• Оконная/скользящая атеншн — исключение менее важных токенов, если задача это позволяет.
• Политики вытеснения/стриминга для экстремальных сценариев.
• Межуровневое повторное использование — идеи для совместного использования результатов обработки на разных уровнях.

Каждый из этих методов жертвует некоторым уровнем качества или универсальности ради значительной экономии памяти.

Вопрос 41. Кэширование префиксов — при изменении архитектуры

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

Q42. Когда кэш пар ключ-значение становится недействительным?

В любой момент, когда предыдущие токены изменяются, а не просто дополняются: при регенерации в ходе разговора, переписывании системного сообщения, замене определений инструментов или применении некаузальных изменений. Кэши префиксов должны формироваться на основе точной идентичности токенов (и версии шаблона). Параметры выборки не делают пары ключ-значение недействительными — они лишь влияют на то, как логиты преобразуются в следующий идентификатор — но изменение адаптера модели, промежуточной версии модели или масштаба RoPE в процессе работы может это сделать.

Часть 6 — голова LM (линейная + softmax)

Вопрос 43. Что делает голова LM и каковы её формы

Последний блок генерирует вектор h ∈ ℝ^(seq_len × d_model). После финальной нормализации один линейный преобразователь вычисляет логиты словаря:

logits = h @ W_lm      W_lm ∈ ℝ^(d_model × V)

При d_model = 4096 и V = 128,000 параметры W_lm составляют 524 млн, и для каждой обрабатываемой позиции формируется вектор шириной 128K.

Вопрос 44. Есть ли логиты для каждой позиции во время декодирования?

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

Вопрос 45. Стоимость работы головы LM при декодировании

Каждый шаг умножает вектор d на d × V — это требует примерно 2 × d × V операций типа FLOP, а также полного считывания потенциально несвязанной головы. При больших значениях V это сопоставимо с работой фрагмента FFN, что становится основанием для использования адаптивного softmax, параллельного разделения словаря и связанных эмбеддингов, когда это допустимо.

Вопрос 46. Логиты против вероятностей

Логиты — это неограниченные оценки. Softmax нормализует их:

p_i = exp(z_i) / Σⱼ exp(z_j)

Помните о инвариантности к сдвигу: добавление константы ко всем логитам не меняет вероятностей — это основа стабильных реализаций и использования параметра температуры для масштабирования разниц.

Вопрос 47. Численно стабильный softmax

Примитивная формула exp(z_i) приводит к переполнению в формате fp16 при умеренных значениях логитов, а также может привести к затоплению всей строки нулями, что создает ситуацию 0/0. Для решения этой проблемы сначала вычитается максимальное значение в строке:

p_i = exp(z_i − max(z)) / Σⱼ exp(z_j − max(z))

Самый большой член равен exp(0) = 1; остальные находятся в диапазоне (0, 1]. Онлайн-алгоритмы (как, например, FlashAttention) сочетают это с операцией matmul, чтобы избежать создания огромных матриц оценок.

Вопрос 48. Перплекситет

Перплекситет представляет собой значение exp(среднее отрицательное лог-вероятность) для всех токенов — это показатель степени «удивления» модели. Он вычисляется на той же стадии, что и логиты/softmax. Низкий перплекситет в определённой области свидетельствует о лучшей настройке модели для выбора следующего токена, но это не является прямым показателем полезности или безопасности.

Часть 7 — Стратегии выборки

После блока LM у вас есть вектор логитов. Выборка — это процесс преобразования этого вектора в следующий идентификатор.

Вопрос 49. Жадное декодирование — и почему оно разочаровывает

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

Q50. Почему не использовать поиск лучших векторов?

Поиск лучших векторов сохраняет B лучших промежуточных гипотез. Он полезен, когда цель короткая и ограничена (например, при переводе). Для открытых диалогов он обычно генерирует универсальный, безопасный с точки зрения вероятности текст, требует B× вычислительных ресурсов и плохо совмещается с методами диверсификации вроде nucleus. Большинство приложений на основе больших языковых моделей отказались от него в пользу методов выборки.

Q51. Top-k

Сохраняются только k крупнейших логитов, затем производится ренормализация и выборка. Это просто, но параметр k имеет серьезный недостаток: иногда вероятности, находящиеся вне диапазона топ-к, всё равно имеют значение; кроме того, при остром распределении топ-k может включать бесполезные значения. Фиксированное значение k не может адаптироваться к степени остроты распределения.

Q52. Top-p (ядро)

Распоряжение элементов по вероятности, сохранение минимального набора, суммарная масса вероятностей которого ≥ p, после чего производится выборка. Когда модель уверена в своем ответе, ядро сужается; при неуверенности — расширяется. Именно эта способность к адаптации привела к тому, что top-p заменил фиксированный параметр top-k в качестве стандарта во многих решениях. Типичное значение p находится в диапазоне от 0,9 до 0,95 и подбирается индивидуально для каждого продукта.

Q53. Температура — математика и интуиция

p_i = exp(z_i / T) / Σⱼ exp(z_j / T)

Логиты делятся на T перед применением функции softmax.

• T → 0 — разрывы между вероятностями становятся огромными; распределение сужается до значения argmax (жадный алгоритм).
• T = 1 — распределение модели без масштабирования.

T > 1 — упрощение структуры; больше неожиданностей и риска некоherентности.

В реализации температура сама по себе не «добавляет случайности» — она просто изменяет распределение, из которого берется выборка.

Q54. Порядок применения: температура против обрезки

Сначала применяется температура к логитам, затем выполняется выборка top-k / top-p из полученного распределения (или, что эквивалентно, обрезка вероятностей после применения температуры). Обрезка до применения температуры влияет на то, какие значения останутся, и обычно приводит к неправильному результату. Укажите в документации порядок применения на вашем сервере; скрытые замены могут изменить поведение системы.

Q55. Штрафы за повторение, частоту и наличие токенов

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

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

Вопрос 56. За пределами top-p

Пороги Min-p, связанные с наивысшей вероятностью (p_i ≥ min_p × p_max), показывают лучшую эффективность при высокой температуре и размытых распределениях вероятностей. Mirostat и подобные контроллеры нацелены на уровень неожиданности. В типовой практике производства по-прежнему преобладают параметры температура + top-p, хотя доля использования min-p увеличивается.

Вопрос 57. Почему при температуре 0 всё равно происходят изменения?

Даже «жадные» алгоритмы различаются по следующим причинам:

• Недетерминистические процессы на GPU и объединённые ядра.
• Разные схемы группировки данных / непрерывной обработки.
• Спекулятивные пути выполнения и численно различные реализации функции softmax.
• Стандартные наказания, строки остановки и шаблоны с серверной стороны.

Шум маршрутизации MoE при его включении.

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

Вопрос 58. Принудительное использование JSON или схемы

Варианты решения:

1. Принудительное использование JSON (чувствителен к ошибкам).
2. Ограниченная декодировка / маски грамматики — полное игнорирование недопустимых токенов на каждом этапе (регулярные выражения, схемы JSON, CFG).
3. Использование API инструментов/функций, которые анализируют сторонние каналы вместо свободного текста.
4. Последующая коррекция (как крайняя мера).

Ограниченная декодировка является надежным решением для систем, где обязательна проверка корректности данных.

Вопрос 59. Оценка настроек выборки

Закрепите модель и протестируйте параметры температуры/топ-п на наборе с метками: успех выполнения задачи, токсичность, разнообразие (distinct-n), частота повторений, задержка. Предпочтительнее офлайн-оценка в сочетании с онлайн-тестированием типа A/B с четкими метриками продукта. Не настраивайте модель на основе одного отобранного специально примера запроса.

Часть 8 — Спекулятивное декодирование

Вопрос 60. Основная идея

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

Вопрос 61. Почему распределение результатов не меняется

Процесс принятия использует соотношения между целевым значением p и предварительным вариантом q, так что принятые токены вместе с остаточным резамплингом воссоздают точно значение p:

P(emit x) = q(x)·min(1, p(x)/q(x)) + P(reject)·p'(x)

Принятый путь вносит вклад в размере min(q,p); остаточный резамплинг заполняет разницу max(0, p−q). Сумма этих значений дает p. Следовательно, спекулятивная декодировка является безубыточной по сравнению с обычным целевым резамплингом — это ускорение работы системы, а не приближение к модели.

Q62. Ожидаемое ускорение

При скорости принятия α и длине предварительного варианта k ожидаемое количество токенов на один целевой шаг составляет:

E[tokens] = (1 − α^(k+1)) / (1 − α)

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

speedup ≈ E[tokens] / (1 + k·c)

Пример: α=0.8, k=4 → ожидаемое количество токенов ~3.36; при c=0.05 → примерно 2.8×. Результаты, публикуемые как успешные, обычно находятся в диапазоне 2–3×. При больших значениях k эффективность снижается, поскольку вероятность выживания уменьшается пропорционально α^k.

Вопрос 63. Когда спекуляции вредны

Низкая степень принятия (сложные запросы, смена области применения, слабый черновик), чрезмерно высокая стоимость создания черновика или ядра, неспособные эффективно выполнять проверки параллельно. В таких случаях дополнительные затраты превышают получаемую выгоду — необходимо использовать пороговое значение α.

Вопрос 64. Кэш KV при отклонении

Хранение записей кэша целей отката (и черновиков) для отклоненных вариантов. Реализации должны устанавливать длину точек контроля и обрезать данные; ошибки в этой части могут повредить будущую обработку информации. Принятые токены сохраняют свои значения K/V.

Вопрос 65. Современные варианты

Medusa / многоголовые генераторы вариантов, генераторы на уровне признаков в стиле орла, генерация вариантов на основе поиска по промпту/н-грамм из самого контекста и каскадные генераторы. Тот же принцип проверки с использованием целевого значения.

Вопрос 66. Внимание к дереву

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

Часть 9 — Детокенизатор и потоковая обработка

Вопрос 67. Детокенизация — это не просто обратная карта

Детокенизаторы должны удалять маркеры пробелов, обрабатывать ситуации с заменой байтов, объединять несколько токенов в один графему и избегать вывода неполных данных формата UTF-8. При потоковой детокенизации данные накапливаются в буфере до тех пор, пока не станет безопасно вывести полный символ/фрагмент — в противном случае клиенты увидят заменяющие символы.

Вопрос 68. Как работает потоковая обработка и что измерять

Серверы генерируют токены (или их части) по мере создания. Необходимо измерять TTFT, TPOT и время до появления первого читаемого символа после детокенизации и буферизации. Для пользовательского интерфейса клиента важнее именно это последнее значение, чем сырые временные метки токенов.

Вопрос 69. Последовательности остановки генерации сложны в обработке

Последовательности остановки могут пересекать границы токенов (\n\n против одного токена, содержащего обе переносные строки). Необходимо проверять декодированный текст (или тщательно отобранное окно токенов), а не только совпадение идентификаторов. При перекрытии с частично сгенерированными последовательностями остановки требуется откат, чтобы текст остановки не отображался.

Вопрос 70. Что прерывает процесс генерации?

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

Часть 10 — FlashAttention, квантизация, roofline

Вопрос 71. FlashAttention — точные утверждения

FlashAttention вычисляет внимание без необходимости формирования полной матрицы оценок размером n × n в памяти HBM, используя тайлинг и статистику softmax в реальном времени. Это снижает нагрузку на память и позволяет обрабатывать более длинные последовательности/большие пакеты данных. Он не меняет математического результата вычисления внимания (за исключением числовых ошибок); это алгоритм, учитывающий особенности ввода-вывода, а не другая модель.

В72. Помогает ли он при декодировании?

При декодировании с использованием кэша внимание часто направляется на ключи из кэша размером n с длиной векторов q, равной 1 — тем самым уменьшается преимущество классического FlashAttention (огромные квадратные значения оценок). Варианты этого алгоритма (FlashDecoding и т. д.) всё ещё способствуют оптимизации пропускной способности каналов передачи данных KV, но декодирование по-прежнему в значительной степени зависит от нагрузки на веса, если только пакет данных не является очень большим.

В73. Квантизация

Хранение/обработка весов (а иногда и активаций/KV) осуществляется в более компактных форматах (FP8, INT8, INT4 и т. д.). Память и пропускная способность снижаются примерно пропорционально ширине бита; степень потери качества зависит от метода (GPTQ, AWQ, плавная квантовка и т. д.). По опыту: 8-битная квантовка обычно практически бесплатна с точки зрения ресурсов; 4-битная квантовка требует некоторых затрат, иногда эти затраты сопоставимы с фоновым шумом — всегда тестируйте на своих задачах.

Вопрос 74. Особенности работы модели в одном абзаце

Постройте график зависимости достижимого количества операций FLOP от уровня арифметической интенсивности. Режим предзаполнения находится ближе к «потолку вычислительных мощностей»; декодирование в режиме одной группы данных находится ближе к «потолку пропускной способности» при примерно 1 FLOP на байт. Оптимизации, повышающие интенсивность (группировка операций, уменьшение количества битов при выполнении одной полезной операции FLOP), перемещают систему ближе к этому «потолку»; чистое ускорение ядра не может превзойти существующие ограничения.

Вопрос 75. Разделение крупной модели между GPU

Параллельность тензоров предполагает разделение слоев на части (требуется быстрая взаимосвязь между ними). Параллельность по трубопроводу распределяет диапазоны слоев между узлами (существует риск возникновения «пузырей»). Параллельность экспертов включает разделение экспертов MoE на части. Параллельность реплик/данных заключается в копировании модели для повышения пропускной способности. В реальных развертываниях используется комбинация этих подходов; KV-данные должны быть разделены или скопированы согласованно с структурой внимания.

Часть 11 — Цифры с доски

• Веса 70B в формате fp16: 70e9 × 2 ≈ 140 ГБ.
• Количество операций FLOPs при передаче данных: ~2 × параметры × токены (приблизительно).
• KV на токен (Llama-3-70B-class GQA): ~два · количество слоев · количество голов KV · размер головы · количество байт типа данных, примерно треть мегабайта на токен.

Частота декодирования в пакете 1: ~пропускная способность / weight_bytes (у современных процессоров класса H100: десятки tok/s в формате fp16 до появления более эффективных методов).

Эмбеддинги + отдельная голова LM при V=128K, d=4096: по ~524 млн параметров каждый.

Параметры механизма внимания против FFN: в стандартном блоке пропорция примерно 1:2 (4d² против ~8d²).

Часть 12 — Ограничения диаграмм

В распространённых учебных диаграммах обычно не показано: шаблоны чата до токенизации, влияние GQA/MQA на ширину KV-элементов, детали порядка выборки, буферизация при детокенизации, разделение KV-элементов на страницы и циклы спекулятивной проверки. Рассматривайте диаграммы как схемы, а не строгие инструкции.

Заключение

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

Подробный анализ A — Экономика предварительного заполнения данных и декодирования на практике

При определении размера флота GPU начните с разделения по уровню крыши здания. Задачи с длинными вводными данными хорошо работают с тензорными ядрами: длинные запросы в режиме кодовой помощи или при обработке данных RAG могут показать высокий уровень использования MFU, если ядра работают эффективно. Результаты декодирования в первой партии напоминают случайные тесты на объем памяти — одни и те же веса размером 70 миллиардов проходят через HBM для выполнения одной операции GEMV. Именно поэтому продукт, выдающий ответы длиной 500 токенов, кажется медленным даже на флагманских GPU, если не использовать группировку задач, квантизацию или другие техники оптимизации.

Регрессии в показателях TTFT обычно свидетельствуют о увеличении длины вводных данных (история запросов, данные RAG, схемы инструментов) без кэширования префиксов. Регрессии в показателях TPOT обычно означают срыв группировки задач, снижение пропускной способности или необходимость использования очень маленьких групп задач из-за высокой нагрузки на структуры KV. Время обработки от начала до конца — это не единый параметр: сокращение длины ответов улучшает показатели TPOT в N раз; кэширование вводных данных помогает при проблемах TTFT; спекулятивное декодирование улучшает показатели TPOT при высокой вероятности принятия ответа.

Показатели пропускной способности, отображаемые на панелях управления, легко подделать с использованием огромных пакетов данных, из-за чего страдают интерактивные пользователи. Необходимо публиковать как количество токенов в секунду на одну GPU, так и значения p50/p95 TPOT при реалистичном сочетании нагрузок. Непрерывная обработка данных позволяет постоянно подпитывать GPU без избыточных затрат, связанных с статическими пакетами; разбивка данных на части предотвращает замедление процесса декодирования из-за одного большого запроса объемом 32 КБ.

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

Подробный обзор B — Токенизатор и затраты на мультиязычную обработку

Универсальность BPE на уровне байтов — это одновременно преимущество и недостаток. Приложения для чата на английском языке недооценивают затраты на обработку текста на хинди, тайском или в социальных сетях, где много эмодзи. Если ваша модель расчетов исходит из количества токенов на секунду для английского языка, многоязычное расширение может тайно исчерпать бюджет. В случаях, когда важен такой трафик, предпочитайте токенизаторы с более широким многоязычным охватом; измеряйте количество токенов на кластер графем в реальных корпусах текстов, а не в примерном тексте lorem ipsum.

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

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

Подробный обзор C — внимание, GQA и память

Механизм многоголового внимания представляет собой специализацию в рамках определенных ограничений. Механизм GQA связан с объемом данных KV-элементов. Переход от многоголового внимания к GQA может сократить размер кэша примерно в соотношении количества голов запросов к числу групп KV-элементов — часто в 4–8 раз — при незначительной потере качества при обучении. MQA является крайним вариантом; MLA и другие методы сжатия преследуют ту же цель, но с использованием других алгоритмов.

Использование отрицательного бесконечности для маскирования причинно-следственных связей — это не педантизм: любое конечное значение маски приводит к утечкам информации. Ошибки в процессе обучения, которые случайно позволяют учитывать будущие данные, приводят к созданию моделей, которые хорошо справляются с метриками, заданными в процессе обучения, но терпят неудачу при реальном авторегрессивном использовании. Ядра, используемые во время декодирования и предполагающие определенную структуру кэша, должны соответствовать параметрам обучения (количество голов, основа RoPE, масштабирование).

Именно из-за остаточных значений и предварительной нормализации стеки из 80–100 слоев стали обычным явлением. Когда пользовательская архитектура устраняет их «для упрощения», следует ожидать нестабильности в процессе обучения, а не каких-либо преимуществ. Механизм управления SwiGLU является параметром качества, влияющим на использование памяти — необходимо знать, объединяет ли ваша архитектура его с другими компонентами.

Углубленный анализ D — стратегия пагинации KV и префиксов

Механизм PagedAttention рассматривает данные KV как набор блоков. Последствия этого:

• В фреймворках агентов с большим количеством общих системных промптов следует стандартизировать эти префиксы, чтобы хэши блоков совпадали.

Библиотеки для работы с небольшим количеством примеров должны сохранять их в стабильном порядке; перетасовка приводит к снижению количества успешных обращений к кэшу.

Поля для персонализации должны находиться после общей основы.

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

Аннулирование кэша с помощью префиксов — это проблема корректности, а не только производительности. Если схема инструмента меняется, но ключ кэша это игнорирует, модель будет использовать устаревшие данные KV для новых инструкций — это тонкие, но серьезные сбои. Включайте в ключ идентификатор токенизатора, хеш шаблона, ID LoRA и масштаб RoPE.

Для устранения проблем при нехватке памяти требуется четкая политика: использование алгоритма LRU для неактивных разговоров, установление жестких лимитов на объем контекста или сжатие через создание кратких сводок. Как бы вы ни выбрали подход, он должен быть отражен в продукте — тихое обрезание данных является проблемой доверия.

Подробный обзор E — Softmax, выборка и детерминизм

В режимах fp16/bf16 использование стабильной функции softmax является обязательным. Слиянные ядра скрывают операцию max-subtract, но пользовательский исследовательский код по-прежнему может столкнуться с проблемой переполнения. Показатель перплекситета остается полезным индикатором при изменении ядер или схем квантования: резкие скачки означают изменение распределения.

Состав процесса выборки должен проходить тестирование на единицах: сначала температура, затем обрезка данных, затем штрафы и только после этого выборка. Измените порядок операций в тестовом фикстчере, и вы увидите, как изменятся эталонные результаты. Декодирование JSON с ограничениями должно проходить нагрузочное тестирование; генерация масок может стать проблемой для CPU при наивной реализации.

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

Подробный обзор F — Операции спекулятивного декодирования

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

Спекуляции в виде деревьев полезны, когда черновик может недорого предложить альтернативы. Тесты корректности отката KV-записей должны выполняться в рамках CI: необходимо целенаправленно отклонять результаты в процессе выполнения и проверять, соответствуют ли последующие операции базовому варианту без спекуляций.

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

Углублённый анализ G — потоковой UX и точки остановки

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

Углубленный разбор H — FlashAttention и квантизация при обслуживании

FlashAttention позволяет использовать более длинные предзаполнения и более плотные пакеты данных за счёт экономии памяти типа HBM. Стоит отметить, что это не меняет саму логику декодирования. Квантизация служит инструментом для ускорения декодирования: меньшее количество байт на каждый вес увеличивает эффективное количество обрабатываемых токенов в секунду. Перед тем как утверждать, что 4-битная квантизация доступна без ограничений, протестируйте её на своей сборке тестов — особенно с учётом вызовов инструментов и воспроизведения длинных контекстов.

Логика расчёта параметров крыши гарантирует честность аргументов: если у вас ограниченная пропускная способность, покупка большего количества TFLOPS без увеличения пропускной способности (или сокращения объёма данных) приводит к разочарованию. Если же ограничением является вычислительная мощность при предзаполнении данных, более эффективные алгоритмы GEMM и планирование обработки данных имеют большее значение, чем сокращение размера структуры KV.

Углублённый анализ I — Реалии использования нескольких GPU

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

Углублённый анализ J — Сборка конвейера обработки

Путь обработки запроса, который стоит запомнить:

1. Создание шаблона и токенизация на CPU
2. Вставка данных и предзаполнение с использованием каузального внимания, запись данных в структуру KV (GPU, ограничение вычислительной мощности)

Голова LM в последнем положении, затем выборка (GPU с политикой CPU)

Цикл декодирования с кэшем, непрерывная группировка данных, необязательное спекулирование (GPU, ограничение по пропускной способности)

Детокенизация, проверки остановки, обработка потока на CPU

Освобождение или использование блоков KV в аллоциаторе

Каждая оптимизация соответствует одной стрелке в этом списке. Если вы не можете указать на соответствующую стрелку, значит вы ещё не анализируете процесс инференса — вы просто собираете информацию.

Дополнительные пояснения в стиле FAQ

Увеличивает ли температуру креативность в измеримой степени? Она увеличивает энтропию распределения следующего токена. То, назовут ли люди результат креативным, зависит от задачи; измеряйте это с помощью показателей разнообразия и качества, а не только субъективных ощущений.

Бывает ли жадность правильной? Да — при методе классификации как генерации, структурированном извлечении с ограниченным декодированием и некоторых инструментах оценки. В открытом диалоге обычно так не бывает.

Можно ли удалить кэш KV и пересчитать данные? Всегда, но с квадратичными затратами. Устройства на периферии иногда работают с короткими окнами времени без кэша; серверы почти никогда не должны этого делать.

Почему на диаграммах показан функция softmax внутри механизма внимания и снова у головы языковой модели? Это разные варианты функции softmax: один смешивает значения внутри слоя; другой преобразует логиты словаря в категориальное распределение для выборки. Одна семья функций, разные задачи.

Что должен сначала запомнить новый инженер? Проблемы, связанные с предзаполнением и декодированием, формулу количества байт KV на токен, понятия TTFT и TPOT, а также то, что батчинг обменивает задержку на пропускную способность. Все остальное зависит от этих четырех аспектов.

Подробный обзор — ядра предзаполнения и механизмы TTFT

Качество предварительной загрузки сервиса в основном определяется скоростью преобразования запроса в готовый к использованию KV-кэш. Ядра внимания, объединенные пути MLP и способ разбиения запроса на части влияют на форму кривой TTFT. Если запросы имеют общую часть текста, кэширование префиксов превращает повторные операции предварительной загрузки в быстрые поисковые запросы; в противном случае каждая новая сессия требует полной стоимости обработки.

Разбиение запросов на части служит не только средством снижения задержек, но и инструментом обеспечения справедливости. Без него одна операция обработки 40 тысяч токенов может заблокировать декодирование для всех остальных задач на GPU. С его использованием интерактивные потоки продолжают работать, пока длительная задача выполняется поэтапно. Компромисс заключается в незначительном увеличении значения TTFT для самой длительной задачи — что обычно является приемлемым.

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

Подробное руководство — Объяснение математики использования пропускной способности словами

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

Когда кто-то утверждает, что ядро работает в 2 раза быстрее при декодировании, спросите, под каким «небом» он находился. Если производительность ограничена пропускной способностью, чистая оптимизация ALU не сможет дать удвоение скорости. Если при этом сокращается количество передаваемых байт, поверьте ему после скриншота от профилятора.

Подробный обзор — Политики обслуживания и SLO

Необходимо отдельно задавать показатели SLO для TTFT и TPOT. Релиз, улучшающий пропускную способность при одновременном удвоении п95 TPOT, считается регрессией для пользовательского интерфейса чата, даже если панель управления мощностью это отмечает как успех. Параметры непрерывной группировки (максимальное количество токенов в группе, максимальная длина очереди ожидания, приоритет декодирования по сравнению с предзаполнением блоков) являются практическими регуляторами, контролирующими соблюдение этих SLO.

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

Подробный обзор — Чек-лист операций токенизатора

Перед публикацией модели:

1. Зафиксируйте файлы токенизатора и текст шаблона чата в том же хранилище артефактов, что и веса модели.
2. Протестируйте несколько многоязычных строк и эмодзи с использованием метода «золотого теста», чтобы выявить неожиданные изменения длины токенов.
3. Протестируйте строки, содержащие много цифр, если продукт выполняет математические операции.
4. Убедитесь, что идентификаторы токенов остановки совпадают с маркерами конца в шаблоне.
5. Убедитесь, что инструменты для расчёта logprob используют тот же токенизатор, что и процесс инференса.

Если вы пропустите хотя бы один из этих шагов, при диагностике «качества модели» на самом деле будет речь о смещении её параметров при пакетировании.

Подробное руководство — варианты механизма Attention в виде временной шкалы

Ранние нейронные сети использовали полные структуры MHA и оплачивали их за счет кэша. Давление производственных задач привело к появлению MQA, а затем GQA в качестве компромисса, который приняли большинство передовых систем. Идеи MLA и связанные с ними структуры с низким рангом KV продолжают ту же линию: сохранять богатство запросов, сокращая объем хранимых данных на каждый прошлый токен. Читая научную статью, следует переводить утверждения на язык «байтов на токен KV» и «изменения качества по результатам оценки» — маркетинговые термины вроде «эффективного внимания» в противном случае бессмысленны.

Подробный обзор — структуры KV с разделением на страницы и поведение в многоклиентных средах

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

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

Подробное руководство — Отбор примеров для продуктов

Стандартные настройки доставки, соответствующие заданию:

• Параметры извлечения/инструментов: низкая температура, ограниченное декодирование, алгоритм «жадного» выбора или использование маленького ядра.
• Чат-поддержка: умеренная температура, ядро в районе значения 0.9, небольшое наказание за повторения при наличии циклов.
• Творческое мозговой штурм: более высокая температура, учет параметра min-p, более явные предупреждения для пользователя о вариативности результата.

Для заявок на поддержку необходимо фиксировать информацию о выбранном примере вместе с каждым ответом. Без этой информации невозможно ответить на вопросы вроде «Вчера модель сказала X».

Подробное руководство — Внедрение спекулятивного декодирования

Разверните решение за флагом. Оценивайте уровень принятия по конечным точкам. Отключите его, когда значение α станет ниже точки безубыточности, рассчитанной на основе предварительной стоимости c и длины данных k. Всегда сохраняйте небольшой фрагмент трафика для тестирования — это ваш эталон качества.

Убедитесь, что пути отклонения удаляют данные из KV-хранилища. Добавьте тест на хаос, который вызывает отклонения в процессе обработки при высокой нагрузке.

Подробное руководство — детали протокола стриминга

Решите, будет ли формат передачи данных включать токены, детокенизированные строки или и то, и другое. Клиенты, выполняющие детокенизацию по-разному, могут не согласовать границы данных. Лучше использовать детокенизацию на стороне сервера с явными событиями “flush” при готовности полного кластера графем. Опишите, как удаляются последовательности остановки, чтобы код интерфейса не обрабатывал их дважды.

Подробное руководство — тесты на принятие квантованных данных

Прежде чем внедрять 4-битные веса в производство:

• Запустите стандартный набор тестов eval.
• Запустите фикстуры для вызова инструментов.
• Запустите тесты на длинные контексты.
• При необходимости сравните результаты тестов на отклонения и безопасность.
• Сравните показатели p95 TPOT и использование VRAM.

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

Подробное руководство — Ответы на задания в формате прозы

Память, необходимая для хранения чекпоинта с семьюдесятью миллиардами параметров в формате fp16, составляет примерно сто сорок гигабайт только для весов. Вычисления на этапе передачи данных требуют примерно двух операций FLOP на параметр и токен. Рост объема данных KV пропорционален количеству активных токенов и числу голов ключ/значение, которые фактически хранятся. Скорость декодирования в одной группе данных зависит от пропускной способности памяти, деленной на количество байт, обрабатываемых на каждом шаге. Таблицы вкладок и независимые головы языковой модели могут потреблять сотни миллионов параметров при больших словарях — это не ошибка округления. Внутри блока путь передачи данных обычно содержит примерно в два раза больше параметров проекции, чем у механизма внимания.

Подробный обзор — Обучение к честности диаграмм

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

Вы можете объяснить, без использования слайдов, почему тот или иной инцидент негативно сказался на TTFT по сравнению с TPOT. Вы можете оценить объем памяти KV для заданной цели совместимости и контекста. Вы можете указать, какой механизм — пакетная обработка, квантование, GQA, спекуляция, кэш префиксов — применим в данном случае. Вы рассматриваете токенизаторы и шаблоны как зависимости с версионированием. Это и есть операционная грамотность для инференса больших языковых моделей; всё остальное — это детали, которые можно найти в соответствующих источниках.

Предположим, вы размещаете чат-модель с 70 миллиардами параметров в формате fp16 на паре GPU с большим объемом памяти. Только веса модели занимают около ста сорока гигабайт, поэтому память этих GPU уже почти полностью заполнена еще до начала любого диалога. Оставшееся пространство должно покрывать потребности в KV-памяти для всех активных сессий, активаций и управления фрагментацией памяти.

Вы установили цели для продукта: шестнадцать одновременных пользователей, контексты длиной четыре тысячи токенов, потоковые ответы. Приблизительные расчеты показывают, что несколько сотен килобайт на токен приводят к значению в десятки гигабайт при умножении на шестнадцать и четыре тысячи — это слишком много для оставшейся памяти. Сразу же появляются варианты решения: перейти на чекпоинт GQA, квантизировать кэш, снизить уровень одновременных запросов, укоротить контекст или добавить GPU. Именно такие расчеты позволяют отличить размытый вопрос «нам нужно больше GPU» от точного плана использования ресурсов.

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

Описание кейса — циклы агента и ключи кэша

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

Описание кейс-стади — Спекулятивная декодировка кода и чата

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

Описание кейс-стади — Ошибки в последовательностях остановки

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

Описание кейс-стади — неожиданность при квантизации

Веса в четыре бита позволили увеличить скорость обработки токенов примерно на 40% на пути декодирования с ограниченной памятью. Запуск инструментов снизил производительность на три пункта. Компромисс: использовать 8-битную форматацию для инструментальных путей и 4-битную — для черновиков длинных блогов. Один модельный артефакт и два профиля обслуживания — всё это возможно благодаря маршрутизации через шлюз.

Практический чек-лист — готовность к запуску

• [ ] Документирована схема обработки данных для предзаполнения и декодирования
• [ ] Измерена величина KV-байтов на один токен в реальном чекпоинте
• [ ] Уровень одновременной обработки и объем контекста соответствуют памяти GPU с запасом
• [ ] Включена функция непрерывной группировки задач с политикой приоритетов декодирования

[ ] Ключи кэша с префиксом включают шаблон, токенизатор, LoRA и масштаб RoPE

[ ] Кортеж выборки записывается для каждого ответа

[ ] Ограниченная декодировка для любого JSON-контракта

[ ] Стриминговая детокенизация буферов с неполным UTF-8

[ ] Последовательности остановки тестируются через границы токенов

[ ] Спекулятивная декодировка включается в зависимости от измеренного уровня принятия

[ ] Квантование проверяется на оценках, специфичных для задачи

[ ] План параллельной обработки тензоров/пайплайнов соответствует реальной структуре взаимосвязей

Практический чек-лист — триаж инцидентов

1. Сломано ли TTFT или TPOT?
2. Изменилась ли длина промпта или состав пакета?
3. Находится ли память KV близко к лимиту?
4. Изменились ли версии токенизатора/шаблона?
5. Изменился ли флаг ядра/квантования?
6. Плохо ли работает спекулятивная декодировка?
7. Ограничены ли мы пропускной способностью или вычислительными ресурсами в конкретном профиле?

Обрабатывайте список в порядке; большинство страниц типа «модель сегодня не работает» решаются на четвертом этапе.

Глоссарий в одном месте

TTFT — время до первого выданного токена после начала запроса. TPOT / ITL — среднее время между последовательными токенами. Prefill — параллельная обработка запроса с заполнением структуры KV. Decode — авторегрессивные шаги, выдающие новые токены. KV cache — сохраненные ключи/значения прошлых токенов. GQA — группированное внимание к запросам с уменьшением количества голов KV. PagedAttention — распределение ресурсов KV по блокам. Nucleus (top-p) — адаптивная обрезка хвоста вероятностей. Speculative decoding — ускорение за счет предварительной обработки и последующей проверки. Roofline — модель, связывающая интенсивность работы с пиковым количеством операций FLOPs и пропускной способностью.

Заключительный абзац

Рассматривайте процесс вывода заключений как производственную линию. Токенизаторы определяют места хранения компонентов. Эмбеддинги и блоки представляют собой машины. Кэш KV — это запасы в процессе обработки, которые занимают место на складе в зависимости от количества открытых заказов. Отбор примеров служит контролем качества для каждой единицы. Стриминг — это причал для отгрузки. Спекулятивная декодировка — это параллельный коридор для проверки. Если оптимизировать ту или иную станцию, не учитывая запасы и пропускную способность, это приведёт к накоплению незавершённой работы и недовольства клиентов — даже если каждая станция «выглядит быстрее» по отдельности.

Приложение — Сравнение когнитивных моделей, о которых вы услышите на собеседованиях

Интервьюеры часто просят вас согласовать три лозунга: «Трансформеры работают параллельно», «Декодирование происходит последовательно» и «Механизм внимания имеет квадратичную структуру». Все они верны в разных контекстах. Процессы обучения и предзаполнения используют параллелизм между уже существующими позициями. Декодирование не может заранее определить будущие токены без спекуляций. Квадратичный член механизма внимания играет наиболее значимую роль, когда длина последовательности велика по сравнению с объемом вычислений, связанных с матричными операциями. Хороший ответ указывает на контекст перед приведением лозунга.

Еще одна распространенная ошибка — отождествление количества параметров с скоростью декодирования. Параметры определяют количество байт, обрабатываемых на шаг, тогда как структура модели (GQA), тип данных и группировка данных в пакеты определяют, как эти байты преобразуются в количество токенов в секунду. Два модели объемом 70 миллиардов параметров могут отличаться в два раза по времени интерактивной обработки из-за этих факторов.

Третья ошибка — рассматривать процесс выборки как «просто RNG». Температура, обрезка данных, штрафы и ограничения каждый по-своему изменяют категориальное распределение; RNG лишь выбирает из того, что осталось. Для устранения странных результатов необходимо сначала записать этот тупл.

Приложение — Основные уравнения, стоит запомнить

KV bytes ≈ 2 × layers × kv_heads × head_dim × bytes × seq_len × batch. Интенсивность декодирования для батча 1 ≈ 2 × params / weight_bytes ≈ O(1) FLOP/byte для плотных данных в формате fp16. Ожидаемое количество спекулятивных токенов на проверку ≈ (1 − α^(k+1)) / (1 − α). Стабильность функции Softmax: вычитайте максимальное значение перед применением функции exp. Маска причинно-следственных связей: записывайте −∞, а не ноль, в запрещенные оценки.

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

Приложение — Куда двигаться дальше

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

Когда в заявке на поддержку указано «ИИ работает медленно», необходимо это проанализировать. Если индикатор загрузки отображается перед любым текстом, следует проверить факторы TTFT: длину промпта, наличие «холодных» префиксов, перегрузку при предзаполнении или отсутствие кэша. Если текст появляется быстро, но затем отображается медленно, следует проверить факторы TPOT: избыточный размер пакетов, ограниченная память KV, вынуждающая использовать маленькие пакеты, неквантизированные веса на карте с ограниченной пропускной способностью или отключение спекуляций на маршруте, который раньше работал эффективно.

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

Когда в заявке говорится, что «система сама создает JSON», прекратите настраивать параметр температуры и внедрите ограниченную декодировку. Выборка не может обеспечить соблюдение грамматики; маскировка — может.

Встречи по планированию мощностей проходят лучше, когда кто-то пишет на доске три числа: количество байтов на один токен KV, целевая конкурентность и целевой объем контекста. Умножьте эти значения, добавьте весовой фактор и сравните результат с объемом памяти GPU. Споры о «магии ИИ» прекращаются, начинается математика закупок.

В этом и смысл всего этого обзора процессов: заменить неопределенность показателями и эти показатели — рычагами, которые можно использовать.

Заключительные замечания по объему работ

Эта переработка остается в рамках процесса инференса: то, что происходит после того, как сформированы веса, когда клиент отправляет текст, и до того, как команда по операциям начинает обсуждение финтюнинга. Вопросы, связанные с процессом обучения — смешивание данных, оптимизаторы, графики параллельного обучения — имеют огромное значение, но это уже другая тема. Если вы можете при давлении запоминать такие аспекты, как разделение на предзаполнение и декодирование, «налог KV» и состав выборки, у вас уже есть основа, к которой можно присоединить остальные элементы.

Упражнение для читателя

Возьмите одну заявку на обработку из ваших журналов. Запишите количество токенов входных данных, количество токенов выходных данных, а также значение TTFT/TPOT, если оно известно. Оцените объем памяти KV с использованием формулы, учитывающей количество токенов и структуру слоев и головы вашей модели. Определите, была ли заявка ближе к сценарию предзаполнения, ограниченному вычислительными ресурсами, или к сценарию декодирования, ограниченному пропускной способностью. Укажите один фактор — кэш префиксов, размер пакета, квантизация, GQA или спекулятивные операции — который мог бы повлиять на показатель, который вас больше всего интересует. Если вы сможете выполнить это задание, не открывая эту статью снова, значит, переработка была эффективной.

Сохраните краткую личную справку: предзаполнение против декодирования, формула для байтов KV, TTFT против TPOT и порядок выборки. Прочитайте её перед анализом объёмов данных и прежде чем винить модель в появлении ошибок. Такие небольшие привычки способствуют формированию надёжной интуиции. Практикуйтесь объяснять процесс работы модели вслух за менее чем две минуты; умение говорить свободно под давлением времени — вот что на самом деле показывает уровень понимания. Практикуйтесь объяснять процесс работы модели вслух за менее чем две минуты; умение говорить свободно под давлением времени — вот что на самом деле показывает уровень понимания. Практикуйтесь объяснять процесс работы модели вслух за менее чем две минуты; умение говорить свободно под давлением времени — вот что на самом деле показывает уровень понимания.