Квантование LLM: GGUF и AWQ для запуска 70B на домашнем ПК

Зачем квантовать LLM: арифметика памяти, скорости и цены железа

Квантование сжимает веса LLM с 16 до 4–8 бит: 70B-модель усыхает со 140 ГБ до 35–40 ГБ, а просадка качества в GGUF K-Quant по замерам держится в пределах двух процентов.

Вся арифметика здесь упирается в одну строчку. Объём весов равен числу параметров, умноженному на биты и поделённому на восемь. Для 70B в FP16 это 70 млрд × 16 / 8 = 140 ГБ. В чистом INT4 — те же 70 млрд × 4 / 8 = 35 ГБ. Ровно в четыре раза меньше, и никакой магии.

Формат	Бит на вес	Размер 70B	Что это даёт
FP16 / BF16	16	≈140 ГБ	Эталон качества, нужен кластер
FP8 / INT8	8	≈70 ГБ	Экономия вдвое, потери почти нулевые
INT4 (AWQ / GPTQ)	4	≈35 ГБ	GPU-сервер, vLLM, высокий батч
Q4_K_M (GGUF)	4,5–4,8	≈40–42 ГБ	CPU + GPU, Ollama, LM Studio
Q8_0 (GGUF)	8,5	≈75 ГБ	Почти эталон, но памяти вдвое больше

Обратите внимание на Q4_K_M: он тяжелее «чистого» INT4. Часть слоёв — эмбеддинги, выходной слой, первые и последние блоки — остаётся в повышенной точности, потому что именно они сильнее всего бьют по качеству. Отсюда и лишние 5–7 ГБ.

К весам нужно прибавить KV-кэш. Формула такая: 2 × число слоёв × число KV-голов × размерность головы × длина контекста × байты. Для 70B-архитектуры с 80 слоями, 8 KV-голов (GQA), head_dim 128 и FP16 это порядка 320 КБ на токен. На 8k контекста — около 2,7 ГБ, на 32k — уже 10,7 ГБ.

Дальше начинается выбор железа. Одна RTX 4090 на 24 ГБ 70B не удержит даже в INT4 — придётся выгружать слои на CPU, и скорость проваливается до единиц токенов в секунду. Две карты по 24 ГБ уже собирают модель целиком. Один ускоритель на 80 ГБ закрывает вопрос с запасом под длинный контекст.

FP16-вариант — это два A100 по 80 ГБ или четыре карты класса RTX 6000 Ada. Разница в требованиях к железу между FP16 и INT4 — не проценты, а порядок: домашняя сборка против серверной стойки.

Качество при этом почти не страдает. По данным разбора методов квантования на AiManual, современные GGUF с K-Quant теряют менее 2% качества относительно FP16 — для большинства прикладных задач это незаметно. Оговорка одна: на задачах с длинными логическими цепочками и точным кодом разрыв чувствуется сильнее.

Хотите увидеть ту же логику на меньшем масштабе — у нас есть разбор про то, как локальная модель SQL на ноутбуке обошла флагмана в тестах: там квантование и есть тот самый рычаг, который позволил уложиться в потребительскую память.

GGUF, AWQ, GPTQ и FP8: какой формат подходит вашему железу

GGUF — для CPU, Ollama и LM Studio, AWQ и GPTQ — для GPU-инференса на vLLM, FP8 — для флагманских ускорителей уровня H100 и B200. Выбор формата диктует не мода, а связка «процессор + видеопамять + движок инференса».

Давайте разберем на пальцах. Модель на 70B в FP16 занимает около 140 ГБ — это четыре топовые видеокарты или одна серверная. В 4 битах те же веса сжимаются примерно до 35 ГБ плюс накладные расходы на кэш и метаданные. Разница между форматами не в степени сжатия, а в том, где и как быстро эти веса разворачиваются.

Формат	Где живёт	Железо	Вес 70B	Когда брать
GGUF (Q4_K_M, Q5_K_M)	llama.cpp, Ollama, LM Studio	CPU, любой GPU, Apple Silicon	~40 ГБ	Домашний запуск, одна машина, гибкая выгрузка слоёв
AWQ (W4A16)	vLLM, SGLang	NVIDIA GPU от 16–24 ГБ	~40 ГБ	Продакшен-API, диалоговые и инструкционные модели
GPTQ (INT4)	vLLM, transformers	NVIDIA GPU	~40 ГБ	Старые конвейеры, где уже есть готовые веса
FP8	vLLM, TensorRT-LLM	H100, B200 и новее	~70 ГБ	Максимальная пропускная способность на флагманах

GGUF — это не просто формат, а целая экосистема вокруг llama.cpp. Файл хранит веса, словарь и конфигурацию архитектуры в одном переносимом контейнере, а собственные типы квантования заточены под эффективный инференс на CPU. По данным разбора AiManual, современные K-Quant-схемы вроде Q4_K_M теряют менее 2% качества относительно FP16 — на большинстве практических задач это не заметно.

Уместность формата хорошо видна на бытовых сценариях: если вы гоняете локальную модель на ноутбуке без дискретной видеокарты, альтернативы GGUF просто нет. Как в кейсе с локальной моделью SQL, которая обошла флагмана в тестах, — там решает не абсолютная точность, а возможность вообще запустить модель без облака.

На GPU-серверах правила меняются. AWQ учитывает не только веса, но и распределение активаций, поэтому при 4 битах держит смысл генерации лучше классического GPTQ — особенно на инструкционных моделях. Именно поэтому в разборе Serverflow AWQ называют следующим шагом после GPTQ, а не его заменой.

FP8 — история для тех, у кого есть H100, B200 или свежие ускорители. Формат экономит память и ускоряет матричные операции, но требует корректного пути исполнения в рантайме. Практический разбор форматов 2026 года прямо предупреждает: без проверки качества на FP8 можно получить красивый график токенов в секунду и сломанную логику ответов. По данным обзора НЬЮ-ССТ, итоговое правило простое: GGUF для CPU и Ollama, AWQ или GPTQ для GPU на vLLM, FP8 для флагманов — и обязательный замер качества на своих данных перед каждым из них.

Как читать маркировку Q4_K_M, Q5_K_S и IQ-типы квантов

Маркировка кванта в GGUF читается в три шага: число бит на вес, метод сжатия и вариант размера. Q4_K_M означает 4 бита, метод K-quant и средний вариант — типовой компромисс между размером файла и качеством генерации.

Первая цифра после буквы Q — базовое число бит на параметр. Дальше идёт метод сжатия: буква K означает K-quant, где веса бьются на суперблоки по 256 значений, а внутри работают подблоки со своими масштабами. Такая схема заметно точнее старого линейного Q4_0 при почти том же размере файла.

Последняя буква — самая непонятная. Суффиксы S (small), M (medium) и L (large) показывают, сколько тензоров поднято в более высокий разряд. В Q4_K_M ключевые слои внимания и часть полносвязных слоёв уходят в Q6_K, а в Q4_K_S всё остаётся честным Q4_K. Разница в размере — единицы процентов, в качестве — куда заметнее.

Отдельная ветка — IQ-кванты. Перед сжатием модель прогоняют по калибровочному корпусу и смотрят, какие связи реально влияют на выход. Важные веса получают больше бит, второстепенные сжимаются агрессивнее.

IQ4_XS — ровно такой случай. Он весит около 4,25 бита на параметр против 4,85 у Q4_K_M: файл меньше, а качество держится сопоставимое. Плата за это — калибровочная матрица значимости при сборке кванта и более скромная скорость на процессорах без AVX2, где часть инструкций уходит в медленный запасной путь.

Квант	Бит на вес	Размер для 70B	Типичный разброс качества
FP16	16	~140 ГБ	эталон
Q8_0	8,5	~74 ГБ	практически неотличимо
Q6_K	6,6	~57 ГБ	доли процента
Q5_K_M	5,7	~50 ГБ	около 1%
Q4_K_M	4,85	~42 ГБ	менее 2%
IQ4_XS	4,25	~37 ГБ	порядка 2%
Q3_K_M	3,9	~34 ГБ	заметная деградация логики
IQ2_M	2,7	~24 ГБ	ломается на сложных задачах

Размеры посчитаны как «число параметров × бит на вес ÷ 8» и у конкретных моделей гуляют на 1–3% из-за словаря и служебных тензоров. Оценка качества — усреднённая по публичным замерам; на вашей задаче цифры могут отличаться сильнее.

По данным разбора форматов GGUF и INT4, современные K-методы дают потерю качества меньше 2% на четырёх битах, и для большинства практических сценариев это незаметно. Но проверять на своих данных всё равно обязательно.

Как это выглядит в деле на домашнем железе, мы разбирали в материале про локальную модель SQL, которая обошла флагмана в тестах — там квантованные веса решали судьбу всей затеи.

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

Для 70B-модели переход с FP16 на 4-битное квантование сжимает веса примерно с 140 до 40–43 ГБ, то есть втрое с лишним, а потеря качества по практическим замерам обычно укладывается в 2%.

Дальше начинается арифметика, которая не врёт. Один параметр в FP16 занимает 2 байта — значит, 70 млрд × 2 = 140 ГБ. Восемь бит дают около 70 ГБ, четыре — порядка 35 ГБ. Реальный файл всегда тяжелее «чистой» математики, потому что метаданные и критичные тензоры в GGUF остаются в повышенной точности. Поэтому Q4_K_M у 70B весит не 35, а 40–43 ГБ.

И ещё один момент, который чаще всего ломает планы. Размер файла — это не требуемая память. К весам добавляется KV-кэш, и на длинном контексте он съедает гигабайты. У типичной 70B-архитектуры с 8 KV-головами и 80 слоями один токен контекста стоит около 0,3 МБ; на 8K это ~2,5 ГБ, а на 32K — уже ~10 ГБ.

Формат	Размер весов 70B	Скорость, ток/с (ориентир для 2×24 ГБ)	Память с контекстом 8K	Падение качества
FP16 / BF16	~140 ГБ	не, только выгрузка на CPU	~145 ГБ	эталон, 0
FP8	~70 ГБ	высокая, но нужен GPU с аппаратной поддержкой FP8	~73 ГБ	менее 0,5%
Q8_0 (INT8)	~70–75 ГБ	единицы, с выгрузкой на CPU	~75 ГБ	~0,5–1%
Q6_K	~57–60 ГБ	5–10	~60 ГБ	менее 1%
Q5_K_M	~48–50 ГБ	5–12	~51 ГБ	~1%
Q4_K_M	~40–43 ГБ	8–15	~43–45 ГБ	1–2%
AWQ INT4 (W4A16)	~38–40 ГБ	15–25 на vLLM	~42 ГБ	1–2%, точнее классического GPTQ на диалоговых моделях
GPTQ INT4	~35–38 ГБ	15–25 на vLLM	~40 ГБ	1–2%, на инструкциях чуть слабее AWQ
Q3_K_M	~33–35 ГБ	10–20	~36 ГБ	заметное: провалы в логике и коде
2-битные (IQ2 и аналоги)	~20–22 ГБ	15–25	~23 ГБ	сильное, для сложных задач не годится

Главный вывод таблицы не в килобайтах, а в том, что 4-битные K-кванты перестали быть компромиссом. По данным практического руководства по квантованию LLM, современные GGUF-форматы с K-Quant теряют менее 2% качества относительно FP16, и для большинства прикладных задач это незаметно.

Дальше выбор диктует не качество, а движок. GGUF живёт в llama.cpp, Ollama и LM Studio — это домашний и CPU-сценарий. AWQ и GPTQ нужны там, где стоит vLLM или серверный конвейер обработки запросов: у AWQ активационно-осознанное квантование даёт более высокую точность на диалоговых моделях, о чём пишут в разборе AWQ от Serverflow. А FP8 и FP4 — история для ускорителей уровня H100 и B200, на потребительском железе они пока либо не заведутся, либо не дадут выигрыша.

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

Практика: запуск 70B модели в llama.cpp и Ollama шаг за шагом

Запуск 70B-модели локально — это три шага: скачать GGUF-веса в квантовании Q4_K_M, поднять их через llama.cpp или Ollama и замерить скорость встроенными утилитами llama-bench либо флагом —verbose.

Сразу про железо, чтобы не терять вечер впустую. Файл Q4_K_M для 70B весит около 42–43 ГБ, плюс KV-кэш. Комфортно это живёт на 48 ГБ видеопамяти (две карты по 24 ГБ) или на Mac с 64 ГБ единой памяти. На одиночной карте с 24 ГБ придётся выгружать слои частично, и скорость упадёт в разы.

Шаг 1. Скачиваем веса

pip install -U "huggingface_hub[cli]"

hf download bartowski/Llama-3.3-70B-Instruct-GGUF \
  --include "*Q4_K_M.gguf" \
  --local-dir ./models

Утилита hf — это переименованный huggingface-cli. Часть репозиториев отдаёт веса нарезанными на куски вида ...-00001-of-00002.gguf. Их склеивают в один файл командой llama-gguf-split --merge, иначе движок просто не увидит модель.

Шаг 2. Запускаем в llama.cpp

llama-cli -m ./models/Llama-3.3-70B-Instruct-Q4_K_M.gguf \
  -ngl 99 --ctx-size 8192 -t 8 \
  -p "Объясни разницу между Q4_K_M и Q5_K_M"

Ключ -ngl 99 отправляет в ускорение все слои, --ctx-size задаёт окно контекста. Если карт две, добавьте --tensor-split 1,1 и --split-mode layer — так веса разложатся по устройствам ровно.

Шаг 3. Ollama — то же самое, но в одну строку

ollama pull llama3.3:70b-instruct-q4_K_M
ollama run llama3.3:70b-instruct-q4_K_M

Ollama сама подберёт раскладку между видеопамятью и процессором, а покажет её команда ollama ps. Нужен свой файл — заведите Modelfile с директивой FROM /путь/к/модели.gguf.

Шаг 4. Замеряем скорость

llama-bench -m model.gguf -p 512 -n 128 -r 3

Утилита вернёт два честных числа: pp512 — скорость обработки промпта и tg128 — скорость генерации, токенов в секунду. В Ollama тот же замер даёт флаг --verbose, где это строки «prompt eval rate» и «eval rate».

Квантование	Размер 70B	Под что подходит
Q4_K_M	~42–43 ГБ	базовый выбор для 48 ГБ видеопамяти и 64 ГБ единой памяти
Q5_K_M	~50 ГБ	чуть выше точность, нужен запас памяти
Q8_0	~75 ГБ	почти FP16, но дома уже тесно
FP16	~140 ГБ	эталон для сравнения, не для ноутбука

По данным разбора на AiManual, современные K-кванты теряют менее 2% качества относительно FP16 — для большинства задач это незаметно. Но замер на своих данных никто не отменял: прогоните десяток типовых запросов и сравните ответы с FP16 глазами, а не по цифре в названии файла.

Если 70B на домашнем железе всё ещё тяжеловата, начните с моделей меньшего размера — в материале про локальную модель SQL, которая обошла флагмана в тестах, показан похожий сценарий для компактных весов.

GPU-инференс на vLLM: AWQ против FP8 на одном ускорителе

На одной видеокарте vLLM поднимает 70B-модель либо в AWQ, либо в FP8. Веса AWQ занимают около 35 ГБ, FP8 — примерно 70 ГБ. Отсюда развилка по железу: int4 стартует на 48 ГБ, FP8 требует 80 ГБ и ускорителя Ada или Hopper.

Считаем на пальцах. 70 млрд параметров при 4 битах дают 35 ГБ (в гибибайтах ≈32,6), при 8 битах — уже 70 ГБ, а в FP16 — 140 ГБ. Но веса это только часть уравнения: сверху ложатся KV-кэш, активации и буферы CUDA-графов. Именно поэтому 48-гигабайтная карта тянет 70B в AWQ и гарантированно падает на FP8.

Параметр	AWQ (W4A16)	FP8 (W8A8)
Битность весов	4	8
Вес модели 70B	≈35 ГБ	≈70 ГБ
Минимум видеопамяти	48 ГБ	80 ГБ
Рабочие архитектуры	Ampere, Ada, Hopper	Ada, Hopper
Ядра в vLLM	awq_marlin	fp8, fp8_marlin

Конфигурация для int4 выглядит буднично:

python -m vllm.entrypoints.openai.api_server \
  --model /models/your-org/70b-awq \
  --quantization awq_marlin \
  --dtype float16 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.92 \
  --tensor-parallel-size 1

Вариант под FP8 отличается парой флагов, зато требует соответствующего железа:

python -m vllm.entrypoints.openai.api_server \
  --model /models/your-org/70b-fp8 \
  --quantization fp8 \
  --kv-cache-dtype fp8 \
  --max-model-len 16384 \
  --gpu-memory-utilization 0.90

Теперь про пропускную способность под батчами. На одиночном запросе декодирование упирается в пропускную способность видеопамяти: чем меньше байт весов читает ускоритель на каждый токен, тем выше скорость. Здесь AWQ отыгрывает заметно.

С ростом батча узкое горлышко смещается к вычислительным блокам, и более быстрые FP8-ядра начинают сокращать разрыв. Плюс int4 освобождает память под KV-кэш, а это прямой путь к большему числу одновременных сессий в continuous batching. Что выгоднее в вашем профиле нагрузки, покажет только замер: универсальной цифры «на столько-то процентов» не существует.

Частые ошибки загрузки весов в vLLM выглядят так:

• «Unknown quantization method» — флаг есть, а сборка vLLM старая. Обновите пакет, ядро awq_marlin появилось не сразу.
• Нет quantization_config в config.json — автодетект молчит, и модель грузится как обычная, а затем падает на несовпадении размеров тензоров. Указывайте --quantization руками.
• GGUF в vLLM — поддержка ограничена, это формат экосистемы llama.cpp и Ollama. Для GPU-сервера берите AWQ или GPTQ.
• Скачан не весь набор шардов — ошибка вида «Cannot find the file» лечится повторной загрузкой репозитория целиком.
• Не влез KV-кэш — уменьшайте --max-model-len, а не надейтесь на чудо.

Если ускорителя под рукой нет вовсе, взгляните на наш разбор про локальную модель, которая обошла флагмана в тестах. А за деталями активационно-осознанного квантования и того, почему int4 обходит классический GPTQ на диалоговых моделях, идите к разбору AWQ от Serverflow.

Как замерить качество кванта на своих данных и не потерять точность

Качество кванта проверяют на своём наборе из 30–100 живых промптов: сравнивают ответы INT4-версии с FP16 по метрикам задачи, а не по перплексии, и держат расхождение в пределах 1–3%.

Перплексия для диалоговых моделей — плохой судья. Она усредняет всё подряд и почти не реагирует на то, что для вас критично: сломанный JSON, потерянное имя клиента, ответ не на русском.

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

Тип задачи	Что сравниваем	Рабочий порог расхождения
Извлечение сущностей, JSON	Доля полностью корректных структур	до 1 процентного пункта к FP16
Ответы по базе знаний	Доля фактически верных ответов	1–3% относительного падения
Многошаговые рассуждения	Доля верных цепочек вывода	до 3–5% — иначе меняем квант
Формат и роль	Доля валидных ответов, доля отказов, смены языка, повторы	любое падение — красный флаг
Скорость и память	Токены в секунду, время до первого токена, объём видеопамяти	не качество, но фиксируем всегда

Единого отраслевого порога не существует — он выводится из цены ошибки. Для чат-бота с консультациями 3% потерянных фактов терпимо, для парсера счетов даже один процент битых структур означает ручной разбор.

По данным разбора методов квантования, современные GGUF-схемы с K-Quant на 4 битах часто теряют менее 2% качества относительно FP16, и для большинства практических задач это незаметно. А в блоге Serverflow отмечают, что AWQ при INT4 обычно точнее классического GPTQ именно на instruction и диалоговых моделях.

Диалоговым моделям нужны свои метрики: доля валидных ответов, доля отказов, средняя длина, повторы, соблюдение персоны. Плюс парные слепые сравнения — один промпт, два ответа, оценщик не знает, где FP16.

И не забывайте про вторую половину уравнения: токены в секунду и потребление памяти. Иногда лишний процент точности не стоит просадки скорости вдвое. Хороший пример того, как цифры обретают смысл только на своём железе и своём наборе задач, — тесты локальной модели SQL на ноутбуке.

В сухом остатке: до 2% расхождения — берём квант в работу, 3–5% — разбираемся по типам ошибок, больше — ищем другую схему или другую модель.

KV-кэш и длинный контекст: скрытый пожиратель видеопамяти

KV-кэш хранит ключи и значения всех предыдущих токенов и растёт линейно с длиной контекста: у 70B-модели с GQA это примерно 320 КиБ на токен в FP16, то есть 10 ГиБ на 32 тысячи токенов.

Механика простая. При генерации каждый новый токен «оглядывается» на все предыдущие, и чтобы не пересчитывать их заново на каждом шаге, движок складывает промежуточные тензоры K и V в память. Освобождается она только после завершения генерации — не после ответа в чате, а именно после закрытия сессии.

Формула бюджета выглядит так: 2 × число слоёв × число KV-голов × размер головы × 2 байта. Для типовой 70B с 80 слоями, 8 KV-головами и головой в 128 элементов получается те самые 320 КиБ на токен. Если модель собрана на классическом многоголовом внимании без GQA, множьте на восемь — и это уже другой разговор про железо.

Длина контекста	FP16	Q8_0	Q4_0
8 192 токена	2,5 ГиБ	1,3 ГиБ	0,7 ГиБ
32 768 токенов	10 ГиБ	5,3 ГиБ	2,8 ГиБ
65 536 токенов	20 ГиБ	10,6 ГиБ	5,6 ГиБ
131 072 токена	40 ГиБ	21,3 ГиБ	11,3 ГиБ

Теперь про квантование самого кэша. В llama.cpp это делается двумя флагами: --cache-type-k q8_0 --cache-type-v q8_0, и обязательно вместе с --flash-attn — без него квантование V просто не включится. В vLLM аналог называется --kv-cache-dtype fp8 и работает на свежих ускорителях.

Отдельно про честность цифр. Тезис «4-битное квантование теряет менее 2% качества» из обзоров относится к весам модели, а не к KV-кэшу — это разные истории, и переносить одну оценку на другую некорректно. Данные по потере качества при квантовании кэша сильно зависят от модели и длины контекста, поэтому замер на своих данных до боевого запуска обязателен.

Рабочая конфигурация для домашнего узла на 48 ГБ: 70B в Q4_K_M, контекст 32k, K и V в Q8_0, включённый flash attention. Это даёт около 5 ГиБ под кэш и оставляет запас под буферы и пакетную обработку. Если нужен контекст 128k, честнее взять модель с архитектурой, сжимающей кэш на уровне внимания (семейство DeepSeek с его MLA), чем выжимать FP16 на потребительской карте.

Подробный разбор типов квантования и их влияния на инференс есть в материале LLM-инференс в продакшене: квантование и KV-кэш, а базовые оценки потерь качества — в обзоре AiManual по квантованию LLM. Из наших прошлых разборов пригодится история про локальную модель SQL на ноутбуке — там как раз видно, как настройки памяти решают, поедет модель или нет.

Подводные камни: деградация на длинном контексте и ложная экономия

Самый компактный квант почти всегда проигрывает на длинном контексте и на задачах, где нужна точность: общие замеры этого не показывают, потому что 4 бита бьют не по среднему качеству, а по «хвостам» поведения модели.

По данным разбора на AiManual, современные схемы с K-квантованием к началу 2026 года теряли менее 2% качества относительно FP16. Звучит как разрешение брать Q4 и не думать.

Но эти проценты собраны на коротких вопросах-ответах. А 70B-модель вы тащите на потребительское железо ради длинных документов, больших файлов кода и многошаговых рассуждений. Вот там и вылезает разница.

Отдельная ловушка — арифметика памяти. Вы ужимаете веса 70B с 140 ГБ в FP16 до ~42 ГБ в Q4_K_M и радуетесь освободившимся ~98 ГБ. Но память ест не только вес модели.

Кэш ключей и значений растёт линейно с длиной контекста. Для типовой 70B-архитектуры с групповым вниманием это порядка 0,3 МБ на токен. На 128 тыс. токенов набегает около 39 ГБ — и половина вашей экономии испаряется прямо в диалоге.

Отсюда второй смысл «ложной экономии»: люди ужимают веса, а потом получают падение скорости на длинных запросах и ошибки при переполнении контекста. Лечится это квантованием самого кэша (в 8 бит) и честным лимитом длины, а не выбором ещё более жёсткого кванта весов.

Полезный ориентир: GGUF с K-квантами — для CPU и локальных сборок, AWQ и GPTQ — для GPU-инференса на vLLM. Про требования к железу и подбор конфигурации мы подробно разбирали в материале про локальную модель SQL на ноутбуке — там как раз про то, где компактный квант вытягивает, а где нет.

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

Инженерная защита данных при локальном инференсе

Локальный инференс защищает данные только при трёх условиях: модель не отправляет телеметрию, журналы обезличены, а исходящий трафик проходит через управляемый шлюз.

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

Проверка занимает пять минут. Задайте модели вопрос с меткой-маркером вроде «тестовый договор № 000» и поищите эту строку по каталогам с журналами и кэшем. Находится чаще, чем хочется.

Базовая схема маскирования выглядит так. Модуль распознавания сущностей вырезает из текста имена, телефоны, почту, номера счетов и адреса, подставляя вместо них стабильные маркеры вида «PERSON_1» и «PHONE_2». Модель работает с обезличенным текстом, а обратная замена происходит в приложении, которое держит карту соответствий у себя.

Карту лучше хранить в памяти процесса и уничтожать после завершения сессии. Регулярные выражения уверенно ловят телефоны и почту, но спотыкаются на именах в косвенных падежах и на адресах — здесь нужен нормальный распознаватель сущностей, а не набор шаблонов.

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

Если внешний API всё же нужен, перед ним ставят шлюз, который проверяет запросы и ведёт журнал. Тогда решение о том, что уходит наружу, принимает инфраструктура, а не разработчик в спешке перед демонстрацией.

Канал утечки	Что попадает наружу	Инженерная мера
Журналы приложения	Полные подсказки и ответы	Отключить запись содержимого, оставить метаданные
Телеметрия клиента	Версия, окружение, иногда тексты	Блокировка доменов на уровне шлюза
Кэш ключей и значений	Фрагменты диалога	Хранить в памяти или шифровать том
Внешний API	Обезличенный текст	Обязательное маскирование перед отправкой

Отдельная головная боль — агенты с доступом к базам. Подключение ИИ к корпоративным хранилищам удобно, но именно там проще всего потерять контроль над тем, какие строки уезжают в подсказку; типовые грабли мы разбирали в материале про MCP-протокол и корпоративные базы данных. Технические детали по кэшу и его влиянию на память подробно разобраны в разборе квантования LLM от AiManual.

Правовые нормы динамичны и требуют предварительной проверки юристами компании. Инженерная часть неизменна: минимум данных на входе, отсутствие лишних исходящих каналов и журналы, которые не превращаются во вторую копию базы.

Часто задаваемые вопросы (FAQ)