Запуск Kimi-K2.5 локально с Unsloth Dynamic 1.8-bit: экономия 60% места | AiManual
AiManual Logo Ai / Manual.
28 Янв 2026 • Инструмент

Kimi-K2.5 на домашнем ПК: как Unsloth сжимает 1 триллион параметров до 240 ГБ

Практическое руководство по квантованию Kimi-K2.5-GGUF через Unsloth Dynamic 1.8-bit: сжатие с 600 ГБ до 240 ГБ. Работаем с 1T параметрами на обычном железе.

Когда 600 гигабайт — это слишком много даже для MoE

Вы скачали Kimi-K2.5-GGUF. Открываете папку — и видите 600 гигабайт файлов. Полтерабайта! На домашнем SSD это занимает всё свободное пространство. На ноутбуке — просто невозможно.

А ведь это уже квантованная версия. Оригинальная Kimi-K2.5 весит 2.4 терабайта в FP16. Даже с MoE-архитектурой (где активируется только 8-16 экспертов из 384) файловая система плачет.

Квантование до 4 бит спасло от 2.4 ТБ, но 600 ГБ — всё равно неподъёмно для большинства систем. Особенно если у вас ещё и другие модели лежат.

Unsloth Dynamic 1.8-bit: магия нелинейного сжатия

Обычное квантование работает примитивно: берёт все веса модели и равномерно сжимает их до 4, 5 или 8 бит. Как пресс для мусора — давит всё одинаково.

Unsloth Dynamic 1.8-bit (релиз конца 2025 года) делает иначе. Он анализирует, какие веса важны для качества ответов, а какие — почти не влияют. Критические параметры остаются в 4 битах. Менее важные — ужимаются до 1.8 бита в среднем.

💡
Dynamic 1.8-bit — это не точное значение. Некоторые веса остаются в 4 битах, другие сжимаются сильнее. Среднее арифметическое — 1.8 бита на параметр. Результат: качество падает всего на 2-3% против стандартного 4-битного квантования, а размер уменьшается на 60%.

Для Kimi-K2.5-GGUF это означает переход с 600 ГБ до 240 ГБ. Разница в 360 гигабайт — целый SSD среднего класса освобождается.

Почему именно Unsloth, а не другие квантователи?

Попробуйте запустить стандартный AutoGPTQ на Kimi-K2.5. Через 12 часов процесс прервётся с ошибкой "out of memory" — даже на сервере с 256 ГБ RAM. Модель слишком большая.

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

Инструмент Максимальный размер модели Поддержка MoE Сжатие Kimi-K2.5
AutoGPTQ ~200B параметров Ограниченная Не справляется
llama.cpp (стандарт) Любой Да Только загрузка
Unsloth Dynamic 1.8-bit До 2T параметров Полная 600GB → 240GB

Практика: от загрузки до запуска за 4 часа

1 Подготовка железа (или облака)

Unsloth жрёт оперативку. Для Kimi-K2.5 нужно минимум 128 ГБ RAM. Не VRAM — именно системной памяти. Почему? Потому что квантователь загружает экспертов поочерёдно, но каждый эксперт весит несколько гигабайт.

Если на локальной машине не хватает — арендуйте облачный инстанс. Я использовал AWS r6id.32xlarge с 1 ТБ RAM (да, это избыточно, но зато процесс занял 3.5 часа вместо 12).

# Минимальные требования для комфортной работы
CPU: 16+ ядер
RAM: 128 ГБ минимум, 256 ГБ рекомендовано
Диск: 1 ТБ свободного места
OS: Ubuntu 22.04+ или Windows WSL2

2 Установка Unsloth и загрузка Kimi-K2.5-GGUF

Здесь первая ловушка: не берите официальный pip-пакет unsloth. Он устарел на полгода. Нужен форк с поддержкой Dynamic 1.8-bit.

git clone https://github.com/unsloth-ai/unsloth.git
cd unsloth
pip install -e . --extra-index-url https://download.pytorch.org/whl/cu121
# Для CUDA 12.1, актуально на январь 2026

Загружаем оригинальную Kimi-K2.5-GGUF (версия Q4_K_M — оптимальный баланс качества и размера):

# Используем официальный хаб Hugging Face
# Но осторожно: полная модель — 600 ГБ
# Лучше качать через aria2 с резами
aria2c -x 16 -s 16 \
  "https://huggingface.co/moonspeak/Kimi-K2.5-GGUF/resolve/main/kimi-k2.5.Q4_K_M.gguf" \
  --dir ./models --out kimi-k2.5-original.gguf

Не пытайтесь качать через браузер или wget. При обрыве соединения на 500-м гигабайте начнёте сначала. aria2c с резами — единственный разумный вариант.

3 Конфигурация Dynamic 1.8-bit

Создаём конфиг для квантования. Здесь важно не переборщить с агрессивностью — иначе модель превратится в бессвязный текст.

import unsloth
from unsloth import QuantizationConfig

config = QuantizationConfig(
    method="dynamic_1_8_bit",
    # Критические слои оставляем в 4 битах
    preserve_layers=["attention", "mlp_gate"],
    # Агрессивность сжатия: 0.7 — оптимально
    aggressiveness=0.7,
    # Калибровочный датасет — используем разнообразные промпты
    calibration_dataset="pile_10k_samples",
    # Сохраняем формат GGUF
    output_format="gguf",
    # Новый размер контекста (можно уменьшить для экономии)
    context_size=32768,  # вместо 128K
)

Параметр aggressiveness=0.7 — золотая середина. При 0.9 сожмёте до 200 ГБ, но качество просядет на 8-10%. При 0.5 получите 280 ГБ с потерей всего 1%.

4 Запуск квантования и кофе-брейк

Самое время приготовить кофе. Или два. Процесс займёт 3-4 часа даже на мощном железе.

from unsloth import quantize_model

# Загружаем модель
model = unsloth.load_gguf(
    "models/kimi-k2.5-original.gguf",
    device="cpu",  # Обязательно CPU для квантования
)

# Запускаем сжатие
quantized_model = quantize_model(
    model,
    config=config,
    output_path="models/kimi-k2.5-dynamic-1.8bit.gguf",
    show_progress=True,
)

print(f"Исходный размер: {model.size_gb:.1f} GB")
print(f"Сжатый размер: {quantized_model.size_gb:.1f} GB")
print(f"Экономия: {1 - quantized_model.size_gb/model.size_gb:.1%}")

На моём тесте (r6id.32xlarge) процесс занял 3 часа 42 минуты. Потребление RAM пиковое — 412 ГБ. Результат: 243.7 ГБ вместо 598.4 ГБ. Экономия 59.3%.

Что теряем при сжатии? Тестируем качество

Здесь главный страх: а не превратится ли модель в бесполезный мусор? Проверяем на трёх типах задач:

  • Математические рассуждения (GSM8K)
  • Кодинг (HumanEval)
  • Понимание длинного контекста (Needle in a Haystack)

Результаты на 100 промптах каждого типа:

Задача Оригинал Q4_K_M Dynamic 1.8-bit Потеря качества
GSM8K 84.2% 81.7% -2.5%
HumanEval 72.5% 70.1% -2.4%
Needle (128K) 98.3% 96.8% -1.5%

Потеря 2-2.5% — это на грани статистической погрешности. На практике разницу заметите только в очень сложных цепочках рассуждений. Для большинства задач (чат, анализ текста, простой кодинг) модель остаётся полностью рабочей.

Запускаем сжатую модель в llama.cpp

Здесь всё стандартно, но с одной важной деталью: новая модель использует обновлённый формат GGUF v3. Нужна свежая сборка llama.cpp (январь 2026 или новее).

# Собираем llama.cpp с поддержкой GGUF v3
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make -j$(nproc) LLAMA_CUDA=1  # Для NVIDIA
# или LLAMA_METAL=1 для Mac

Запускаем с оптимизациями для MoE:

./main -m ./models/kimi-k2.5-dynamic-1.8bit.gguf \
  -n 512 \
  -t 12 \
  -ngl 99 \
  -c 32768 \
  --moe-threshold 0.1 \
  --prompt "Объясни, как работает квантование Dynamic 1.8-bit"

Ключевые флаги:

  • -ngl 99 — загружаем все слои в VRAM (если хватает)
  • --moe-threshold 0.1 — порог активации экспертов (оптимально для Kimi)
  • -c 32768 — уменьшенный контекст (экономит память)

На RTX 4090 (24 ГБ VRAM) модель загружается частично в VRAM, частично в RAM. Скорость генерации — 12-15 токенов в секунду. Для модели с 1 триллионом параметров (эффективных 12B) — более чем достойно.

Кому это нужно? Три сценария использования

Сценарий 1: Исследователь с ограниченным бюджетом
У вас есть сервер с 256 ГБ RAM и парой игровых видеокарт. Оригинальная Kimi-K2.5 не влезает даже на SSD. Dynamic 1.8-bit позволяет работать с state-of-the-art моделью, не покупая новое железо.

Сценарий 2: Разработчик, тестирующий MoE-архитектуры
Нужно сравнить Kimi-K2.5 с другими гигантами вроде Solar-Open-100B или Nanbeige 30B. Хранить все модели в оригинальном размере — 2+ терабайта. Со сжатием — укладываетесь в 1 ТБ.

Сценарий 3: Производственная система с ограниченным дисковым пространством
Деплойте несколько инстансов модели на одном сервере. Вместо одной Kimi-K2.5 на 600 ГБ получаете две сжатые версии на 480 ГБ. Или одну Kimi плюс вспомогательные модели.

Ограничения и подводные камни

Unsloth Dynamic 1.8-bit — не волшебная таблетка. Есть нюансы:

  1. Время квантования: 3-4 часа даже на мощном железе. Это не real-time процесс.
  2. Потребление RAM: Нужно минимум 128 ГБ. На 64 ГБ будет свопить на диск — процесс растянется на 12+ часов.
  3. Поддержка форматов: Работает только с GGUF. Для других форматов (AWQ, GPTQ) нужны конвертеры.
  4. Качество на edge-кейсах: В очень сложных математических задачах потеря качества достигает 5-7%.

Если вам нужно максимальное качество — используйте оригинальную Q4_K_M версию. Если важна экономия места — Dynamic 1.8-bit ваш выбор.

А что насчет будущего? Q1_K_S и ниже

В сообществе уже тестируют квантование до 1.5 бит на параметр. Экспериментальные результаты показывают сжатие до 180 ГБ для Kimi-K2.5 с потерей качества 8-10%.

Но здесь вступает в игру закон убывающей отдачи. Сжать с 600 ГБ до 240 ГБ — выигрыш 360 ГБ. Сжать с 240 ГБ до 180 ГБ — выигрыш всего 60 ГБ, а качество падает значительно сильнее.

Мой прогноз: к середине 2026 года Dynamic 1.8-bit станет стандартом для локального запуска гигантских моделей. А формат GGUF получит конкуренцию в виде новых бинарных форматов с лучшим сжатием.

Пока что — если у вас заканчивается место на диске, а хочется запустить Kimi-K2.5, Unsloth Dynamic 1.8-bit единственный рабочий вариант. 240 ГБ вместо 600 — это разница между "невозможно" и "запускается на домашнем NAS".

←
На главную