Когда вы в ChatGPT, Claude или DeepSeek вводите текст, модель начинает отвечать по одному символу — буквально в течение нескольких сотен миллисекунд. На первый взгляд этот процесс кажется простым, но на деле это одна из самых тонких инженерных задач в современном вычислительном деле. В этой статье собран полный разбор цепочки рассуждений AI-инженера Акшая Пачхара (Akshay Pachaar): от tokenization, embedding и attention до двух этапов prefill/decode, KV cache, квантования — и почему DeepSeek V4 сократил объём кэша до прежних лишь 10%.
Ключевая ментальная модель: LLM — это просто «угадывание следующего token», а затем многократное повторение
По сути, большая языковая модель делает только одну вещь: предсказывает следующий token. Она получает последовательность токенов, которую вы ей подали, вычисляет распределение вероятностей следующего токена, сэмплирует и генерирует токен, добавляет его в конец входа и снова предсказывает следующий — и так без остановки, пока модель не выведет стоп-символ или не достигнет заданного лимита.
Ключевая проблема всего процесса вывода (inference) — не «как именно она предсказывает», а «почему второй token получается намного быстрее первого?». Ответ приводит к двум самым важным понятиям в современных сервисах на LLM: этапам prefill и decode и к тому же KV cache.
Step 1：Tokenization превращает текст в числа
Нейросети не читают текст — они работают с векторами. Поэтому ваш промпт сначала проходит tokenization, разбивается на кусочки «token», и каждый token соответствует целому числу — ID. Большинство современных LLM используют BPE (Byte Pair Encoding, байтовое кодирование): начиная с исходных символов, последовательно объединяют наиболее часто встречающиеся пары, и в итоге получают словарь из примерно 50 тысяч распространённых token.
Влияние этого шага гораздо сильнее, чем кажется большинству людей. На языках, которые в обучающих данных tokenizer встречаются с меньшим весом, токенизация даёт больше token — а значит растут вычислительные затраты, и скорость падает. Китайский язык и традиционный китайский в ряде англонаправленных tokenizer обычно требуют разбиения каждого иероглифа на 2–3 token. Это одна из фундаментальных причин, почему стоимость инференса для пользователей китайского выше.
Step 2：Embedding превращает целые числа в векторы и добавляет позиционную информацию
Целочисленный ID каждого token ищется в огромной «embedding-таблице». Если словарь модели — 50K, а скрытая размерность (hidden dimension) — 4096, то форма этой таблицы будет [50000, 4096]. Для каждого token берётся одна строка — вектор размерности 4096, то есть его векторное представление.
Эти векторы не случайны. При обучении модель «сдвигает» семантически близкие token в одну и ту же область пространства: king и queen оказываются рядом в некотором направлении; python (язык) и javascript — рядом в другом; python и snake (змея) — ещё в третьем.
Позиционная информация также добавляется на этом этапе, потому что механизм attention сам по себе не «знает», какой token стоит раньше, а какой — позже. В большинстве современных моделей используется RoPE (Rotary Position Embedding, поворотное позиционное кодирование): позиция токена поворачивает вектор, а порядок оказывается «зашит» прямо в самом представлении.
Step 3：Self-Attention — ядро Transformer
Далее последовательность векторов поступает в 32 (или больше) слоёв transformer. Каждый слой делает две вещи: с помощью self-attention смешивает информацию между token, а затем с помощью feed-forward смешивает информацию внутри каждого token.
Как работает self-attention: каждый token через три обучаемые матрицы весов Wq, Wk, Wv генерирует три вектора — query (запрос), key (ключ) и value (значение). Затем query одного токена берёт скалярное произведение с key всех остальных токенов и получает веса, определяющие, «сколько информации этот токен должен подтянуть из контекста». После этого значения value усредняются с соответствующими весами.
Вот где и проявляется «магия» attention: каждый token самостоятельно решает, на какие позиции в контексте смотреть и какие сведения подтягивать в своё представление. Когда таких слоёв 32, модель способна отслеживать ссылки через тысячи token. Следующая после attention feed-forward-сеть берёт на себя большую часть «знаний» модели: attention занимается переносом информации, а feed-forward — её обработкой.
Prefill и Decode：на одном GPU, но с совершенно разными узкими местами
Это самая важная граница в данной статье. Генерация ответа объёмом в 200 слов на практике представляет собой две задачи с совершенно разными свойствами, которые выполняются на одной и той же GPU.
Prefill-этап — когда вы отправляете prompt, модель сначала должна прогнать все входные token один раз, чтобы сгенерировать первый token. Этот этап можно «распараллелить»: Q, K и V каждого token вычисляются одновременно, а attention реализуется как умножение больших матриц на большие матрицы. GPU создан для таких операций: вычислительные блоки (Tensor Cores) загружены, а узкое место находится в «вычислительной мощности». Метрика задержки этого этапа называется TTFT (Time to First Token, задержка до первого токена).
Decode-этап — после того как выходит первый token, модель переключает режим. Когда генерируется 51-й token, ей нужно лишь вычислить Q, K и V для нового токена; K и V для предыдущих 50 token уже посчитаны и пересчитывать заново не требуется. Проблема в том, что объём вычислений на каждый token небольшой, но GPU всё равно должна загрузить из видеопамяти веса всей модели и всю историю KV, выполнить небольшую операцию, затем снова «выкинуть» результат. Узкое место меняется: с «вычислений» на «пропускную способность памяти». Метрика задержки этого этапа называется ITL (Inter-Token Latency, задержка между токенами) — именно она определяет, насколько «быстро печатает» модель.
Поэтому prefill — это compute-bound, а decode — memory-bound. Одна и та же модель, то же железо, но совершенно разные характеристики производительности.
KV Cache：ключевая оптимизация, делающая инференс LLM возможным
Decode-этап «не пересчитывает K и V прошлых token» — и именно этим занимается KV cache. На каждом transformer-слое поддерживаются два тензора: K и V для всех исторических token. Для нового токена вычисляют его K и V, затем append’ят в кэш; а во время attention просто читают всю историю целиком.
Без KV cache генерация ответа из 1,000 token на каждом шаге заставляла бы заново пересчитывать весь растущий по длине прецедент, и сложность раздувается до квадратичного взрыва. С KV cache длинная генерация ускоряется более чем в 5 раз. Но цена такова: кэш хранится в GPU-видеопамяти, и при каждом новом token кэш увеличивается на один «слой». Для модели масштаба 13B один token занимает примерно 1MB; контекст около 4K сжигает порядка 4GB видеопамяти только на то, чтобы хранить этот cache.
Это и есть настоящая причина «длинный контекст — медленно и дорого»: не потому, что модель «не может», а потому что cache съедает всю видеопамять, из‑за чего число пользователей, которых можно обслужить на одной GPU одновременно, резко падает. Типичные способы оптимизации включают: квантование cache до INT8 или INT4; использование sliding window, чтобы выбрасывать слишком старые токены; применение grouped-query attention (GQA), чтобы несколько attention head делили общий K и V; либо PagedAttention (как у vLLM), которая управляет cache «страницами» (по смыслу похоже на управление памятью в операционной системе).
Революция в кэше DeepSeek V4：в контексте 1M до 10% от прежнего объёма
Квантование и разбиение на страницы (paging) рассматривают KV cache как «фиксированную стоимость» и оптимизируют её. Серия V4, которую DeepSeek анонсировала под конец 2025 года, пошла ещё более радикальным путём: она напрямую переизобретает attention, чтобы cache изначально был небольшим.
V4 использует гибридный механизм, сочетая две вариации сжатия attention — разреженную и плотную — и обе работают поверх сильно сжатого потока KV. В условиях контекста в миллион токенов V4-Pro сообщает, что объём KV cache составляет примерно 10% от объёма у предшественника, а вычислительная нагрузка на один token — около 27%. Важно не только то, что «DeepSeek снова стал дешевле», а то, что KV cache превратился в один из главных узких мест оптимизации во всём домене LLM: когда attention-механизм сам начинает пересобираться ради уменьшения cache, это означает, что «ограничения» всего технологического сообщества полностью сместились.
Более практичная информация для читателей с Тайваня: DeepSeek V4-Flash уже доступен в Ollama Cloud и на американских хостингах (см. репортаж abmedia от 4/24), а также через Claude Code и OpenClaw — можно одним нажатием подключить и без самостоятельного развёртывания проверить преимущества нового поколения attention в сценариях с длинным контекстом.
Quantization：меняем точность на скорость и видеопамять
Обучению нужна высокая точность, инференсу — нет. В большинстве реальных развертываний переходят с FP32 на FP16 или BF16, и это сразу удваивает и объём видеопамяти, и throughput. Более радикальный подход — квантовать веса до INT8, а иногда и до INT4.
Понятный пример по цифрам: модель с 7B параметров в FP32 требует 28GB, в FP16 — 14GB, в INT8 — 7GB, а в INT4 — всего 3.5GB. Вот почему даже видеокарты в обычных ноутбуках способны запускать 7B-модели. Методы вроде GPTQ и AWQ подбирают коэффициенты масштабирования для каждого канала, чтобы минимизировать потерю качества из-за необратимого (lossy) сжатия: хорошо спроектированный INT4 в большинстве бенчмарков показывает результат всего на 1 процентный пункт хуже оригинала.
Собираем всё воедино：полное путешествие одного промпта
Если соединить все шаги вместе, то полный маршрут одного прогона инференса будет таким: (1) Tokenize — текст превращается в целочисленные ID. (2) Embed — ID превращаются в векторы и добавляется позиционная информация. (3) Prefill — все слои параллельно прогоняют все входные token; это относится к compute-bound, создаётся KV cache и генерируется первый выходной token. (4) Decode loop — на каждом шаге проецируется только новый token: выполняется attention по K и V из cache, затем работает feed-forward, делается сэмплирование вывода, новые K и V записываются обратно в cache; это относится к memory-bound. (5) Detokenize — ID токенов преобразуются обратно в символы, а затем поток вывода стримится на экран.
Фреймворки сервисов вроде vLLM, TensorRT-LLM, Text Generation Inference добавляют поверх этого цикла непрерывные батчи (токены разных пользователей могут интерливиться в одном GPU step), speculative decoding (маленькая модель пишет черновик, большая проверяет) и тонкий менеджмент памяти — и именно так достигается обслуживание десятков пользователей на одной GPU.
Практический вывод для разработчиков：за что вам стоит переживать — TTFT или ITL?
Когда вы ясно понимаете весь inference-процесс, естественно возникают несколько практических решений:
Длинные промпты увеличивают TTFT, а длинные ответы увеличивают ITL — это разные источники нагрузки, и нельзя направлять ресурсы оптимизации «не в тот показатель». Context не бесплатен: удвоение контекста означает не только удвоение вычислений, но и сжатие того, сколько батчей KV cache способен вместить. Квантование — это сейчас рычаг с наибольшим эффектом: переход с FP16 на INT8 часто снижает задержку примерно вдвое при минимальной потере качества. Даже показатель GPU utilization часто оказывается вводящим в заблуждение: на prefill GPU может быть загружена «под завязку», а на decode — использовать лишь около 30%; решение здесь не в том, чтобы добавлять вычисления, а в том, чтобы ускорить память или уменьшить cache.
Transformer привлекает больше всего внимания на архитектурном уровне, но реальная эффективность инференса живёт в «скучных деталях»: в настройке памяти, управлении cache и ширине битов. Когда кто-то говорит: «эта модель слишком медленная», следующий вопрос должен быть не «какую GPU поставить», а «она тормозит на этапе “старта” или на этапе “стриминга”?» — именно ответ определяет весь маршрут оптимизации.
Первая публикация этой статьи с полным руководством по inference LLM: KV cache и кэш-революция DeepSeek V4 — в цепочке новостей ABMedia.
