Свой инференс для AI-агентов: память, скорость и гибрид CPU + GPU

Черновик v0.1: текст будет дополняться.

Агент — это языковая модель, которую вызывают много раз подряд. Она читает задачу, решает, какой инструмент вызвать, получает его ответ, думает дальше и так до результата. Когда такую модель запускают у себя, без облачного API (ради приватности, цены или работы без сети), всё упирается в железо: влезет ли модель в память, как быстро она будет отвечать и что делать, если видеокарты не хватает.

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

1. Чем агент нагружает инференс

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

Вызовов много, и они идут подряд. Каждый шаг агента — это отдельный вызов модели, и задержки шагов складываются. Если один шаг занимает 20 секунд, задача из 15 шагов займёт пять минут, даже если модель отвечает правильно.

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

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

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

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

2. Две фазы инференса

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

Потом decode: модель генерирует ответ по одному токену. Для каждого нового токена нужно прочитать из памяти все веса модели (для плотной модели) и весь накопленный KV-кэш, а вычислений на это приходится мало. Поэтому decode упирается в пропускную способность памяти. Авторы NEO пишут об этом прямо: внимание на этапе декодинга ограничено пропускной способностью памяти и на GPU, и на CPU из-за низкой арифметической интенсивности.

Отсюда практическое правило. Скорость генерации определяется тем, сколько байт в секунду память может отдать, а скорость чтения контекста — вычислительной мощностью.

3. Сколько нужно памяти

Память под модель складывается из трёх частей: веса, KV-кэш и накладные расходы.

Веса весят столько, сколько параметров умножить на байты на параметр. В FP16 это 2 байта, в 8 битах 1 байт, в 4-битном квантовании около половины байта. Например, у Llama-3.1-8B в формате Q4_K_M файл весит около 4,9 ГБ, а у Llama-3.1-70B в том же формате около 42 ГБ.

KV-кэш растёт с длиной контекста. На один токен он занимает:

2 × число слоёв × число KV-голов × размер головы × байт на число

У Llama-3.1-8B 32 слоя, 8 KV-голов по 128, поэтому в FP16 выходит 128 КиБ на токен. Контекст в 32 тысячи токенов занимает около 4 ГиБ, а в 128 тысяч — около 16 ГиБ, больше, чем сами веса в 4 битах. У Llama-3.1-70B 80 слоёв, и на токен уходит 320 КиБ: 32 тысячи токенов — это около 10 ГиБ. Для агента с длинным контекстом KV-кэш легко становится главным потребителем памяти, а при нескольких параллельных сессиях он умножается на их число.

Накладные расходы — это память самой среды: CUDA, буферы, активации. По оценке авторов llm_gpu_calculator, только CUDA берёт около 0,5–1 ГБ.

Пример: Llama-3.1-8B в Q4_K_M с контекстом 32 тысячи токенов требует примерно 4,9 + 4 + 1 ≈ 10 ГБ. Это влезает в видеокарту на 12 ГБ. С контекстом 128 тысяч нужно уже около 22 ГБ, и это впритык для 24 ГБ.

Если не влезает, есть несколько способов уменьшить память:

1. Квантовать веса сильнее: Q4 вместо Q8, Q3 вместо Q4, ценой качества.
2. Квантовать KV-кэш (например, в 8 бит). Он станет вдвое меньше; потеря качества обычно невелика, но её стоит проверить на своих задачах.
3. Ограничить контекст агента: сжимать историю и обрезать длинные ответы инструментов.
4. Взять модель меньше или MoE-модель и вынести часть работы на процессор (об этом раздел 6).

4. Сколько токенов в секунду

Раз decode упирается в память, его потолок легко оценить:

скорость генерации ≈ пропускная способность памяти / байты, которые читаются на один токен

Для плотной модели на один токен читаются все веса и KV-кэш. На этой формуле с поправкой на эффективность построен llmfit.io, и его авторы пишут, что оценки обычно попадают в реальные результаты с точностью ±20 %.

У RTX 4090 пропускная способность около 1 ТБ/с, а 8B-модель в Q4 весит около 4,9 ГБ. Потолок получается около 200 токенов в секунду, а на практике выходит заметно меньше, обычно половина-две трети потолка. Двухканальная память DDR5 на обычном настольном компьютере даёт около 90 ГБ/с, то есть потолок около 18 токенов в секунду для той же модели на процессоре.

Если модель не влезла в видеопамять и часть весов осталась в обычной оперативной памяти, скорость падает резко. По данным llmfit, в 5–20 раз.

С MoE-моделями счёт другой. В MoE на каждый токен работает только часть экспертов. Например, у DeepSeek-V3 671 миллиард параметров, но на токен активны около 37 миллиардов. Значит, на токен читается только часть весов, и скорость определяется активными параметрами. Поэтому большие MoE-модели хорошо подходят для гибрида CPU + GPU.

Для агента важна и скорость prefill. Если контекст шага — 30 тысяч токенов, а модель читает его со скоростью 500 токенов в секунду, первый токен ответа появится только через минуту. На видеокарте prefill обычно в десятки раз быстрее, чем на процессоре, и именно здесь кэш префикса экономит больше всего.

5. Калькуляторы: что они считают и где ошибаются

Посчитать всё вручную можно, но проще начать с калькулятора. Вот четыре из источников.

llmfit.io

Вы выбираете видеокарту (NVIDIA от RTX 3000 до 5000, A100, H100, H200, AMD RX 7000, Apple от M1 до M4) или считаете на процессоре, задаёте модель, квантование от FP16 до Q2_K и контекст от 2 до 128 тысяч токенов. Калькулятор отвечает, влезет ли модель, и оценивает скорость генерации, скорость prefill, время до первого токена и раскладку памяти. Считает он по пропускной способности памяти с поправкой на эффективность. Сами авторы предупреждают, что это теория: реальная скорость отличается примерно на ±20 % в зависимости от движка, батча и системы, а у Apple общая память даёт меньшую эффективную пропускную способность, чем у отдельной видеокарты.

whatmodelscanirun.com

Здесь вопрос обратный: какие модели подойдут под ваше железо. Вы указываете видеокарту или объём видеопамяти, минимальный контекст (от 2 до 200 тысяч токенов), минимальную скорость (от 5 до 100 токенов в секунду) и, если нужно, объём оперативной памяти для выгрузки. Сайт подбирает модели и квантования. Методика расчёта на странице не раскрыта, данные обновлены в сентябре 2026 года.

llm_gpu_calculator

Открытый калькулятор на GitHub. Считает память как сумму весов, KV-кэша, активаций, памяти под оптимизатор и градиенты и накладных расходов CUDA, поэтому годится и для инференса, и для дообучения (LoRA, QLoRA). Поддерживает форматы llama.cpp (GGML) и bitsandbytes. Авторы сверяли расчёт с замерами на RTX 4090 и RTX 2060 и получили точность около ±500 МБ, но предупреждают, что точное значение предсказать невозможно: оно зависит от модели, данных, версии CUDA и квантования.

LLM-calculator

Ещё один калькулятор на GitHub, но про скорость генерации. Он учитывает несколько видеокарт и разбиение слоёв между ними, обмен по PCIe, выгрузку на процессор и в оперативную память, плотные и MoE-модели. Скорость определяется самым узким местом: пропускной способностью видеопамяти, вычислениями, шиной PCIe или оперативной памятью. Авторы честно пишут, что результаты — оценки, и что сравнение конфигураций между собой надёжнее, чем абсолютное число токенов в секунду.

Что общего

Все четыре считают один запрос с заданным контекстом. Агенту же нужен длинный контекст, часто несколько сессий сразу, и для него важны время до первого токена и переиспользование префикса. Калькулятор хорош, чтобы отсечь заведомо неподходящее, а окончательный ответ даст только замер на своём железе, например llama-bench из llama.cpp на вашей длине контекста.

6. Когда модель не влезает: гибрид CPU и GPU

Если модель не помещается в видеопамять, часть работы можно отдать процессору. Есть два пути.

Первый путь — держать веса в оперативной памяти и подкачивать их на видеокарту по мере надобности. Он упирается в шину PCIe: у PCIe 4.0 около 32 ГБ/с, гораздо меньше, чем у видеопамяти.

Второй путь — считать часть модели прямо на процессоре, где лежат веса. Это выгоднее, потому что пропускная способность памяти у серверного процессора гораздо выше, чем у PCIe. Например, у двухсокетного Xeon с DDR5 около 440 ГБ/с. Три работы ниже развивают именно этот путь.

NEO: больше запросов на одну видеокарту

NEO (MLSys 2025, Пекинский университет, UC Berkeley, UC Davis, Гарвард) решает задачу онлайн-сервиса, которому не хватает видеопамяти под KV-кэш. Без памяти нельзя набрать большой батч, и дорогая видеокарта простаивает. NEO переносит часть вычислений внимания на этапе декодинга вместе с их KV-кэшем на процессор того же сервера. Видеокарта и процессор работают одновременно (асимметричный конвейер), а планировщик на каждом шаге решает, какие запросы отправить на процессор.

Почему это работает: decode-внимание упирается в память, а по памяти разрыв между видеокартой и процессором невелик. Авторы приводят пример: у A10G около 600 ГБ/с и 125 TFLOPS, у обычного x86-сервера около 200 ГБ/с и 1,2 TFLOPS. По вычислениям разница в сто раз, а по памяти всего втрое.

Результат при той же задержке: до 7,5 раз больше пропускной способности на T4, на 26 % больше на A10G и на 14 % больше на H100. С более мощным процессором прирост на A10G доходит до 79,3 %. Для агентов это значит больше одновременных сессий на одной видеокарте.

APEX: процессор и видеокарта параллельно

APEX (arXiv 2506.03296, 2025) продолжает ту же идею для слабых видеокарт. Авторы заметили, что подход NEO плохо работает, когда задача в основном генерирует текст: батч приходится делить на части, и линейные операции считаются дважды. APEX не делит батч. Внимание для запросов, выгруженных на процессор, считается асинхронно, пока видеокарта делает свою часть, а когда какой режим выгоднее, решает простая аналитическая модель.

На T4 с LLaMa-2-7B APEX даёт на 84–96 % больше пропускной способности, чем vLLM, и до 49 % больше, чем NEO. На A10 с LLaMa-3.1-8B — на 11–89 % больше, чем vLLM, и до 37 % больше, чем NEO, на длинных ответах. Ограничения авторы называют сами: блокировка интерпретатора Python требует минимального числа запросов на процессоре, профилирование иногда ошибается, и несколько видеокарт пока не поддерживаются.

KTransformers: огромная MoE-модель на одной видеокарте

KTransformers (SOSP 2025, Университет Цинхуа, Approaching.AI и другие) нацелен на локальный запуск больших MoE-моделей вроде DeepSeek-V3/R1 на 671 миллиард параметров, когда запрос один. Внимание и общие эксперты, которые работают на каждом токене, остаются на видеокарте, а маршрутизируемые эксперты, которых большинство, считаются на процессоре. Для этого авторы написали ядра под инструкции Intel AMX (для prefill) и AVX-512 (для decode), уложили всю фазу декодинга в один CUDA Graph, чтобы убрать накладные расходы на запуск ядер, и придумали отложенных экспертов (Expert Deferral). Часть экспертов слоя считается одновременно со следующим слоем, и процессор с видеокартой простаивают меньше: в примере с DeepSeek-V3 загрузка выросла с 74 % и 28 % до 100 % и 37 %.

По сравнению с существующими системами prefill ускоряется в 4,62–19,74 раза, decode — в 1,25–4,09 раза. Отложенные эксперты добавляют до 45 % скорости декодинга, а точность на тестах (HumanEval, MBPP, GSM8K, StrategyQA, LiveBench) падает в среднем не больше чем на 0,5 %.

Испытательный стенд — два процессора Xeon с 1 ТБ DDR5 и видеокарта RTX 4080 на 16 ГБ (или A100). DeepSeek-V3 в Int4 на таком стенде, судя по графикам статьи, генерирует около 16 токенов в секунду, а с отложенными экспертами — около 23. Prefill — до 500 токенов в секунду на промптах в пару тысяч токенов. Для агента это значит, что модель уровня DeepSeek-V3 можно держать у себя, на одном сервере с одной потребительской видеокартой, если для задачи хватает одного-двух запросов одновременно.

7. Как выбрать железо и модель под своих агентов

1. Посчитайте типичный контекст шага агента: системный промпт, описания инструментов, историю и ответы инструментов. По нему посчитайте KV-кэш для своей модели.
2. Сложите веса, KV-кэш и запас около гигабайта и сравните с видеопамятью. Если не влезает, квантуйте веса, квантуйте KV-кэш или сокращайте контекст.
3. Оцените скорость генерации: пропускная способность памяти, делённая на размер активных весов, умноженная на 0,5–0,7. Отдельно оцените время до первого токена на вашем контексте: для агента оно часто важнее.
4. Если нужна большая модель, а видеокарта одна, смотрите в сторону MoE и гибрида CPU + GPU, как в KTransformers. Плотную модель лучше целиком держать на видеокарте.
5. Если агентов несколько и они работают одновременно, памяти нужно на KV-кэш всех сессий сразу. Здесь помогают выгрузка части внимания на процессор (NEO, APEX) и кэш префикса.
6. Проверьте выбор калькулятором (llmfit.io, whatmodelscanirun.com), а затем замером на своём железе с вашей длиной контекста.

Источники

• llmfit.io — калькулятор: влезет ли модель и с какой скоростью она будет работать.
• What Models Can I Run — подбор моделей под видеокарту.
• llm_gpu_calculator — расчёт памяти для инференса и дообучения.
• LLM-calculator — оценка скорости генерации с выгрузкой и несколькими видеокартами.
• Jiang, Zhou, Cao, Stoica, Yu. NEO: Saving GPU Memory Crisis with CPU Offloading for Online LLM Inference. MLSys 2025.
• Fan, Zhang, Li, Nikolopoulos. Parallel CPU-GPU Execution for LLM Inference on Constrained GPUs (APEX). arXiv 2506.03296, 2025.
• Chen et al. KTransformers: Unleashing the Full Potential of CPU/GPU Hybrid Inference for MoE Models. SOSP 2025.