---
title: "Свой инференс для AI-агентов: память, скорость и гибрид CPU + GPU"
description: "Чем агенты нагружают инференс, как посчитать память и скорость модели на своём железе, что умеют калькуляторы и как свежие системы делят работу между GPU и CPU: NEO, APEX, KTransformers."
status: "published"
language: "ru"
canonical: "https://bulnik.dev/ru/articles/agents-local-inference/"
publishedAt: "2026-10-05"
---

> Черновик 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](https://llmfit.io/) — калькулятор: влезет ли модель и с какой скоростью она будет работать.
- [What Models Can I Run](https://whatmodelscanirun.com/) — подбор моделей под видеокарту.
- [llm_gpu_calculator](https://github.com/wawancenggoro/llm_gpu_calculator) — расчёт памяти для инференса и дообучения.
- [LLM-calculator](https://github.com/BloedeBleidd/LLM-calculator) — оценка скорости генерации с выгрузкой и несколькими видеокартами.
- [Jiang, Zhou, Cao, Stoica, Yu. NEO: Saving GPU Memory Crisis with CPU Offloading for Online LLM Inference. MLSys 2025](https://minlanyu.seas.harvard.edu/writeup/mlsys25.pdf).
- [Fan, Zhang, Li, Nikolopoulos. Parallel CPU-GPU Execution for LLM Inference on Constrained GPUs (APEX). arXiv 2506.03296, 2025](https://arxiv.org/html/2506.03296v2).
- [Chen et al. KTransformers: Unleashing the Full Potential of CPU/GPU Hybrid Inference for MoE Models. SOSP 2025](https://madsys.cs.tsinghua.edu.cn/publication/ktransformers-unleashing-the-full-potential-of-cpu/gpu-hybrid-inference-for-moe-models/SOSP25-chen.pdf).