Tencent заявила о сжатии модели Hy4-preview примерно с 1.5 ТБ до 200 ГБ в формате GGUF. По представленному описанию, сжатая версия сохраняет около 98% исходной производительности. Для локальных LLM это означает заметно меньшие требования к диску и потенциально более доступный запуск.
Есть существенная оговорка: в доступных материалах нет проверяемых сведений о точном типе квантизации, исходном файле модели, используемом движке, тестовом наборе и методике расчёта 98%. Поэтому цифры 1.5 ТБ, 200 ГБ и 98% корректно трактовать как заявленные показатели, а не как подтверждённый независимым тестом результат.
Сжатая Hy4-preview выглядит интересно для владельцев локальных AI-систем, но размер GGUF сам по себе не отвечает на вопрос о запуске. Нужно учитывать VRAM, оперативную память, KV-кэш, рабочие буферы, пропускную способность памяти и поддержку конкретного рантайма.
Что заявлено о Tencent Hy4-preview в GGUF
Суть заявления сводится к трём параметрам: исходный размер модели около 1.5 ТБ, размер версии GGUF около 200 ГБ и сохранение примерно 98% производительности. Разница между исходным и сжатым вариантом составляет около 7,5 раза по объёму файла.
Для пользователя локальной LLM это снижает требования к дисковому пространству. Загрузка модели на сервер или домашний AI-компьютер становится практичнее, а часть вычислений можно распределять между GPU и CPU. При этом модель объёмом 200 ГБ всё равно относится к тяжёлым решениям и не превращается в вариант для обычной видеокарты.
98% производительности - не то же самое, что 98% качества на любой задаче
Производительность может означать скорость prefill, скорость decode, задержку до первого токена или совокупный результат нескольких тестов. Качество ответа измеряется иначе: точностью, полнотой, соблюдением формата, корректностью кода и устойчивостью рассуждений.
Средний показатель 98% способен скрывать более заметные провалы на отдельных задачах. Ошибка в одном промежуточном вычислении испортит весь математический ответ. Небольшое изменение вероятностей токенов может привести к синтаксически неверному коду или нарушить требование к формату вывода.
Наиболее чувствительными сценариями считаются генерация кода, математические вычисления и многошаговые рассуждения. Для обычного диалога, суммаризации или классификации разница может оказаться менее заметной, но это нужно проверять на конкретной модели и фиксированном наборе запросов.
Каких данных пока не хватает для окончательного вывода
Для полноценной проверки заявления нужны:
- исходный файл Hy4-preview и его точный размер;
- тип и параметры квантизации;
- commit-идентификатор или релиз GGUF;
- название и версия движка запуска;
- модель GPU, объём VRAM и объём оперативной памяти;
- настройки offload и длина контекста;
- тестовый набор и критерии оценки качества;
- скорость prefill, скорость decode и задержка до первого токена;
- логи запуска с фиксацией пикового потребления памяти и отсутствия OOM.
Без этих сведений нельзя определить, что именно означает показатель 98%: скорость, средний балл качества или комбинацию нескольких метрик.
Как квантизация уменьшает Hy4-preview с 1.5 ТБ до 200 ГБ
Квантизация переводит параметры модели в представление с меньшей разрядностью. Вместо хранения каждого веса в формате с высокой точностью применяются более компактные числовые представления. Это уменьшает объём весов на диске и количество памяти, необходимое для их обработки.
GGUF выступает контейнером для распространения локальной модели. В него входят веса и служебные метаданные, которые нужны совместимому движку. Сам формат не определяет качество квантизации: итог зависит от конкретного варианта файла и выбранных параметров.
В контексте Hy4-preview слово «сжатие» скорее всего описывает изменение представления весов с возможной потерей точности. Архивирование без потерь не смогло бы уменьшить объём параметров в несколько раз при сохранении полноценной структуры модели.
Что именно экономится: веса, VRAM и дисковое пространство
Экономия проявляется на нескольких уровнях:
- Диск. Файл GGUF занимает около 200 ГБ вместо заявленных 1.5 ТБ.
- Оперативная память. При CPU-инференсе движку требуется загрузить веса и выделить память под контекст и рабочие операции.
- VRAM. Сжатые веса занимают меньше места при выгрузке на видеокарту.
- KV-кэш. Освободившаяся память может использоваться для хранения состояния длинного контекста.
- Рабочие буферы. Движку нужен запас памяти для вычислений, промежуточных тензоров и служебных операций.
Размер файла не равен полному потреблению памяти во время генерации. Чем длиннее контекст и чем больше параллельных запросов, тем сильнее растёт расход на KV-кэш и буферы.
Почему меньший GGUF не гарантирует запуск на одной видеокарте
Видеокарта с 24 ГБ VRAM не сможет разместить целиком файл размером около 200 ГБ. Даже если часть весов загружается на GPU, оставшийся объём должен находиться в оперативной памяти и передаваться через системную шину.
Такой режим называют offload. Он позволяет запустить модель при нехватке VRAM, но скорость зависит от того, как часто вычисления обращаются к памяти CPU. При недостаточной пропускной способности интерактивная генерация может стать неудобной.
Для большой модели потребуется сочетание GPU, RAM и диска. Поддержка конкретного режима зависит от движка, архитектуры Hy4-preview и настроек загрузки.
Что нельзя утверждать без параметров квантизации
Нельзя достоверно назвать уровень точности, скорость на конкретной видеокарте или минимальный объём памяти. Один GGUF размером 200 ГБ может использовать другой баланс точности слоёв, чем альтернативный файл того же объёма.
Поэтому обозначения вроде Q2, Q3, Q4 или IQ нельзя приписывать Hy4-preview без карточки конкретного файла. Практический компромисс определяется сочетанием размера, качества, скорости, поддержки движка и длины контекста.
Для сравнения подходов полезен разбор [1-битного квантирования Hy3-GGUF](https://ai-manual.ru/article/testirovanie-1-bitnogo-kvantirovaniya-iq1m-modeli-hy3-gguf-naskolko-sohranyaetsya-kachestvo-pri-szhatii-do-89-gb/), где отдельно показано, почему малый размер не отменяет проверку на реальных задачах.
Запуск Hy4-preview на 24 ГБ VRAM и на CPU
Сценарии запуска нужно разделять по архитектуре системы. Одна видеокарта, несколько GPU и CPU-инференс предъявляют разные требования к памяти и пропускной способности.
Конфигурация с 24 ГБ VRAM: что реально меняет квантизация
Квантизация уменьшает объём весов, который можно разместить на видеокарте, и освобождает часть VRAM под KV-кэш и рабочие буферы. Но Hy4-preview в файле около 200 ГБ всё равно не помещается в 24 ГБ целиком.
Реалистичный сценарий предполагает частичную выгрузку слоёв на GPU и хранение остального объёма в RAM. Перед запуском нужно проверить, хватает ли оперативной памяти с запасом. Недостаток RAM приведёт к обращению к диску, ошибкам загрузки или резкому падению скорости.
Рабочую конфигурацию следует оценивать по пиковому потреблению памяти на реальном промпте. Короткий тест на старте не показывает расход при длинном контексте.
Несколько GPU и tensor parallelism
Несколько видеокарт позволяют распределить веса между устройствами. Tensor parallelism делит вычисления между GPU, но требует поддержки со стороны движка и подходящей топологии соединения.
Итоговая скорость зависит от объёма памяти каждой карты, межсоединения, загрузки устройств и баланса между частями модели. Связка видеокарт с разной производительностью может простаивать на этапе синхронизации.
Суммарный объём VRAM не даёт автоматической гарантии запуска. Нужно проверить, умеет ли выбранный рантайм загружать конкретный GGUF и распределять его слои или тензоры между GPU.
CPU-запуск: доступность против скорости
На CPU модель может использовать системную RAM вместо VRAM. Для файла около 200 ГБ потребуется не менее сопоставимого объёма свободной памяти, а для контекста и рабочих буферов нужен дополнительный запас.
Главным ограничением становится пропускная способность памяти. При каждом шаге decode процессор и движок обращаются к большим массивам весов, поэтому техническая загрузка модели не означает комфортный диалог в реальном времени.
CPU-инференс может подойти для фоновых задач, пакетной обработки, экспериментов и редких запросов. Для интерактивной работы нужно отдельно измерить скорость decode и задержку первого токена.
Проверка перед запуском: память, offload и стабильность
- Зафиксируйте размер GGUF, тип квантизации и версию файла.
- Запишите доступные объёмы VRAM и RAM до запуска.
- Укажите движок, параметры offload и число GPU-слоёв.
- Проверьте несколько длин контекста, включая рабочую.
- Измерьте пиковое потребление VRAM и RAM.
- Запишите скорость prefill, задержку до первого токена и скорость decode.
- Проверьте отсутствие OOM на реальном рабочем промпте, а не только на коротком тесте.
Для длинного контекста дополнительно нужны retrieval-тесты. Спрячьте контрольные факты в начале, середине и конце промпта, затем проверьте, извлекает ли их модель после успешного prefill.
Где потеря качества будет заметнее всего
Влияние квантизации зависит от типа запроса, длины контекста и цены ошибки. Одинаковый средний результат может быть приемлемым для суммаризации и неудовлетворительным для генерации рабочего кода.
Генерация и анализ кода
Проверяйте синтаксическую корректность, соблюдение требований, работу с несколькими файлами и способность исправлять собственные ошибки. Для репозитория полезно использовать фиксированный набор задач: добавить функцию, изменить API, написать тесты и объяснить причину сбоя.
Маленькая ошибка в условии или имени переменной способна сделать патч непригодным. Поэтому сравнивать нужно долю решений, которые проходят тесты, а не только субъективную связность объяснения.
Математика и многошаговые рассуждения
В математике оценивайте промежуточные вычисления и финальный ответ отдельно. В рассуждениях проверяйте устойчивость цепочки зависимых шагов и долю корректных решений на повторных запусках.
Заявленные 2% потери могут проявляться здесь непропорционально заметно: одна ошибка в начале цепочки меняет все последующие выводы. Без тестового набора нельзя утверждать, насколько это касается Hy4-preview.
RAG и повседневные запросы
Для RAG проверьте, отвечает ли модель по переданному контексту, не добавляет ли неподтверждённые сведения и сохраняет ли нужный формат. Для суммаризации измеряйте полноту фактов и отсутствие искажений.
В обычном диалоге часто важны стабильность, скорость и стоимость запуска. Однако длинный контекст нужно тестировать отдельно: max context в конфигурации не доказывает, что модель успешно обработает такую длину и найдёт информацию в любой её части.
Как проверить заявление о 98% производительности
Проверка должна разделять скорость инференса и качество ответов. Сравнивать исходную и сжатую версии следует на одном оборудовании, в одном движке, с одинаковыми промптами и настройками генерации.
Что измерять при инференсе
- фактическую длину токенизированного промпта;
- скорость prefill в токенах в секунду;
- задержку до первого токена;
- скорость decode в токенах в секунду;
- пиковое потребление VRAM;
- потребление RAM;
- время загрузки модели;
- наличие OOM и других ошибок;
- стабильность результата при повторных запусках.
Для длинного контекста фиксируйте успешность prefill, генерацию после него и сохранение информации по всей последовательности. Одного значения максимального окна недостаточно.
Как проверять качество на собственных задачах
Соберите небольшой неизменяемый набор запросов по пяти категориям: кодинг, математика, многошаговые задачи, RAG и обычный диалог. Для каждого запроса заранее задайте критерии: правильность, полнота, формат и необходимость ручной доработки.
Повторите каждый тест несколько раз с одинаковыми параметрами sampling. Сравнивайте ответы по заранее выбранным правилам, а не по впечатлению от одного удачного или неудачного примера.
Публиковать вывод о «98%» корректно только вместе с описанием набора тестов, оборудования и метрик.
Почему max context не доказывает работу с длинным контекстом
Параметр max context сообщает допустимый предел конфигурации. Он не подтверждает успешный prefill, отсутствие переполнения памяти, приемлемую скорость decode и точное извлечение фактов после длинной последовательности.
KV-кэш растёт вместе с длиной контекста и занимает память во время генерации. Поэтому проверка должна включать реальные промпты, замеры VRAM, latency до первого токена и retrieval по началу, середине и концу текста.
Расширение окна через YaRN или другой механизм требует отдельной проверки параметров и совместимости. Без commit-идентификатора, логов запуска и фактических замеров стабильность такой конфигурации подтверждать нельзя.
С чем сравнивать Hy4-preview в формате GGUF
Сравнивать локальные LLM нужно по единой матрице. Один размер файла не показывает, сколько памяти потребуется для контекста и какую скорость получит конкретная система.
Матрица сравнения локальных LLM
| Критерий | Что фиксировать |
|---|---|
| Размер модели | Размер GGUF и свободное место на диске |
| Квантизация | Точный тип, уровень точности и наличие смешанных слоёв |
| Память | Минимальные RAM и VRAM, пиковое потребление |
| Производительность | Prefill, latency до первого токена и decode |
| Качество | Код, математика, рассуждения, RAG и диалог |
| Контекст | Фактическая длина, стабильность и retrieval по всей последовательности |
| Совместимость | Поддерживаемый движок, GPU-offload и tensor parallelism |
Для ориентира по выбору низкого уровня квантизации полезен разбор [Q2 и Q3 для Qwen 3.8 27B](https://ai-manual.ru/article/qwen-38-27b-v-nizkih-kvantizatsiyah-kogda-q2-imeet-smyisl-i-chto-teryaetsya-po-sravneniyu-s-q3/). Его вывод применим как методика сравнения, но не заменяет тест Hy4-preview.
Когда размер важнее максимального качества
Меньший файл может быть рациональным выбором при ограниченном диске, небольшом объёме VRAM, необходимости автономной работы или запрете на отправку данных в облако. Сжатая модель удобнее для домашнего AI-сервера, если её качество проходит проверку на целевых задачах.
Экономия оправдана, когда снижение точности не приводит к росту ручной проверки и повторных запусков. Для простых RAG-запросов или пакетной классификации этот компромисс может оказаться приемлемым.
Когда лучше сохранить более точную версию
Полноценная или менее агрессивно сжатая модель предпочтительнее, если цена ошибки высока. Это касается сложного кода, точных вычислений, многошагового анализа и сценариев, где требуется повторяемый результат.
Более тяжёлая версия оправдана и при наличии достаточного оборудования. Дополнительный объём файла не компенсирует потерю качества, если ответы всё равно приходится перепроверять вручную.
Итог: кому имеет смысл рассматривать сжатую Hy4-preview
Hy4-preview в GGUF около 200 ГБ потенциально интересна владельцам локальных AI-систем, которым критичны размер модели, доступность диска и возможность распределить нагрузку между GPU и CPU. Заявление о сохранении 98% производительности выглядит значимым, но пока не подтверждено техническими артефактами и независимым сравнением.
Краткий чек-лист перед переходом
- Проверьте происхождение GGUF и commit-идентификатор.
- Уточните тип и параметры квантизации.
- Убедитесь в совместимости с выбранным движком.
- Сопоставьте доступные RAM и VRAM с размером весов, KV-кэшем и буферами.
- Настройте offload и проверьте распределение нагрузки.
- Измерьте prefill, decode, latency и пиковую память.
- Проверьте кодинг, математику, RAG, рассуждения и длинный контекст на собственных запросах.
- Зафиксируйте ошибки OOM и нестабильные ответы.
Главный компромисс
Квантизация делает большую модель доступнее по диску и памяти, но не отменяет стоимость инференса, требования KV-кэша и ограничения пропускной способности. Файл на 200 ГБ нельзя считать решением для GPU с 24 ГБ VRAM без offload или распределения между несколькими устройствами.
Переход имеет смысл после воспроизводимой проверки на собственном железе. Для повседневного диалога и части RAG-задач сжатая версия может оказаться практичной. Для кода, математики, многошаговых задач и длинного контекста решение нужно принимать по измеренному качеству, а не по одной цифре 98%.