llama.cpp KV-кеш: квантизация K/V и проверка памяти

Что именно квантуется и кому это нужно?

При генерации llama.cpp сохраняет ключи и значения attention в KV-кеше. В отличие от квантизации весов GGUF, параметры --cache-type-k и --cache-type-v меняют тип данных кеша для текущего контекста, а не исходный файл модели. По документации llama-server оба типа по умолчанию f16; в перечне допустимых значений есть q8_0, q4_0, q5_0 и другие. Типы K и V выбираются независимо. Это не инструкция переквантовать GGUF и не основание обещать неизменный ответ s1s2s6.

Практическая задача — поместить выбранную модель и нужную длину контекста в имеющиеся ресурсы, не потеряв пригодность ответов. Путь: собственные запросы → один точный файл GGUF и его ревизия → память CPU/GPU и требуемый контекст → сервер llama.cpp → логи KV и проверенные ответы. Если не определили модель или backend, начните с общего запуска llama.cpp и только потом меняйте тип кеша. Размер файла весов не равен минимальной RAM/VRAM: кроме весов будут кеш, рабочие буферы, размещение слоёв и другое потребление процесса s1s3s5.

Как выбрать f16, q8_0 или q4_0 без ложных гарантий?

f16/f16 — контрольный режим, совпадающий с параметрами K/V по умолчанию. q8_0/q8_0 и q4_0/q4_0 — две отдельные экспериментальные конфигурации, а не обязательная последовательность улучшений. В закреплённом исходнике квантованный V требует Flash Attention: режим auto включает его автоматически, а явный off приводит к ошибке. Наличие флага ещё не доказывает поддержку выбранным backend. При заданной архитектуре и количестве ячеек более компактный формат может уменьшить выделенный буфер, но отношение размеров не переносится автоматически на всю RAM или VRAM; исходник выделяет тензоры по слоям и сообщает K/V отдельно. Не переносите измерения чужой модели, длины контекста или backend на свою машину s1s3s6s7.

Для первого сравнения используйте симметричные пары, явно фиксируя, что K и V меняются вместе; это сравнение конфигураций, а не оценка вклада каждой компоненты. Если требуется оценить эффект только K, сравните q8_0/f16 с f16/f16 при остальных равных условиях, затем отдельно меняйте V. Смешанный q8_0/f16 допустим в перечне независимых параметров, но совместимость и скорость конкретной комбинации зависят от backend и сборки. Проверка качества важнее формального уменьшения буфера: возьмите длинные контексты со ссылками на факты, задачами извлечения и повторным обращением к началу документа, а не только один короткий приветственный запрос s1s2s3.

--no-kv-offload отключает выгрузку KV на ускоритель, но не квантует и не уменьшает автоматически всю память системы. В исходном коде тип буфера берётся от CPU, либо от устройства слоя при включённом offload; поэтому сравнивайте место выделения вместе с числом MiB. Не объявляйте экономию VRAM, если кеш ушёл в RAM. Опция --cache-ram и reuse префикса описывают другой слой управления кешем; они не являются заменой выбору типа K/V s1s3.

Как подготовить сопоставимый локальный запуск?

Используйте один и тот же собранный бинарник llama-server, точный путь к разрешённому к использованию GGUF и одинаковые аппаратные настройки в каждой серии. В документации сборки есть отдельные пути CPU, CUDA и других backend; не меняйте backend посередине эксперимента. Замените /PATH/TO/MODEL.gguf на фактический локальный файл, не скачивайте случайную модель лишь ради этого теста. Если бинарник не поддерживает параметры из закреплённой ревизии, сначала проверьте версию через llama-server --help s1s5.

Для контрольного сервера используйте шаблон по документации, который Modelium не запускал: llama-server -m /PATH/TO/MODEL.gguf --host 127.0.0.1 --port 8080 -c 4096 -np 1 --cache-type-k f16 --cache-type-v f16 --flash-attn on. На отдельном запуске замените обе последние пары f16 на q8_0, а после фиксации логов — на q4_0. Остальные аргументы, включая GPU layers, контекст и число слотов, оставьте неизменными; --flash-attn on держите одинаковым во всех сериях. Если выбранная модель/сборка/backend отказывается стартовать с включённым Flash Attention или определённым типом, зафиксируйте ошибку как несовместимость, а не подменяйте параметры только в одной серии. Не открывайте тестовый сервер наружу: 127.0.0.1 — локальный адрес привязки s1s2s5.

После каждого старта запросите GET /health: во время загрузки сервер может вернуть 503, после готовности — 200. Затем подайте одинаковый тестовый набор на /completion или совместимый с моделью /v1/chat/completions; /completion не является OpenAI-совместимым маршрутом. Не считайте HTTP 200 проверкой смысла: запишите ответ, ошибки и условия sampling. Между режимами полностью остановите процесс и поднимите его заново, иначе сравните прогретый кеш и остатки нагрузки вместо типов K/V s1.

Как измерить память, задержку и качество ответов?

В логах старта найдите выделенный KV buffer size для конкретного CPU/GPU backend и строку size = ... MiB с отдельными размерами K и V, количеством ячеек и слоёв. Эти числа позволяют сравнить буфер KV при одинаковых условиях, но не отражают полное потребление процесса. Дополнительно снимайте свободную/занятую память устройства и RAM до и после запуска своим обычным мониторингом; не выводите «минимальные требования» из одной строки лога. Даже при одинаковом GGUF число слотов, -c, аппаратный backend и offload меняют размещение и объём кеша s1s3.

Зафиксируйте точный файл и ревизию модели, версию бинарника, backend/устройство, режим K/V, -c, -np, GPU layers, --flash-attn, входные запросы, sampling, число выходных токенов и загруженность системы. Для каждого режима сравните правильность извлечения фактов из длинного разрешённого документа, ссылки на фрагмент, удержание условий в начале контекста и долю отказов/ошибок. Собственный критерий: ни одна критичная задача не ухудшилась недопустимо относительно f16, а сокращение памяти реально позволило нужный контекст. Это редакционный протокол, не бенчмарк или обещание числа процентов от разработчиков s1s3.

Для скорости сохраняйте задержку первого токена и полное время ответа при равной конкуренции. В серверных ответах есть объект timings с количеством и временем обработанных и предсказанных токенов; --metrics включает /metrics только если это нужно на закрытом стенде. Для более повторяемого pp/tg-сравнения llama-bench принимает -ctk, -ctv и -d (глубину заполненного контекста); prompt processing и generation — разные испытания. Запишите разброс повторов, не выдавайте токены/с за качество и не сравнивайте разные контекстные глубины как эффект одной квантизации s1s4.

Почему выигрыш не проявился или ответы испортились?

• Буфер меньше, а общая память почти не изменилась: веса и другие буферы остались прежними, часть KV могла находиться в RAM вместо VRAM. Проверьте строку backend, offload и внешнее измерение памяти, а не только размер GGUF s1s3.
• Квантованный тип не запустился: сверьте допустимые значения в --help, Flash Attention, модель/архитектуру и поддержку выбранного backend. Сохраните лог ошибки; не утверждайте, что любой тип работает на любом устройстве s1s2.
• Скорость стала ниже: дополнительная стоимость преобразования и путь выполнения на устройстве могут перекрыть уменьшение объёма кеша. Измерьте pp и tg отдельно на том же контексте; если условие эксперимента менялось, результат не атрибутируется квантизации s1s4.
• Ответы хуже при длинном контексте: вернитесь к f16/f16 или проверьте менее агрессивную пару q8_0/q8_0 на том же наборе; не объявляйте низкую ошибку по одному короткому запросу доказательством качества на документах s1s3.

Какой следующий шаг после сравнения?

Запишите три конфигурации, логи размеров K/V и размещения, условия нагрузки, результаты одинаковых запросов и измерения доступной памяти. Оставляйте квантованный режим только если он работает на вашем backend и выбранной модели, даёт полезный выигрыш в вашем ограничении памяти и не нарушает критерий качества. Если проверка не пройдена, используйте контрольный f16 либо пересмотрите контекст, GGUF и инфраструктуру через гайд запуска llama.cpp и выбор видеокарты. Modelium эту тройку режимов на реальном оборудовании не запускал s1s3s4.