А что для пользователей 3060 (12) с многоядерными зионами и озу 128 ? Есть ли свет в конце туннеля?
Ну 130гб квант с -ot exps=CPU и -ctk q8_0 -ctv q8_0 в теории должен в притык влезть и сколько-то контекста вместить, у меня не точные цифры про 10гб, точнее это с небольшим запасом, на деле там меньше.
Фактически 1-битная модель, это на самом деле 1.58-битная модель - это минимально возможный размер, когда есть 3 значения: -1, 0, 1, меньше уже нельзя создать квант. Даже 1-bit BitNet, это тоже 1.58-битные llm. Так что даже если эту 1.66-битную уменьшить на это чуть-чуть, особо выигрыша по размеру не будет.
LM Studio хорошо работает как быстрый старт, но если нужно, найти альтернативу можно, основные это Jan и Cherry Studio. Мне лично нравится text-generation-webui из-за различных гибкостей, которых нет в упрощенных клиентах.
но навскидку казалось что потери должны быть заметно страшнее.
На CPU ускорение за счет SIMD, а конкретно avx2/avx512, если ядер мало (например, 4), то потери могут быть заметны. Именно оптимизацией этих операций, особенно pp, занимается форк ik_llama. В случае GPU эффект тоже можно заметить, особенно для pp которое может достигать тысяч t/s.
Вот запуск gpu only, хотя физический размер модели одинаковый, разница всё равно есть:
Про табличку еще вопрос - это ваши внутренние замеры, или такое где-то спрятано в глубинах обсуждений репы llama.cpp? Я просто как раз собирался погонять на разных квантах модели, чтобы собрать примерно такие же данные
Да, собственные замеры через llama-bench. Можете указать любое количество моделей через -m, llama-bench сама прогонит все модели по очереди. Или если запускаете в разные моменты, то результаты из консоли можете отправить в те же llm и попросите собрать в одну markdown табличку.
почему модели с низким квантом занимают место в памяти все-таки пропорционально квантованному размеру, а не разбухают до базового FP32/16/8?
Веса распаковываются на лету, потери на распаковку компенсируются общим выигрышем по размеру. И не все кванты одинаковы по вычислительным ресурсам, например, i-кванты будут тяжелее, чем статичные K-кванты, и другие факторы:
cpu only, имитация 6 ядерного ПК
И хотелось бы все таки добавить, что perplexity - это отличный коэффициент для рассчёта, но к сожалению нет никаких гарантий, что в вашей конкретной задаче большее или меньшее его значение будет означать лучшие или худшие ответы.
В работе Accuracy is Not All You Need (https://arxiv.org/abs/2407.09141) показали, что KLD лучше отображает корреляцию между ошибками квантования и метрикой KLD, чем PPL, так как PPL скрывает ошибки квантования из-за усреднения.
PPL (Perplexity) - это степень неуверенности модели в предсказании токена, чем ниже, тем увереннее модель. PPL усредняет логарифмические вероятности по всем токенам, поэтому ошибки, например, завышение вероятности одних токенов и занижение других, могут компенсировать друг друга - в результате PPL близок к оригиналу, хотя результат искажен. Ещё PPL слабо реагирует на ошибки в редких токенах, важных для генерации разнообразных ответов.
KLD (KL Divergence) измеряет расхождение между распределениями исходной и квантованной моделей для каждого токена, потом суммирует расхождения для всех токенов. Тут ошибки никак не компенсируются друг другом, отклонения в вероятностях редких и частых токенов одинаково повлияют на итог. Это куда лучше позволяет оценить потери при квантовании, и если оптимизировать квантование под минимизацию KLD, то в среднем это улучшает кванты.
Тут само собой не время до первого токена, а общее время на генерацию tg.
Недавно встретил параметры -b 4096 -ub 4096, в моём случае они ускоряют генерацию pp в разы, с 40 t/s до 180 t/s. Для больших контекстов это может быть полезно. В этот раз без -ctk q8_0:
Понять так же как и везде, сделать выборку запросов, взять 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, жаль не могу протестировать так же
Ну 130гб квант с
-ot exps=CPUи-ctk q8_0 -ctv q8_0в теории должен в притык влезть и сколько-то контекста вместить, у меня не точные цифры про 10гб, точнее это с небольшим запасом, на деле там меньше.Фактически 1-битная модель, это на самом деле 1.58-битная модель - это минимально возможный размер, когда есть 3 значения: -1, 0, 1, меньше уже нельзя создать квант. Даже 1-bit BitNet, это тоже 1.58-битные llm. Так что даже если эту 1.66-битную уменьшить на это чуть-чуть, особо выигрыша по размеру не будет.
Среди MoE моделей вчера вышла новинка Hunyuan 80B-A13B с 256к контекстом, добавление поддержки в llama.cpp в работе.
Не всё сводится к LM Studio, есть хорошие опенсорсные клиенты + сервер:
https://jan.ai/ (https://github.com/menloresearch/jan)
https://github.com/CherryHQ/cherry-studio
https://github.com/oobabooga/text-generation-webui
https://github.com/LostRuins/koboldcpp
https://github.com/kolosalai/kolosal
Открытые клиенты, которые требуют самостоятельного бэкэнда:
https://github.com/chatboxai/chatbox
https://github.com/open-webui/open-webui
Закрытая альтернатива LM Studio, по их мнению во всём лучше чем LM Studio:
https://msty.app/
LM Studio хорошо работает как быстрый старт, но если нужно, найти альтернативу можно, основные это Jan и Cherry Studio. Мне лично нравится text-generation-webui из-за различных гибкостей, которых нет в упрощенных клиентах.
На CPU ускорение за счет SIMD, а конкретно avx2/avx512, если ядер мало (например, 4), то потери могут быть заметны. Именно оптимизацией этих операций, особенно pp, занимается форк ik_llama. В случае GPU эффект тоже можно заметить, особенно для pp которое может достигать тысяч t/s.
Вот запуск gpu only, хотя физический размер модели одинаковый, разница всё равно есть:
Да, собственные замеры через llama-bench. Можете указать любое количество моделей через -m, llama-bench сама прогонит все модели по очереди. Или если запускаете в разные моменты, то результаты из консоли можете отправить в те же llm и попросите собрать в одну markdown табличку.
Веса распаковываются на лету, потери на распаковку компенсируются общим выигрышем по размеру. И не все кванты одинаковы по вычислительным ресурсам, например, i-кванты будут тяжелее, чем статичные K-кванты, и другие факторы:
В работе Accuracy is Not All You Need (https://arxiv.org/abs/2407.09141) показали, что KLD лучше отображает корреляцию между ошибками квантования и метрикой KLD, чем PPL, так как PPL скрывает ошибки квантования из-за усреднения.
PPL (Perplexity) - это степень неуверенности модели в предсказании токена, чем ниже, тем увереннее модель. PPL усредняет логарифмические вероятности по всем токенам, поэтому ошибки, например, завышение вероятности одних токенов и занижение других, могут компенсировать друг друга - в результате PPL близок к оригиналу, хотя результат искажен. Ещё PPL слабо реагирует на ошибки в редких токенах, важных для генерации разнообразных ответов.
KLD (KL Divergence) измеряет расхождение между распределениями исходной и квантованной моделей для каждого токена, потом суммирует расхождения для всех токенов. Тут ошибки никак не компенсируются друг другом, отклонения в вероятностях редких и частых токенов одинаково повлияют на итог. Это куда лучше позволяет оценить потери при квантовании, и если оптимизировать квантование под минимизацию KLD, то в среднем это улучшает кванты.
https://docs.opensearch.org/docs/latest/vector-search/optimizing-storage/lucene-scalar-quantization/
Тут само собой не время до первого токена, а общее время на генерацию tg.
Недавно встретил параметры
-b 4096 -ub 4096, в моём случае они ускоряют генерацию pp в разы, с 40 t/s до 180 t/s. Для больших контекстов это может быть полезно. В этот раз без-ctk q8_0:Понять так же как и везде, сделать выборку запросов, взять 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: