Понять так же как и везде, сделать выборку запросов, взять top-k для f16 и сравнить их с top-k int8. А Lucene вам не подходит? Он же сам конвертирует веса в int8, правда только из fp32, но конвертнуть в разы проще.
С недавних пор делают, динамическое квантование от unsloth UD-Q8_K_XL, там тензоры токенных эмбедингов, первый и последний слой оставлены в BF16, вместо Q8_0.
Для тензорного параллелизма vllm нужны одинаковые по объему видеокарты в количестве кратном степени двойки. То есть нужно 16 Tesla P40, либо 8 китайских 4090 48гб, либо 4 RTX PRO 6000 96гб.
Скорость PCIe не критична для инференса. Единственное на что она хоть как-то влияет - это если вы работаете в режиме с unified memory, когда у вас постоянно идет подкачка в GPU из ram Разница на v100 32GB c/без nvlink что-то меньше 20% в row split режиме llama.cpp. и незаметна в layer split режиме.
Там речь про запуск в режиме Tensor Parallelism, например, через vLLM.
В Tensor Parallelism каждый слой считается параллельно на всех GPU, вычисление элементов слоя разбивается на отдельные матричные операции, которые нужны для общего результата, и каждая GPU считает свой кусочек. Первая GPU считает Y1 = X * A1, вторая Y2 = X * A2, третья Y3 = X * A3.
После этого GPU1 получает [Y2, Y3], GPU2 получает [Y1, Y3], GPU3 получает [Y1, Y2]. Теперь каждая GPU собирает итоговый Y = [Y1, Y2, Y3].
Передача результатов вычислений туда сюда требует пропускной способности либо pice, либо nvlink, либо ещё как. Размеры этих кусочков хоть и несопоставим с размером модели, так как все веса уже предзагружены в GPU, но всё равно намного больше, чем в llama.cpp. За счет такого распределения вычислений видеокарты лучше утилизируются. Ну, допустим, на двух GPU вместо 30 t/s, можно получить 50 t/s на той же конфигурации.
LLM из-за того, что их веса загружены в память и статичны, могут выполнять параллельную обработка множества запросов почти без потери скорости. Например, если в llama.cpp указать параметр --parallel N, где N количество слотов, то можно пользоваться моделью одновременно с кем-то без задержек, либо запрашивать сразу несколько ответов. Максимальный размер контекста делится на количество слотов.
И если в таком же режиме запустить Tensor Parallelism, то требования к пропускной способность pcie или nvlink резко возрастут, кратно количеству слотов.
ИМХО это очень сильно зависит от размера моделей и ее параметров
Так размер модели обсуждаемый в этом посте - тот что влезет в 24/32гб VRAM. А вы переходите на гипотетические драматические ситуации промышленного инференса на B200 с множеством параллельных запросов.
В MoE и reasoning models там совсем все драматично. Но возьмите DeepSeek R1/V3 и там все будет намного хуже.
В R1/V1 всего 37B активных параметров, будет точно также по скорости. Проблема только как вместить всю модель в VRAM. Та же Qwen3-30B-A3B летает на домашних картах с 1000 t/s на pp и 130 t/s на tg, так как активных параметров всего 3B.
DeepSeek дома запускают на одной GPU получая ускорение через -ot exps=CPU, т.к. никакого тензорного параллелизма не хватит чтобы уместить 671B в домашний VRAM. При чем как раз 2 5060 тут могут выступить лучше одной 3090, скорости у них будут одинаковые из-за распараллеливания работы, а контекста вместят больше.
Насчет processing/generation — это как раз очень наглядно.
Если вместо 800 t/s будет 400 t/s на pp (x4 вместо x16), это всё равно с огромным запасом для домашнего использования, 64к контекста переварятся за 3 минуты в первый раз, а дальше частично закэшируются, даже 100 t/s будет вполне достаточно. Если речь про идеальные цифры, то да, а если про реальные - то даже для x1 это имеет смысл, а не "такая себе затея" и "как раз вот тут автор и стрельнул себе в ногу".
Для больших моделей с большим контекстом и требованиями по низкому time-to-first-token — это становится проблемой. Именно поэтому инференс сейчас активно двигается в сторону больших систем типа GB200NVL72 или B200 NVL8, которые ранее использовались в основном для тренинга.
Тут уж говорим либо про домашний инференс, либо про промышленный. Сколько у вас получается получить на B200 и какой поток на тензорный параллелизм показывает?
Я на домашнем ПК получал скорость pp 30 t/s для 64к на DeepSeek R1 671B, квант который целиком влезал в RAM + 1 GPU, время до первого токена десятки секунд. Да, медленно, но драматизма не вижу, если бы целиком влезло в VRAM, было бы на порядок быстрее даже на медленной шине.
Tensor parallelism - там разрезается модель на N-слоев (каждый слой делится на N частей и отправляется в свою GPU). И вот тут оно намного более требовательное к полосе, ибо при запросе данные ходят очень активно между картами. Есть еще Pipeline parallelism и т.д. И как раз вот тут автор и стрельнул себе в ногу, выбрав 5060 Ti, у которой шина PCIe 5.0 x8. Т.е. всего 30GB/s при скорости VRAM у 5060 Ti в 450GB/s.
Да не на столько драматично. Для Tensor parallelism в режиме генерации токенов в пике хватает 5 гб/с. Обмен тензорами же происходит не размером в целую модель, а только результирующими. Столбик RX:
И вот ровно по той причине, что PCIe СИЛЬНО (больше, чем в 10 раз) медленнее даже GDDR7 (я молчу тут про HBM), делать тензорный или pipeline parallelism на картах без NVLINK - такая себе затея.
Если гнаться за идеальными цифрами, то да, но на практике ускорение против Pipeline parallelism будет в любом случае. Урезая шину, подготовка промпта PP упадет драматично, но она всё ещё огромна, поэтому важнее именно генерация новых токенов TG, которое почти не проседает от количества линий. А учитывая, что даже pcie4.0 x1 дает 4гб/с, то затея стоящая в любом случае.
про 5060 тоже слегка лукаво - нужно не просто pci x16, а версию свежую - v1, v2, v3 вряд ли подойдут) ну и плата будет на самая плохая, раз есть два слота x16 на достаточном расстоянии. с 5060 затраты на железо будут кратно больше (наверное можно купить еще одну 3090).
Никакой разницы не будет. Если нет второго x16, а у x1 слота есть вырез, то можно прям в него подключать видеокарту. Подойдут даже x1 pcie 1.0 подключенные через удлинитель.
Для инференса ширина pcie не играет роли, так как данные грузятся 1 раз и дальше тензоры уже крутятся на внутренней vram и скорость шины уже не важна, выдавая на выход лишь небольшую порцию данных. По сути, тоже относится и к играм, если игра влезает целиком в vram.
Скорость pcie важна для обучения, и то если обработка батчей происходит быстрее, чем скорость загрузки этих батчей, которые часто бывают небольшого размера на домашнем обучении.
Более актуальный совет, это выбирать 5060 размером 2-слота, а не 2.5, так как нижняя карта, в зависимости от материнки, может упереться или ей будет не хватать воздуха от слишком близкого расположения с нижней заглушкой корпуса, где блок питания.
Раздел How (Details), там идет описание самой первой реализации статического Qx_K квантования для архитектуры GPT-2, ещё времена когда gguf назывались ggml. В части про quantization mixes идет описание для attn и ffn. attn - это attention, ffn - это feed forward network. Сейчас S/M/L делаются на 1 шаг выше, чем указано там.
По ссылке указывают конкретные тензоры которые получают повышенный квант, и "все остальные" базовый, а также формулу расчёта супер-блоков. Среди "неважных" есть и attn, а среди важных есть один из ffn, а именно feed_forward.w2, в современных архитектурах он называется ffn_down, это тензор отвечает за сжатие данных после обработки в высокоразмерном пространстве d_ff (это ffn_gate и ffn_up), которое и квантуется как x.
Структура статичного Q4_K_M кванта если нажать на квант на huggingface
Я упростил до "важные тензоры внимания" и в целом описал упрощенное понимание, что означает сочетание XS/S/M/L/XL и как они зависят от Qx_K, что важные тензоры оставляют тем ближе к оригиналу, чем "больше" буквы, так как это полезно при выборе квантов.
Ещё стоит учесть, что первые реализации Qx_K квантования были зашиты в код и были статичны, а сейчас каждый может сделать свой рецепт и поднять или понизить приоритет для любого типа тензоров, при этом продолжая называть их так же. Например, некоторые квантуют ffn_up и ffn_gate на 1 шаг ниже, чем x, так как уверены, что это работает хорошо. Или, например, bartowski называет кванты как Q4_K_M, использует правильную схему, но при этом даже для статичных квантов использует imatrix, для всех кроме Q8_0. В обоих случаях это не настоящие статичные Q4_K_M.
Общая идея плюс-минус конечно остается той же, но именно поэтому разные источники квантов, но одинаково названные, от разных создателей будут вести себя по разному. У одного из таких создателей была ситуация, что его gguf Qwen2.5-coder сбоила, а официальные кванты gguf работали хорошо, хотя и те и те назывались одинаково Q4_K_M.
В целом, сейчас надежнее брать кванты из репозитория unsloth, они для классических Qx_K квантов используют стандартную схему без изменения её туда-сюда, а для UD квантов они делают свою динамическую схему. Ещё они работают с создателями моделей и быстро исправляют ошибки в своих квантах или помогают создателям моделей исправить ошибки, например, в шаблонах чата.
M — средняя точность, L — низкая точность, выше скорость, но ниже качество
L и S перепутаны. M - medium, L - large, S - small. Смысл значений S, M, L в том какие тензоры как будут квантованы.
Упрощенно говоря, каждый слой модели состоит из 2 видов тензоров: это тензоры внимания attn текущего слоя и тензоры полносвязной сети ffn, основное тело модели. Указание Qx - где x число от 1 до 8, это квантование именно ffn тензоров. Указание S, M, L - означает, что важные тензоры внимания будут квантованы на 1, 2 или 3 шага выше, чем число X. Именно тензоры внимания определяют, на сколько квантованная модель будет качественной.
Дальше идут IQ кванты. IQ - это квантование с использованием imatrix, матрицы важности. imatrix создается из обычного текстового файла, в который собирается типичное использование модели, примеры программирования, языка, фактов и т.д. Во время квантования те блоки, что откликаются на текст из этого файла, квантуются выше, те, которые ни на что не откликаются, получают более низкий квант. За счет этого уменьшается вес квантованной модели оставляя почти тоже качество. "Почти тоже" тут главное, так как важно, чтобы imatrix попала в ваш сценарий использования. Обычно матрица делается из английских слов, соответственно, русский язык может не особо хорошо перенести такое квантование, но обычно i-кванты нормально работают.
Дальше идёт динамическое квантование, сейчас таких два: UD и R4.
UD-...-XL - квантование Unsloth Dynamic 2.0. XL означает, что важные тензоры оставлены в очень высоком качестве. Поэтому даже UD 2-битное (UD-Q2_K_XL ) сравнимо с оригиналом по качеству, теряя всего несколько процентов на примере DeepSeek R1, будучи в 3.3 раза меньше по размеру (212гб против 700гб).
https://arxiv.org/html/2505.02390v1
R4 - это sota квантование от ikawrakow, уже известного ранее созданием хороших квантов, вроде IQ4_XS. Сейчас он создал форк ik_llama сосредоточившись на оптимизации CPU и гибридного GPU/CPU. R4 доступен только в ik_llama, но там есть возможность конвертации либо на лету, во время загрузки, либо скриптом. Также в ik_llama реализовано MLA, оригинальная технология DeepSeek, позволяющая в 11гб памяти засунуть 160к контекста. И другие оптимизации для MoE моделей DeepSeek, Qwen3, Llama4.
Также ik_llama недавно добавил квантование iqN_rt, это Trellis квантование аналогичное QTIP, используемого в exl3. Trellis квантование находит оптимальные параметры для каждого блока позволяет ещё лучше сохранить свойства оригинальной модели при минимальном bpw, на графике это IQ2_KT. KLD лучше отображает снижение качества, чем PPL.
RMS Δp показывает среднее отклонение показателей от Q8_0 кванта.
Да, в FramePack HunyuanVideo есть только I2V, но сообществом реализована поддержка T2V и FLF2V (когда задается начальное и конечное изображение), а так же Lora. Для Text-To-Video это сделано на основе адаптера от Flux, поэтому качество для T2V будет не нативное и, скорее всего, сильно хуже.
В вариантах выше Text-To-Video уже добавлено, например, в SD.next, можно сравнить с оригиналом на video.hunyuan.tencent.com:
Cinematic shot: colossal transformer knight, intricate gothic-mechanical armor covered in glowing runes, swings a massive plasma greatsword in a blinding arc. Volcanic wasteland backdrop, dramatic volumetric lighting, sparks flying, motion blur, epic scale, hyper-detailed, concept art style, inspired by Warhammer 40k and Blade Runner.
можно взять открытые модели, например HunyuanVideo (по уровню Kling Pro) - взять в аренду в облаке парочку A100 и в итоге получить генерацию в 3-4 раза дешевле, а если еще и ComfyUI там развернуть для гибкого управления процессом генерации - то вообще будет полный творческий полёт
Обычное 2 битное квантование роняет качество очень сильно, UD делает так, что важные для модели тензоры остаются в высоком качестве, за счет этого качество сохраняется даже при сильном квантовании.
Квант r4 - это по сути как UD квантование, только ещё более продвинутое, так как r4 это sota новый тип квантования тензоров дающий качество лучше.
у меня машина 128гб ram и 32гб vram, жаль не могу протестировать так же
T_TG - время до первого токена. S_PP - prompt processing, скорость обработки контекста. S_TG - token generator, скорость генерации новых токенов. N_KV - размер текущего контекста.
На 32к контекста нужно всего ~3.5гб памяти, никакие 400гб не требуются. Для 64к нужно ~6гб, скорость всё еще терпимая:
Повторюсь, это проблема llama.cpp, где ещё не реализовали MLA, но оригинальный DeepSeek, если запускать его официальную transformers safetensors версию, запускается с MLA (и MTP которая дает ускорение в 1.8 раза, чего пока тоже нет в llama.cpp). MLA реализована в форке ik_llama, в общем в предыдущем комментарии я всё описал и так.
Пользуются даже больше, чем может показаться. Mistral - это один из тех игроков, которые делают свою архитектуру и обучают модели с нуля, ещё и выкладывают модели в открытый доступ, их модели всегда привлекают внимание.
У них одни из лучших открытых моделей: они первые выпустили MoE модель, у них был лучший codestral для локального copilote, их Large 2 конкурировал с gpt-4o того года, на основе их моделей получаются отличные файнтюны и т.д. Например, по бенчмаркам qwen может быть лучше, но на практике mistal оказывался более продуманным и качественным.
Raid не поможет, нужно линейное чтение в 1 потоке. raid0/raid1 - в обоих случаях в 1 потоке будет просто поочередное чтение с разных дисков и скорость останется той же. Раид это обычно про увеличение iops, то есть про многопоток.
Вот HighPoint SSD7540 Raid0 из 8 nvme дисков. В CrystalDiskMark первая строка этого многопоточное чтение, вторая однопоточное.
С недавних пор llama.cpp позволяет выгружать на GPU не целые слои, а их части. Например, для MoE моделей на каждом шагу, допустим, нужны лишь 5 слоев из 64, на каждом новом шагу эти 5 слоев разные. Если выгрузить 10 слоев на GPU, то шанс, что на каждом шагу вычисления попадут на GPU малы.
Теперь есть параметр -ot или --override-tensors. Этим параметром можно разбить слои на тензоры внимания attn и массивные тензоров ffn. Если тензоры внимания вынести на GPU, для этого нужно не так много vram, то 64 слоев из 64 в виде тензоров внимания будут считаться на GPU на каждом шагу, что и дает ускорение.
Если памяти хватает, то и отдельные ffn можно выгрузить на GPU дополнительно. Например, -ngl 99 -ot "blk.([0-9]|1[0-3]).ffn.=CUDA0" -ot exps=CPU выгрузит все тензоры внимания на GPU, после этого тензоры ffn слоев с 0 по 13 выгрузит на первую gpu CUDA0, а остальное отправит на CPU.
Если в оригинале нажать на Files Info со стрелочкой, то будет видно, что BF16 и F32 там совсем немного, они нужны только для динамической активации и масштабирования. И если посмотреть в оригинальном репозитории размер модели, то не квантованный оригинал в safetensors занимает 163 файла весящие в среднем по 4.3гб, итого 700гб.
У gguf нет поддержки квантования из fp8, поэтому чтобы квантовать модель, её сначала нужно апскейлить до bf16, и только после этого можно получить Q8 и так далее.
Понять так же как и везде, сделать выборку запросов, взять top-k для f16 и сравнить их с top-k int8.
А Lucene вам не подходит? Он же сам конвертирует веса в int8, правда только из fp32, но конвертнуть в разы проще.
С недавних пор делают, динамическое квантование от unsloth UD-Q8_K_XL, там тензоры токенных эмбедингов, первый и последний слой оставлены в BF16, вместо Q8_0.
https://huggingface.co/unsloth/gemma-3-27b-it-GGUF/tree/main
Для тензорного параллелизма vllm нужны одинаковые по объему видеокарты в количестве кратном степени двойки. То есть нужно 16 Tesla P40, либо 8 китайских 4090 48гб, либо 4 RTX PRO 6000 96гб.
Там речь про запуск в режиме Tensor Parallelism, например, через vLLM.
В Tensor Parallelism каждый слой считается параллельно на всех GPU, вычисление элементов слоя разбивается на отдельные матричные операции, которые нужны для общего результата, и каждая GPU считает свой кусочек.
Первая GPU считает Y1 = X * A1, вторая Y2 = X * A2, третья Y3 = X * A3.
После этого GPU1 получает [Y2, Y3], GPU2 получает [Y1, Y3], GPU3 получает [Y1, Y2]. Теперь каждая GPU собирает итоговый Y = [Y1, Y2, Y3].
Передача результатов вычислений туда сюда требует пропускной способности либо pice, либо nvlink, либо ещё как. Размеры этих кусочков хоть и несопоставим с размером модели, так как все веса уже предзагружены в GPU, но всё равно намного больше, чем в llama.cpp. За счет такого распределения вычислений видеокарты лучше утилизируются. Ну, допустим, на двух GPU вместо 30 t/s, можно получить 50 t/s на той же конфигурации.
LLM из-за того, что их веса загружены в память и статичны, могут выполнять параллельную обработка множества запросов почти без потери скорости. Например, если в llama.cpp указать параметр
--parallel N, где N количество слотов, то можно пользоваться моделью одновременно с кем-то без задержек, либо запрашивать сразу несколько ответов. Максимальный размер контекста делится на количество слотов.И если в таком же режиме запустить Tensor Parallelism, то требования к пропускной способность pcie или nvlink резко возрастут, кратно количеству слотов.
Так размер модели обсуждаемый в этом посте - тот что влезет в 24/32гб VRAM. А вы переходите на гипотетические драматические ситуации промышленного инференса на B200 с множеством параллельных запросов.
В R1/V1 всего 37B активных параметров, будет точно также по скорости. Проблема только как вместить всю модель в VRAM.
Та же Qwen3-30B-A3B летает на домашних картах с 1000 t/s на pp и 130 t/s на tg, так как активных параметров всего 3B.
DeepSeek дома запускают на одной GPU получая ускорение через
-ot exps=CPU, т.к. никакого тензорного параллелизма не хватит чтобы уместить 671B в домашний VRAM. При чем как раз 2 5060 тут могут выступить лучше одной 3090, скорости у них будут одинаковые из-за распараллеливания работы, а контекста вместят больше.Если вместо 800 t/s будет 400 t/s на pp (x4 вместо x16), это всё равно с огромным запасом для домашнего использования, 64к контекста переварятся за 3 минуты в первый раз, а дальше частично закэшируются, даже 100 t/s будет вполне достаточно.
Если речь про идеальные цифры, то да, а если про реальные - то даже для x1 это имеет смысл, а не "такая себе затея" и "как раз вот тут автор и стрельнул себе в ногу".
Тут уж говорим либо про домашний инференс, либо про промышленный. Сколько у вас получается получить на B200 и какой поток на тензорный параллелизм показывает?
Я на домашнем ПК получал скорость pp 30 t/s для 64к на DeepSeek R1 671B, квант который целиком влезал в RAM + 1 GPU, время до первого токена десятки секунд. Да, медленно, но драматизма не вижу, если бы целиком влезло в VRAM, было бы на порядок быстрее даже на медленной шине.
Да не на столько драматично. Для Tensor parallelism в режиме генерации токенов в пике хватает 5 гб/с. Обмен тензорами же происходит не размером в целую модель, а только результирующими. Столбик RX:
Если гнаться за идеальными цифрами, то да, но на практике ускорение против Pipeline parallelism будет в любом случае. Урезая шину, подготовка промпта PP упадет драматично, но она всё ещё огромна, поэтому важнее именно генерация новых токенов TG, которое почти не проседает от количества линий. А учитывая, что даже pcie4.0 x1 дает 4гб/с, то затея стоящая в любом случае.
Никакой разницы не будет. Если нет второго x16, а у x1 слота есть вырез, то можно прям в него подключать видеокарту. Подойдут даже x1 pcie 1.0 подключенные через удлинитель.
Для инференса ширина pcie не играет роли, так как данные грузятся 1 раз и дальше тензоры уже крутятся на внутренней vram и скорость шины уже не важна, выдавая на выход лишь небольшую порцию данных. По сути, тоже относится и к играм, если игра влезает целиком в vram.
Скорость pcie важна для обучения, и то если обработка батчей происходит быстрее, чем скорость загрузки этих батчей, которые часто бывают небольшого размера на домашнем обучении.
Более актуальный совет, это выбирать 5060 размером 2-слота, а не 2.5, так как нижняя карта, в зависимости от материнки, может упереться или ей будет не хватать воздуха от слишком близкого расположения с нижней заглушкой корпуса, где блок питания.
Раздел How (Details), там идет описание самой первой реализации статического Qx_K квантования для архитектуры GPT-2, ещё времена когда gguf назывались ggml. В части про quantization mixes идет описание для attn и ffn.
attn - это attention, ffn - это feed forward network. Сейчас S/M/L делаются на 1 шаг выше, чем указано там.
По ссылке указывают конкретные тензоры которые получают повышенный квант, и "все остальные" базовый, а также формулу расчёта супер-блоков. Среди "неважных" есть и attn, а среди важных есть один из ffn, а именно feed_forward.w2, в современных архитектурах он называется ffn_down, это тензор отвечает за сжатие данных после обработки в высокоразмерном пространстве d_ff (это ffn_gate и ffn_up), которое и квантуется как x.
Я упростил до "важные тензоры внимания" и в целом описал упрощенное понимание, что означает сочетание XS/S/M/L/XL и как они зависят от Qx_K, что важные тензоры оставляют тем ближе к оригиналу, чем "больше" буквы, так как это полезно при выборе квантов.
Ещё стоит учесть, что первые реализации Qx_K квантования были зашиты в код и были статичны, а сейчас каждый может сделать свой рецепт и поднять или понизить приоритет для любого типа тензоров, при этом продолжая называть их так же. Например, некоторые квантуют ffn_up и ffn_gate на 1 шаг ниже, чем x, так как уверены, что это работает хорошо. Или, например, bartowski называет кванты как Q4_K_M, использует правильную схему, но при этом даже для статичных квантов использует imatrix, для всех кроме Q8_0. В обоих случаях это не настоящие статичные Q4_K_M.
Общая идея плюс-минус конечно остается той же, но именно поэтому разные источники квантов, но одинаково названные, от разных создателей будут вести себя по разному. У одного из таких создателей была ситуация, что его gguf Qwen2.5-coder сбоила, а официальные кванты gguf работали хорошо, хотя и те и те назывались одинаково Q4_K_M.
В целом, сейчас надежнее брать кванты из репозитория unsloth, они для классических Qx_K квантов используют стандартную схему без изменения её туда-сюда, а для UD квантов они делают свою динамическую схему. Ещё они работают с создателями моделей и быстро исправляют ошибки в своих квантах или помогают создателям моделей исправить ошибки, например, в шаблонах чата.
Не помню точно, где-то вот тут: https://github.com/ggml-org/llama.cpp/pull/1684
Или вот тут: https://huggingface.co/docs/hub/gguf#quantization-types
L и S перепутаны. M - medium, L - large, S - small. Смысл значений S, M, L в том какие тензоры как будут квантованы.
Упрощенно говоря, каждый слой модели состоит из 2 видов тензоров: это тензоры внимания attn текущего слоя и тензоры полносвязной сети ffn, основное тело модели.
Указание Qx - где x число от 1 до 8, это квантование именно ffn тензоров.
Указание S, M, L - означает, что важные тензоры внимания будут квантованы на 1, 2 или 3 шага выше, чем число X. Именно тензоры внимания определяют, на сколько квантованная модель будет качественной.
Дальше идут IQ кванты.
IQ - это квантование с использованием imatrix, матрицы важности. imatrix создается из обычного текстового файла, в который собирается типичное использование модели, примеры программирования, языка, фактов и т.д. Во время квантования те блоки, что откликаются на текст из этого файла, квантуются выше, те, которые ни на что не откликаются, получают более низкий квант. За счет этого уменьшается вес квантованной модели оставляя почти тоже качество. "Почти тоже" тут главное, так как важно, чтобы imatrix попала в ваш сценарий использования. Обычно матрица делается из английских слов, соответственно, русский язык может не особо хорошо перенести такое квантование, но обычно i-кванты нормально работают.
Дальше идёт динамическое квантование, сейчас таких два: UD и R4.
UD-...-XL - квантование Unsloth Dynamic 2.0. XL означает, что важные тензоры оставлены в очень высоком качестве. Поэтому даже UD 2-битное (UD-Q2_K_XL ) сравнимо с оригиналом по качеству, теряя всего несколько процентов на примере DeepSeek R1, будучи в 3.3 раза меньше по размеру (212гб против 700гб).
R4 - это sota квантование от ikawrakow, уже известного ранее созданием хороших квантов, вроде IQ4_XS. Сейчас он создал форк ik_llama сосредоточившись на оптимизации CPU и гибридного GPU/CPU. R4 доступен только в ik_llama, но там есть возможность конвертации либо на лету, во время загрузки, либо скриптом. Также в ik_llama реализовано MLA, оригинальная технология DeepSeek, позволяющая в 11гб памяти засунуть 160к контекста. И другие оптимизации для MoE моделей DeepSeek, Qwen3, Llama4.
R4 позволяет создать самый маленький квант R1 в мире, занимающий всего 130 гб и подходящий для домашних ПК 128гб + 1 GPU:
Также ik_llama недавно добавил квантование iqN_rt, это Trellis квантование аналогичное QTIP, используемого в exl3. Trellis квантование находит оптимальные параметры для каждого блока позволяет ещё лучше сохранить свойства оригинальной модели при минимальном bpw, на графике это IQ2_KT. KLD лучше отображает снижение качества, чем PPL.
Да, в FramePack HunyuanVideo есть только I2V, но сообществом реализована поддержка T2V и FLF2V (когда задается начальное и конечное изображение), а так же Lora. Для Text-To-Video это сделано на основе адаптера от Flux, поэтому качество для T2V будет не нативное и, скорее всего, сильно хуже.
В вариантах выше Text-To-Video уже добавлено, например, в SD.next, можно сравнить с оригиналом на video.hunyuan.tencent.com:
Гифка 1.5мб. FramePack T2V
HunyuanVideo можно запускать на домашних GPU от 6гб: https://github.com/lllyasviel/FramePack
5-секундый ролик генерируется где-то 5-10 минут. Можно использовать SD.Next, FramePack-Studio, ComfyUI-FramePack, чтобы было удобнее.
Не, не 2 бит, а UD 2 бит, потому что это разные вещи: https://unsloth.ai/blog/dynamic-v2
Обычное 2 битное квантование роняет качество очень сильно, UD делает так, что важные для модели тензоры остаются в высоком качестве, за счет этого качество сохраняется даже при сильном квантовании.
Квант r4 - это по сути как UD квантование, только ещё более продвинутое, так как r4 это sota новый тип квантования тензоров дающий качество лучше.
Тот квант, что я запускал, это самый маленький квант DeepSeek-R1 из существующих, он как раз сделан под систему 128гб ram + 16gb vram: https://huggingface.co/ubergarm/DeepSeek-R1-0528-GGUF
Описание ключей запуска ik_llama: https://github.com/ikawrakow/ik_llama.cpp/discussions/258
Замеры PPL:
https://docs.unsloth.ai/get-started/beginner-start-here
Сейчас проверим. Модель DeepSeek R1-0528, размер 671B. Размер контекста 32к, тот где согласно вашей ссылке нужны 400гб.
Запуск на обычном домашнем ПК с 192гб, не сервер, проц обычный, дешевая китайская Kingbank DDR5 4x48. Одна игровая GPU 24гб для ускорения через
-ot.Параметры запуска ik_llama бенчмарка llama-sweep-bench, который тестирует размер контекста и скорость:
./llama-sweep-bench -m DeepSeek-R1-0528-IQ1_S_R4-00001-of-00003.gguf -ctk q8_0 -mla 3 -fa -amb 512 -fmoe -ngl 99 -ot exps=CPU -t 28 -c 65536 -ts 24,0 -rtrT_TG- время до первого токена.S_PP- prompt processing, скорость обработки контекста.S_TG- token generator, скорость генерации новых токенов.N_KV- размер текущего контекста.На 32к контекста нужно всего ~3.5гб памяти, никакие 400гб не требуются. Для 64к нужно ~6гб, скорость всё еще терпимая:
Повторюсь, это проблема llama.cpp, где ещё не реализовали MLA, но оригинальный DeepSeek, если запускать его официальную transformers safetensors версию, запускается с MLA (и MTP которая дает ускорение в 1.8 раза, чего пока тоже нет в llama.cpp). MLA реализована в форке ik_llama, в общем в предыдущем комментарии я всё описал и так.
Пользуются даже больше, чем может показаться. Mistral - это один из тех игроков, которые делают свою архитектуру и обучают модели с нуля, ещё и выкладывают модели в открытый доступ, их модели всегда привлекают внимание.
У них одни из лучших открытых моделей: они первые выпустили MoE модель, у них был лучший codestral для локального copilote, их Large 2 конкурировал с gpt-4o того года, на основе их моделей получаются отличные файнтюны и т.д. Например, по бенчмаркам qwen может быть лучше, но на практике mistal оказывался более продуманным и качественным.
magistral 24B gguf, запускать с ключом
--jinja: https://huggingface.co/unsloth/Magistral-Small-2506-GGUFRaid не поможет, нужно линейное чтение в 1 потоке. raid0/raid1 - в обоих случаях в 1 потоке будет просто поочередное чтение с разных дисков и скорость останется той же. Раид это обычно про увеличение iops, то есть про многопоток.
Вот HighPoint SSD7540 Raid0 из 8 nvme дисков. В CrystalDiskMark первая строка этого многопоточное чтение, вторая однопоточное.
С недавних пор llama.cpp позволяет выгружать на GPU не целые слои, а их части. Например, для MoE моделей на каждом шагу, допустим, нужны лишь 5 слоев из 64, на каждом новом шагу эти 5 слоев разные. Если выгрузить 10 слоев на GPU, то шанс, что на каждом шагу вычисления попадут на GPU малы.
Теперь есть параметр
-otили--override-tensors. Этим параметром можно разбить слои на тензоры внимания attn и массивные тензоров ffn.Если тензоры внимания вынести на GPU, для этого нужно не так много vram, то 64 слоев из 64 в виде тензоров внимания будут считаться на GPU на каждом шагу, что и дает ускорение.
Если памяти хватает, то и отдельные ffn можно выгрузить на GPU дополнительно. Например,
-ngl 99 -ot "blk.([0-9]|1[0-3]).ffn.=CUDA0" -ot exps=CPUвыгрузит все тензоры внимания на GPU, после этого тензоры ffn слоев с 0 по 13 выгрузит на первую gpu CUDA0, а остальное отправит на CPU.Если в оригинале нажать на Files Info со стрелочкой, то будет видно, что BF16 и F32 там совсем немного, они нужны только для динамической активации и масштабирования.
И если посмотреть в оригинальном репозитории размер модели, то не квантованный оригинал в safetensors занимает 163 файла весящие в среднем по 4.3гб, итого 700гб.
У gguf нет поддержки квантования из fp8, поэтому чтобы квантовать модель, её сначала нужно апскейлить до bf16, и только после этого можно получить Q8 и так далее.
DeepSeek обучен в fp8, а не fp16, поэтому не квантованный весит 700гб.