Контекст локальной LLM: 8K, 32K, 64K или 128K — сколько реально нужно

Что такое context window у LLM

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

В него попадает не только ваш последний вопрос. Современный чат может передавать модели:

• system prompt;
• историю предыдущих сообщений;
• текущий вопрос;
• текст документов;
• результаты RAG retrieval;
• описания tools/functions;
• прочитанные файлы проекта;
• вывод терминала и тестов;
• часть будущего ответа.

Поэтому окно 32K не означает «можно вставить документ на 32 тысячи токенов и ещё получить бесконечный ответ». Все компоненты делят один бюджет.

Что такое 8K, 32K и 128K токенов

K здесь означает тысячи токенов:

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

Максимальный context и эффективный context — разные вещи

Если в карточке модели указано 128K, это означает, что архитектура/runtime допускают окно такого размера. Это не гарантирует одинаковое качество на 4K и 120K входа.

В исследовании EMNLP 2025 Context Length Alone Hurts LLM Performance Despite Perfect Retrieval авторы проверяли пять открытых и закрытых моделей на математике, QA и coding. Даже при идеальном доступе ко всей релевантной информации качество снижалось по мере роста входа, оставаясь внутри заявленного context window.

Это соответствует и практическим отзывам local-LLM пользователей: длинное окно часто полезно как вместимость, но модель может хуже удерживать ограничения, связи и детали в очень длинных сессиях. Форумные цифры нельзя считать универсальным benchmark, но сам эффект подтверждается исследованиями.

Сколько контекста ставить: практическая таблица

Что такое KV-cache и почему он съедает память

Transformer не пересчитывает всю предыдущую последовательность с нуля при каждом новом токене. Для уже обработанных токенов сохраняются key/value states — KV-cache.

Чем больше контекст, тем больше таких состояний нужно хранить.

Разработчик llama.cpp в официальной discussion поясняет memory breakdown: веса модели — отдельный buffer, KV buffer — это context, а ещё существуют compute buffers. Поэтому размер GGUF на диске не показывает полный расход памяти.

Насколько может вырасти VRAM из-за контекста

Точный размер KV-cache зависит от архитектуры: числа слоёв, KV-heads, head dimension, типа K/V cache, GQA/MQA и других параметров.

В одном из официальных разборов llama.cpp контекст около 30K для конкретной 32-layer модели создавал KV-cache примерно 3,75 ГБ. Это не универсальная цифра, но хорошо показывает порядок проблемы.

Именно поэтому статья про размер модели и статья про context — разные темы.

Базовые расчёты памяти: сколько RAM и VRAM нужно локальной LLM.

Почему большой контекст замедляет модель

Есть два разных этапа:

Поэтому 128K context может быть «включён», но пользователь будет ждать значительно дольше до начала ответа.

TTFT и tokens/s — не одно и то же

TTFT — time to first token. Большой prompt прежде всего ухудшает TTFT. После начала генерации tokens/s может выглядеть приемлемо, но пользователь уже потратил десятки секунд или минуты на prefill.

Почему больше контекста не означает лучшее качество

Причин несколько:

• релевантные факты становятся меньшей долей общего входа;
• модели хуже используют информацию в некоторых позициях длинного текста;
• много похожих фрагментов создаёт конкурирующие сигналы;
• длинная история содержит устаревшие инструкции и ошибки;
• long-context training не гарантирует одинаковую reasoning-quality на всей длине.

В исследовании EMNLP 2025 снижение качества наблюдалось даже при идеальном retrieval и без обычной проблемы «модель не нашла нужный кусок». То есть сама длина входа может быть фактором деградации.

Как context length работает в Ollama

В актуальной документации Ollama context по умолчанию выбирается в зависимости от доступной VRAM:

Для web search, agents и coding tools документация Ollama рекомендует устанавливать как минимум 64K.

Изменить context глобально

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

Изменить в текущей CLI-сессии

/set parameter num_ctx 32768

Передать через API

{
  "model": "qwen3:8b",
  "prompt": "Разбери документ",
  "options": {
    "num_ctx": 32768
  }
}

Проверить реальный context и offload

ollama ps

Смотрите столбцы PROCESSOR и CONTEXT. Если после увеличения окна вместо 100% GPU появился CPU/GPU split, вы уже заплатили за длинный context скоростью.

Как выставить context в LM Studio

LM Studio позволяет задавать context_length при загрузке модели. Через REST API это выглядит так:

{
  "model": "model-id",
  "context_length": 32768,
  "flash_attention": true,
  "offload_kv_cache_to_gpu": true
}

API LM Studio отдельно различает:

• context_length — что вы выделили текущему instance;
• max_context_length — максимум, заявленный самой моделью.

Контекст в llama.cpp

В llama.cpp используется параметр -c / --ctx-size.

llama-cli -m model.gguf -c 32768

Для server:

llama-server -m model.gguf -c 32768

Важно: в server-сценарии KV pool может использоваться несколькими sequences/slots. Исторически разработчик llama.cpp пояснял: если общий ctx-size 8192 делится между двумя последовательностями, каждая получает максимум около 4096 токенов при полном заполнении.

Сколько ставить для обычного чата

Для обычного домашнего помощника без огромной истории чаще всего достаточно:

Вместо бесконечного роста контекста лучше периодически:

• начинать новый чат;
• суммаризировать старую историю;
• хранить факты отдельно;
• подключать memory/RAG для устойчивых знаний.

Сколько ставить для PDF, документов и RAG

RAG как раз существует для того, чтобы не отправлять целую библиотеку в контекст. Система ищет несколько нужных chunks и передаёт только их.

Если RAG требует 128K на каждый вопрос, сначала проверьте:

• chunk size;
• Top K;
• reranking;
• дубли документов;
• качество retrieval.

Полный гайд: локальная нейросеть для PDF и документов.

Сколько context нужно coding-agent

Coding-agent расходует окно агрессивнее обычного чата. В prompt попадают tool schemas, файлы, diff, ошибки компилятора, команды и история действий.

Но если на 64K модель частично выгружается в CPU, 32K с полным GPU-resident inference может дать лучший рабочий опыт.

Подробнее: локальный ИИ для программирования и Codex.

Почему серверу с несколькими пользователями context обходится ещё дороже

Один пользователь с 32K и четыре пользователя с 32K — не одно и то же.

llama.cpp server поддерживает parallel slots и unified KV pool. При планировании сервера нужно учитывать число одновременных sequences.

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

Можно ли уменьшить KV-cache квантизацией

Да. llama.cpp поддерживает quantized K/V cache на основных backend, включая CPU, CUDA, ROCm, Metal и Vulkan.

Это позволяет уменьшить память, занимаемую длинным контекстом. В зависимости от backend используются параметры типов cache K/V.

llama-cli -m model.gguf \
  -c 65536 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0

Более агрессивная квантизация cache может сэкономить ещё больше памяти, но её влияние на качество и скорость нужно проверять на конкретной модели/backend.

Модель стала медленной после увеличения context: что проверять

Оптимальный алгоритм настройки context

1. Определите реальную задачу.
2. Начните с минимального разумного окна.
3. Проверьте, помещается ли модель полностью на GPU.
4. Измерьте TTFT и generation speed.
5. Проверьте несколько реальных длинных запросов.
6. Увеличивайте окно только если упираетесь в его предел.

Частые вопросы