Я не знаю на сколько из далека вам нужна теория, поэтому с самого начала, если что просто переходите на следующий пункт.
Про квантизацию
Веса модели это массив млрд цифр типа float. Стандартный размер float это 32-бита на вес, то есть это числа такого вида: 0.340282347234423412354675889478
Эти числа образуют собой матрицы чисел, матрицы (тензоры) перемножаются друг на друга и модель выдает результат. Фактически в модели нет ничего кроме этих чисел, там нет скрытых слоев знаний или слоев данных, просто так удачно сложились значения этих весов, что на выходе выходит что-то осмысленное плюс различные эмерджентные свойства. Подбор этих весов это и есть обучение модели.
Количество цифр после запятой велико, чем дальше они от начала, тем меньший вклад вносят в итоговый результат умножения, поэтому можно просто сократить их в 2 раза и перейти на float16. Это имеет почти нулевое влияние на качество, но увеличивает скорость инференса и скорость обучения в 2 раза. float16 уже выглядит так: 0.1245236426236046
16 бит на вес - цифр после запятой всё ещё достаточно, можно сократить их ещё в 2 раза и получить fp8, в fp8 как раз обучена DeepSeek, но обычно другие модели обучают до сих пор в f16.
Есть ещё всякие детали, вроде распределения мантисы и экспоненты, и то, что сейчас используют более точный bfloat16, вместо обычного float16, есть fp4 в nvidia 5000 серии и т.д. Чтобы квантование в fp4 или fp8 хорошо работало, устройство должно поддерживать операции с этим типом чисел, иначе нужны преобразования весов на лету до поддерживаемых типов.
Квантование в gguf работает не просто сокращением чисел после запятой, там в основном используются целочисленные типы int, а перегнать число с плавающей запятой в int - это само по себе снижение точности, в gguf же ещё происходит и объединение весов в суперблоки, из-за чего срезаются выбросы, если в суперблок попали веса не похожие на общие в среднем веса суперблока. В среднем если точности хватает, это не так важно, но чем агрессивнее квантование, тем больше будет потерь.
Ну это упрощенно, gguf позволяет сохранять веса и без квантования и квантовать любым другим способом, не только через суперблоки. Например, в ik_llama недавно добавили Trellis quants IQx_KT, работающие аналогично как в exl3, и они в целом дают лучшее качество при меньшем весе и большую скорость, но хорошо работают только на GPU, на CPU происходит просадка скорости.
Цифра рядом с Q - это то количество бит, которое будет затрачено на основные веса модели, а буквы XL, L, M, S - это на сколько выше будут квантованы важные тензоры, например, внимания, которые сильнее влияют на качество, чем основное тело модели. L - Large на 2-3 уровня выше, M - Medium на 1-2 уровня выше, S - Small на 0-1 уровня выше. Ну и XL - eXtra Lagre, там динамичное число и могут быть на много уровней выше.
Например, вначале в gguf было квантование прямо в лоб, был тип Q4_0 - это просто урезание весов до int4, или 4 bpw (bite per weight), или чуть позже Q4_1, оно чуть получше, но эти типы работали плохо и качество сильно падало.
Сам алгоритм квантования был изменен, качество стало выше, размер меньше. Эти кванты до сих пор везде используются как база, те самые популярные Q4_K_M или IQ4_XS. Q4 - это 4 бита на основные веса K - это скорее всего Kawrakow, просто отделяет Q4_0, Q5_0 кванты от Q4_K, Q5_K и т.д. M - Medium, значит важные веса на 2 уровня выше и квантуются как Q6_K. Супер важные тензоры остаются в fp32 или f16 (f16 - это общее название для bf16 и fp16).
В таких квантах тензоры квантованы не равномерно и суммарный BPW для Q4_K_M будет 4.82 BPW, при этом размере чуть больше чем у Q4_0, по качеству это выходит почти как 5 бит на вес, соответственно и качество ощутимо лучше.
IQ4_XS или IQ2_XSS - это уже более продвинутый тип квантования через матрицу важности imatrix, сами XS и XSS это уже именно алгоритмы квантования тензоров, количество S передает смысл сохраняемой точности, чем их больше, тем ниже точность.
В форке ik_llama есть новые кванты IQ2_KS и KSS, в данном случае K просто показывает, что это другой квант, у них точность выше чем у XS и XSS, а размер тот же.
В общем чем ниже число, тем ниже бит на вес, тем хуже качество модели. 8 бит на вес работает почти без потерь, квантование Q6_K - очень близко к без потерь, Q5_K_M процентов на 2-3% хуже, Q4_K_M процентов на 5% и т.д. IQ кванты лучше чем статичные K кванты, поэтому IQ4_XS весит меньше, но работает на уровне Q4_K_M. Кванты из ik_llama ещё лучше, поэтому могут весить ещё меньше при том же качестве.
В общем это примерное описание, не нужно воспринимать эту информация как истину, этого достаточно, чтобы примерно понимать что к чему, но везде могут быть исключения и прочие тонкости.
Между ними разница на треть по размеру дискового пространства, но и алгоритмы сильно разные. Качество тоже разнится?
Качество отличается, квантование это способ снизить размер за счет снижения качества. Весь смысл в том, сколько качества нужно потратить на каждый шаг снижения веса. Один из способов померить разницу - это замерить PPL или KLD, их описание есть в статье. Чем эти значения ниже, тем меньше отклонений от оригинальной модели.
DeepSeek R1 0528 ppl
Кроме общего представления, можно заметить, что новые кванты из ik_llama весят меньше, а PPL такой же как у более крупных квантов, квантованных старыми способами.
Например, новый квант IQ2_KS весит 196гб и имеет PPL 3.6378, а квант UD-Q2_K_XL весит 234гб и PPL 3.6062. Разницы почти нет, при этом размер на 38гб меньше. Новый квант IQ2_K_R4 имеет размер 220гб и PPL 3.5069, что ощутимо ниже чем у UD-Q2_K_XL, а вес меньше на 14гб.
Но разницы почти нет это довольно условное представление. Разницы почти нет на тексте wiki.test.raw, это узкий диапазон текстов на английском из википедии, а для другого языка или для вашего редкого сценария разница может быть куда более ощутимой.
Или "экономия диска" (и более быстрая загрузка?), а потребление VRAM одинаковое в итоге? Или действительно IQ2_M так хорош, что при экономии всего (и диска, и VRAM) даст сравнимое качество с Q3_K_L?
Потребление VRAM будет разное, чем сильнее квантование, тем меньше, по сути столько, сколько весит модель физически + размер контекста, столько и нужно VRAM или RAM. Веса распаковываются на лету, поэтому скорость работы разных квантов будет разной, так как везде разные алгоритмы, и поэтому эту скорость можно ускорить на той же пропускной способности памяти. По крайней мере для скоростей PP это заметная разница.
i-кванты обычно тяжелее по вычислительным ресурсам, чем статичные K-кванты. Я как-то давно делал простое сравнение, хотя размер по весу у моделей примерно одинаковый, но скорости отличаются. Новые IQK кванты легче старых i-квантов (в сравнении их нет):
Или вот IQ1M и IQ2_XXS - по размеру на диске разница не принципиальная. В 8GB VRAM ни одна не влезел, а в 12 любая (наверное). При этом IQ2, наверное, сильно лучше IQ1?
Про сильно лучше - это сомнительно, что сильно, но лучше это да, обычно чем больше цифра и какие бы ни были символы, тем лучше. И там разница почти 1гб, это можно дополнительно ~16к контекста вместить, это не так уж и мало, иногда как раз 0.5гб и не хватает и взять их не откуда.
Опять же, исключением для цифры может быть у разного типа квантования, например, старые из llama.cpp и новые из ik_llama.cpp. На графике выше видно, что новый IQ3_K_R4 на том же уровне как старый IQ4_XS, при этом новый весит на 33гб меньше, но это скорее исключение.
Speculative decoding (в RooCode для LM Studio есть такая галочка - хоть это и не в рамках подхода из данного поста)
В статье есть немного про спекулятивное декодирование, в DeepSeek оно называется MTP. Смысл в том, что нужна очень маленькая модель для черновиков, на которую не жалко потратить немного ресурсов, и они должны быть из одного семейства, иначе не заработает.
Сначала маленькая предлагает последовательность токенов, например 16 новых токенов, большая модель внедряет эти токены в свою последовательность и производит расчет, если вероятности совпадают, то большая принимает эти токены. Ускорение происходит за счет того, что большая модель не тратит время на генерацию шаг за шагом, а проверяет вероятности сразу для всех токенов параллельно. Сам алгоритм не так важен, главное, что за счет kv-кэша проверить токены быстрее, чем высчитать их с нуля.
Маленькая модель - это 0.6B, 1B или 1.5B, размеры 3B или 4B уже слишком большие, но и они могут быть полезны в редких ситуациях.
Ну и получается, что помимо большой модели (которую хочется максимальную по локальным ресурсам запустить) надо еще и мелкую стартовать? (в таком не вижу большого смысла, лоакльные ресурсы и так ограничены).
Берем gemma-3-27b UD-Q5_K_XL, она занимает 21гб. Берем gemma-3-1b Q4_K_M, она занимает 800мб. Черновой модели тоже нужен контекст, где-то суммарно будет 1.5гб VRAM, две модели влезают в 24гб + 22к контекста.
Qwen3-235B-A22B-2507-UD-Q4_K_XL, было 4.8 t/s, стало 7.1 t/s
Процент принятия 56%, было 4.8 t/s, стало 7.1 t/s, ускорение в 1.5 раза, вполне нормально, можно попробовать подобрать другую модель для черновика или квант этой модели. Но черновая модель не всегда помогает, может сделать и хуже.
По умолчанию черновик генерирует последовательность в 16 токенов, шанс что будет принята такая длинная последовательность не велика, а времени тратится и на проверку и на генерацию. Если модели очень сильно отличаются, то тут может помочь снизить длину последовательности. Параметром --draft-max 4 или --draft-max 8 можно сократить последовательность до 4/8 токенов.
Тут тот случай, когда для большой Qwen3-235B-A22B-2507 в качестве черновика лучше подойдет Qwen3-4B, урезав последовательность до 4 можно получить скорость 7.5 t/s, но правда это всего на 0.2 t/s больше, чем Qwen3-1.7B, с которой 7.3 t/s.
Возьмем огромную модель Qwen3-Coder 480B-A35B, черновая Qwen3-1.7B. Модели уже совсем разные по качеству ответов. Черновая модель с базовыми настройками делает хуже, уменьшение длины последовательности помогает и увеличивает процент принятия до 73%, хотя дает прирост скорости всего 5%, с 5.9 до 6.3 t/s.
Qwen3-Coder-480B-A35B-UD-Q2_K_XL
И ещё один вариант, когда модель не влезает в RAM и считывается с nvme. Снова огромная Qwen3-Coder 480B-A35B, в кванте UD-Q3_K_XL.
Qwen3-Coder-480B-A35B-UD-Q3_K_XL
Тут уже черновая модель помогает намного лучше, было 2.3 t/s, стало 4.2 t/s, с натяжкой можно пользоваться.
Тут тоже информация не на 100% верная, нужно перепроверять и тестировать.
Или они независимы и можно draft запустить через API где-то за копейки (модель легкая и супербыстрая), а финал локально доделать (не слишком долго, ибо только верификация)?
Задержки будут большими, да и нет такого функционала.
Можно использовать 2 GPU. Основную модель запустить на основной GPU, а черновую на второй карте. Не знаю, можно ли так сделать в LM Studio, в llama-server это делается командой: .\llama-server -m "gemma-3-27b-it-UD-Q5_K_XL.gguf" -ts 24,0 -ngl 99 -fa -md "gemma-3-1b-it-Q4_K_M.gguf" -ngld 99 -devd cuda1
Через -ts 24,0 запрещаем использовать вторую GPU для основной модели, через -devd cuda1 направляем draft модель на устройство cuda1. -ngl 99 выгрузить все слои основной модели, -ngld 99 выгрузить все слои черновой модели.
Вторая карта медленная 4060, поэтому ускорение слабое, но всё равно есть:
Модель large работает на мобильной 3070 8gb терпимо. Транскрибация правда довольно медленная получается, примерно 1 к 1 по времени. Т.е. час видео
Попробуйте whisper.cpp, должно быть быстрее на 3070. Модели в формате ggml (по сути тоже самое, что gguf) лежат тут: https://huggingface.co/ggerganov/whisper.cpp. У whisper ещё вышла модель whisper-large-v3-turbo, она быстрее и легче чем просто large-v3.
На 4060ti часовая лекция разбирается: – за 7 минут на large-v3 неквантованная, 4гб vram – за 5.1 минуты на large-v3 в кванте q5_0, 2.5гб vram – за 2.3 минуты на large-v3-turbo в кванте q8_0, 1.6гб vram.
4060ti, Andrei1980/whisper-large-rus-ggml неквантованная large v3, транскрипция часовой лекции за 7 минут
Qwen устроил неделю релизов. Суммарно они представили по хронологии:
Qwen3-235B-A22B-2507
Qwen3-235B-A22B-Thinking-2507
Qwen3-Qwen3-Coder-480B-A35B
Qwen Wan2.2 размером 5B и 14B (генерация видео из текста или из картинки)
Qwen3-30B-A3B-Instruct-2507
Qwen3-30B-A3B-Thinking-2507
Qwen3-Coder-30B-A3B-Instruct
Маленький Qwen3-Coder-30B-A3B они назвали Qwen3-Coder-Flash, для своего размера он показывает не плохие результаты.
Серия маленьких 30B-A3B моделей интересна не только тем, что их можно запустить даже на CPU с нормальной скоростью, так как активных параметров всего 3B, но и тем, что увеличили нативный контекст до 256к. Большая Qwen3-235B-A22B-Thinking-2507 сделала лучший пересказ книги, книга занимала 215к токенов и влезала целиком в 256к, теперь интересно на сколько хорош контекст у очень легковесной Qwen3-30B-A3B-Thinking-2507. Модель маленькая, и можно её сравнить с Gemma3 27B у которого 128к.
Результат Gemma3 уже есть в статье, он выдумывает и ошибается даже на 32к контексте. Поэтому тот же вопрос, что и для Gemma3 27B.
В какой момент была включена Roll Over Beethoven? Что произошло дальше?
Qwen3-30B-A3B-Thinking-2507-IQ4_K.gguf, ответ правильный
Сам ответ правильный, это при том, что в контекст загружена вся книга целиком, а не как в случае Gemma только 32к контекста, но последний момент с уходом в Лабиринт Смерти - технически правильно, но тут как будто бы это не к месту упомянуто, так как перед походом было много других событий.
Можно попробовать дать куда более сложное задание, пройти по всей книге и обобщить факты из разных эпизодов, из начала, середины и конца книги. Это частая проблема для многих моделей на SWA, так как скользящее окно контекста обычно всего 4к.
Ответь на 3 вопроса по книге:
Какие по ходу книги были ники у гг
Кто такая Вика, почему их две
Сколько раз гг встречался с Маньяком, а сколько раз с Человеком без Лица
Не забыл упомянуть про личность номер 7
Про игру отражений правильное замечание
Qwen3-30B-A3B-Thinking-2507-IQ4_K.gguf
Для такой маленькой модели ответы вполне хороши. Ошибка и путаница про встречи с Маньяком, часть правильно, часть спутана, части не хватает, но это как раз и есть самая сложная часть собрать по книге все встречи. После провала Gemma3 27B и Llama4 Scout 109B-A17B, казалось что маленькие модели не способы переваривать огромный контекст, но у Qwen3 30B-A3B на первый взгляд получилось куда лучше.
В предыдущем комментарии я слегка ошибся, для вмещения 256к контекста нужно не 8гб, а 23гб. Скорости на скриншотах низкие, так как почти всю память отдал под контекст, используя -ot exps=CPU даже тут, если контекст уменьшить, то скорости будут ожидаемо большими. Появились сборки бинарников ik_llama под Windows, бенчмарк скорости на них: https://github.com/Thireus/ik_llama.cpp
и судя по всему 128гб ram должно в притык хватить (я верно понимаю, что часть, выгруженная в vram в ram уже не используется?) если учитывать видеокарту, при этом на весь объем контекста!?
Да, если включен mmap, то всё что выгружено в VRAM уже не использует в RAM, в итоге доступный объема памяти под модель это RAM + VRAM, и если этого не хватит, то автоматически залезет на nvme. Если mmap выключен (например, он автоматически выключается если использовать -rtr), то такое не работает, так как без mmap модель вначале будет целиком загружена в RAM и не освободит её после разгрузки.
IQ4_KSS впритык, 128гб это 119 ГиБ, а квант весит 114 ГиБ, с учётом разгрузки в VRAM влезет, если память ни на что другое не тратится. Но всегда есть IQ3_K (106 ГиБ), он всего на 3.2% по PPL отличается от BF16, а IQ4_KSS на 2.1%.
Весь 256к контекст с полной выгрузкой -ot exps=CPU не влезает в 24гб. У модели 93 слоя, для теста с книгой я смог выгрузить только 45, это ощутимо ударило по скорости tg, и учитывая, что это размышляющая модель, если не нужен полный контекст, то лучше выгрузить все слои. Если нужен полный, то можно попробовать выгрузить на 2 gpu указав -mg 0 (main gpu X) для той, где будет контекст, а оставшиеся слои выгрузить на вторую, но тут надо экспериментировать.
Сегодня вышла новая MoE модель Qwen3-235B-A22B-Thinking-2507. У неё контекст 256к, для вмещения всего контекста в q8_0 нужно примерно 8гб, модель использует GQA и SWA, через -fa это работает.
На длинном контексте по бенчмарку эта модель на данный момент лучше остальных опенсорсных, и конкурирует с закрытыми, кроме совсем топовых:
Решил посмотреть как эта модель покажет себя на Лабиринте Отражений. Книга на этой модели занимает 215к токенов, в 256к как раз влезает целиком:
Пересказ охватывает всю книгу правильно
В общем могу подтвердить, пока это самый точный пересказ книги, оценена была именно книга целиком. Модель легко разделяет двух Вик, и с другими конкретными вопросами модель тоже справляется успешно.
Обычно у языковых моделей вроде ChatGPT нет постоянной памяти. Но в нашем случае — в новом, “чистом” чате — модель: узнала собеседника, сослалась на статью, которую мы с ней писали в прошлом, и продолжила говорить в том же стиле и знании, хотя технически не должна была иметь к этому доступ.
3 июня 2025 года обновление: улучшения функции памяти начинают внедряться для бесплатных пользователей. Помимо сохранённых воспоминаний, которые уже были ранее, ChatGPT теперь учитывает ваши недавние диалоги, чтобы давать более персонализированные ответы.
10 апреля 2025 года обновление: функция памяти в ChatGPT стала ещё более полной. Помимо сохранённых ранее воспоминаний, теперь учитываются все ваши прошлые разговоры, чтобы делать ответы более релевантными и адаптированными под вас. Это означает, что функция памяти теперь работает двумя способами: «сохранённые воспоминания», которые вы просили запомнить, и «история чатов» — это сведения, которые ChatGPT извлекает из прошлых бесед для улучшения будущих.
i7-14700 + 192гб (или 188 гиб) DDR5 4800 MT/s + 4090 + nvme PM9A1. 4060 не добавлял, так как не хотелось подбирать перенос тензоров. В общем запускал с самой ленивой -ot exps=CPU командой.
Активных параметров у модели 35B, вес кванта 216 гиб + контекст, в итоге чтение с nvme не такое большое, как по объему так и по скорости, поэтому просадка tg не такая заметная, но всё равно из-за этого скорость получилась ближе к 4 t/s, чем к 5 t/s.
Вот эта разница между гб и гиб как раз не позволяет этот квант целиком вместить даже с учетом разгрузки, поэтому добавление 4060 не сильно поможет. Пришлось снизить ub/b до 3072, чтобы выгрузить лишний слой:
Qwen3-Coder-480B-A35B IQ3_K +4060
Ещё когда вышла Kimi K2 размером 1026B-A32B, запускал на тот момент самый маленький квант Kimi-K2-Instruct-UD-IQ1_S, он весит 262гб, это уже ощутимо не влезает в память и необходимость постоянного чтения с nvme уже по полной просаживает скорость:
Kimi-K2-Instruct-UD-IQ1_S
Сейчас уже добавили версию smol-IQ1_KT размером 219гб и потерей по PPL в 30%, не запускал, но думаю скорость будет примерно такой же ~4 t/s, как и у Qwen3-Coder.
А какой квант запускали? И если не секрет, какой скорости удалось добиться?
Запускал IQ3_K (216гб), он не влез в 188гб ram памяти, поэтому частично запускался с ssd. ub/b 4096 чтобы повысить скорость PP. Так как это не размышляющая модель, то скорость tg примерно в 5 t/s будет терпимой, а скорость pp выше 100 t/s нормальной, такая позволит обрабатывать длинный контекст достаточно быстро.
У IQ3_K замер PPL всего на 1.6% хуже, чем у Q8_0 кванта (5.1808 против 5.0975). Скорость pp: 100 t/s, tg: 4 t/s.
Qwen3-Coder-480B-A35B IQ3_K
Можно взять квант, чтобы целиком влезал в память, например, IQ2_KS (144гб). У IQ2_KS замер PPL на 11% хуже (5.6578 против 5.0975). Скорость pp: 350 t/s, tg: 6 t/s
Qwen3-Coder-480B-A35B IQ2_KS
IQ2_KS хоть и просел по качеству, но с заданием справляется. Можно даже усложнить задачу, с чем у многих моделей уже сложности. Напиши на js качественный эффект как в матрице, только используй смайлы эмодзи. Сделай так, чтобы эффект было видно только в круге по центру. В одном index.html файле.
Интересно то, что Qwen3-Coder на официальном сайте не справляется с этим заданием, как и у комментатора ваше. Но в итоге с 3 раза справился, так что если кванты пишут плохой код, это не факт, что проблема именно квантов, может это модель такая.
Сейчас это работает даже получше, так как в ik_llama недавно были разработаны новые кванты, которые весят меньше, а работают лучше. По ссылке на gguf ik_llama для этой новой модели они уже используются.
Размер модели 480B-A35B, размер контекста нативные 256к и 1м через Yarn. Поддерживает Agentic Coding, можно использовать вместе с Cline или Roo Code. Рекомендуемые настройки: temperature=0.7, top_p=0.8, top_k=20, repetition_penalty=1.05
SDXL стал свободен благодаря тюнингу, флюх мне помнится опозорился неспособностью нарисовать женщину на траве, а раз про какой-то новый хайдрим ссылка вообще не на локальную версию, то и так понятно, что там будет.
Не, это SD3 не мог, а Flux как раз мог, и ещё много чего мог. И для Flux и HiDream достаточно файнтюнов на civitai.com, надо только зарегаться. И для них доступны gguf версии, так что мощное железо не требуется для запуска.
Базовый flux1-dev-Q6_K.gguf
У Flux есть Kontext, тот который может редактировать фото, он тоже работает как gguf, и для него тоже доступны файтнюны.
Да не, там всё проще, но запутанно для тех, кто не заходил к ним раньше. Раньше дефолтная модель была гибридная Qwen3-235B-A22B и по умолчанию выбрано "мышление", сейчас дефолтная это новая Qwen3-235B-A22B-2507 без мышления. Если нажать "мышление", то переключиться на старую размышляющую. И сейчас они как раз явно переименовали в 2507, а в первый день там было имя тоже самое Qwen3-235B-A22B как и раньше, но по качество ответов уже было видно, что это новая модель.
И gguf версии тоже готовы, и для llama.cpp и для ik_llama. Подобрал и сравнил 2 кванта одинакового качества, но разного квантования. Создатель k- и i- квантов (те самые Q4_K_M) недавно сделал форк ik_llama, где сосредоточился на скорости работы своих предыдущих квантов и создания новых улучшенных квантов. Я решил их сравнить, и разница в пользу ik_llama, квантованная новыми квантами модель при чуть лучшем качестве не только весит меньше, но и работает быстрее.
чем ниже ppl тем лучше
Ещё можно увидеть, что они добавили в чат Qwen3-Coder 480B-A35B с контекстом 1 млн токенов, видимо это и есть тот сюрприз, который они обещали и который от них давно ждали, так как их модели для программирования достаточно высокого уровня.
Стоить добавить, что llama.cpp это только половина, вторая половина это всем привычные кванты Q4_K_M или Q5_K_M, без которых сложно представить локальное использование моделей.
В этом форке он сосредоточен на улучшения скорости работы текущих k- и i- квантов и создании новых SOTA (передовых) квантов. Среди уже созданных новых квантов это серия IQK, которые работают быстрее и выдают лучшее качество при меньшем размере, они походят и для CPU и для GPU, кванты Trellis quants KT - эти кванты очень хороши для выполнения на CUDA, при этом имеют высокое качество, но не особо подходят для CPU, кванты с R4 - заточены на работу только на CPU.
Модель весит ~120гб, и это намного больше размера видеопамяти GPU, поэтому ускорение достигается через -ot, а основные веса крутятся на i7-14700 + DDR5 со скоростью памяти 70 гб/с. Для ускорения скорости обработки контекста PP использую -ub 4096 -b 4096.
чем ниже ppl, тем лучше
Показатель PPL у обоих квантов примерно равен, но новые кванты весят меньше (117гб против 125гб), а скорость генерации выше на той же конфигурации ПК. В зависимости от модели, квантования и оборудования разница может достигать до 2.5 раз.
Кроме прямых замеров ещё важна стабильность скорости. Например, обновленный qwen3-235B теперь поддерживает размер контекста 256к и скорость PP важна, так как PP ощутимо падает на длинном контексте, и на ik_llama падение скорости происходит медленнее, чем просто на llama.cpp.
А точно ли в их чате уже есть новая модель? С таким же именем там была модель и вчера, и позавчера...
Имя модели осталось как и было Qwen3-235B-A22B, а 2507 это дата релиза, такое именование часто, если не было смены архитектуры, встречается у обновлений, а в официальных чатах оставляют базовое имя модели. Instruct - это тоже стандартное именование означающее пост-обучение модели на следование инструкциям, кто-то это указывает, кто-то нет, потому что бывает ещё Base модель. Такая же путаница была с обновлением DeepSeek V3-0324 и R1-0528, когда не понятно обновили в чате или нет.
Официальный пост от Qwen указывает, что новая модель это теперь дефолтная модель в их чате:
В процессе прочитала 4,64 Tb с диска (это я пытался оценить "износ" SSD, так как существуют модели размером с терабайт и более, и такие модели в память не поместятся, будут читаться и перечитываться с диска, и я боялся, что это может сильно снизить ресурс SSD).
Довольно популярный миф, но чтение с SSD не влияет на износ диска и не снижает его ресурс, только запись на диск. Показатель TBW, который используют для оценки ресурса и износа, расшифровывается как раз как Total Bytes Written.
"--cache-type-k", "${CACHE_TYPE_K:-q4_0}", Получившиеся данные стали для меня откровением. Оказалось что несмотря увеличение скорости генерации токена, общее время ответа растёт, модели дают ответы содержащие больше токенов. При этом ещё и снижается качество ответов.
Любые замеры качества при квантовании кэша q4_0 не имеют смысла, так как любое квантование кэша даёт непредсказуемый результат качества, а на столько экстремальное тем более.
q4_0 это опция только для тех, кому любой ценой надо сэкономить память. Только q8_0 можно считать условно не влияющим на качество, но надо держать в голове, что что-то может пойти не так, особенно в программирование, где каждый символ имеет значение.
Динамическое квантование UD, то есть улучшенное качество по сравнению с обычными квантами, имеют только UD-...-XL кванты, остальные кванты имеют обычное квантование, поэтому UD-IQ2_M так отличается. UD-Q2_K_XL с натяжкой всё еще влезает в 256гб памяти, с учётом разгрузки на GPU.
И только с UD-IQ2_M из представленных в тесте возможен переход в сборке на более бюджетные модули памяти по 32GB вместо модулей по 64GB.
Если интересует малый размер и повышенное качество - стоит попробовать ik_llama.cpp. Бонусом будет в 1.5-2 раза возросшая скорость.
В ik_llama представлена серия новых SOTA квантов, которые работают быстрее, весят меньше, и дают качество лучше. Например, среди них DeepSeek-R1-0528-IQ2_K_R4, размер 220гб, с запасом укладывается в 256гб, при этом падение качества ppl всего 9%, с 3.21 до 3.5. PPL не лучший показатель, но он является быстрым замером примерного уровеня.
Интересно, спасибо. С контекстом правда у Hunyuan для русского языка не очень, хоть он и 256к, но он примерно в 1.35 раза менее эффективен чем у DeepSeek для токенов на русском, поэтому книга целиком не влезла в контекст, требуется 289к, у deepseek 215к.
Сегодня появился новый претендент. Kimi K2 - новая открытая MoE модель на 1T параметров, если точнее 1026B, с 32B активными. Сделана на архитектуре deepseek, поэтому MLA присутствует, и поддержка должна появиться довольно быстро.
И самое главное, это не мыслящая модель, значит не будет тысячами бесполезных токенов размышления, при этом качество по бенчмаркам конкурентоспособное:
Я не знаю на сколько из далека вам нужна теория, поэтому с самого начала, если что просто переходите на следующий пункт.
Про квантизацию
Веса модели это массив млрд цифр типа float. Стандартный размер float это 32-бита на вес, то есть это числа такого вида:
0.340282347234423412354675889478Эти числа образуют собой матрицы чисел, матрицы (тензоры) перемножаются друг на друга и модель выдает результат. Фактически в модели нет ничего кроме этих чисел, там нет скрытых слоев знаний или слоев данных, просто так удачно сложились значения этих весов, что на выходе выходит что-то осмысленное плюс различные эмерджентные свойства. Подбор этих весов это и есть обучение модели.
Количество цифр после запятой велико, чем дальше они от начала, тем меньший вклад вносят в итоговый результат умножения, поэтому можно просто сократить их в 2 раза и перейти на float16. Это имеет почти нулевое влияние на качество, но увеличивает скорость инференса и скорость обучения в 2 раза. float16 уже выглядит так:
0.124523642623604616 бит на вес - цифр после запятой всё ещё достаточно, можно сократить их ещё в 2 раза и получить fp8, в fp8 как раз обучена DeepSeek, но обычно другие модели обучают до сих пор в f16.
Есть ещё всякие детали, вроде распределения мантисы и экспоненты, и то, что сейчас используют более точный bfloat16, вместо обычного float16, есть fp4 в nvidia 5000 серии и т.д. Чтобы квантование в fp4 или fp8 хорошо работало, устройство должно поддерживать операции с этим типом чисел, иначе нужны преобразования весов на лету до поддерживаемых типов.
Квантование в gguf работает не просто сокращением чисел после запятой, там в основном используются целочисленные типы int, а перегнать число с плавающей запятой в int - это само по себе снижение точности, в gguf же ещё происходит и объединение весов в суперблоки, из-за чего срезаются выбросы, если в суперблок попали веса не похожие на общие в среднем веса суперблока. В среднем если точности хватает, это не так важно, но чем агрессивнее квантование, тем больше будет потерь.
Ну это упрощенно, gguf позволяет сохранять веса и без квантования и квантовать любым другим способом, не только через суперблоки. Например, в ik_llama недавно добавили Trellis quants IQx_KT, работающие аналогично как в exl3, и они в целом дают лучшее качество при меньшем весе и большую скорость, но хорошо работают только на GPU, на CPU происходит просадка скорости.
Цифра рядом с Q - это то количество бит, которое будет затрачено на основные веса модели, а буквы XL, L, M, S - это на сколько выше будут квантованы важные тензоры, например, внимания, которые сильнее влияют на качество, чем основное тело модели.
L - Large на 2-3 уровня выше, M - Medium на 1-2 уровня выше, S - Small на 0-1 уровня выше. Ну и XL - eXtra Lagre, там динамичное число и могут быть на много уровней выше.
Например, вначале в gguf было квантование прямо в лоб, был тип Q4_0 - это просто урезание весов до int4, или 4 bpw (bite per weight), или чуть позже Q4_1, оно чуть получше, но эти типы работали плохо и качество сильно падало.
Потом пришел Kawrakow (тот самый создатель форка ik_llama) и сделал нормальные кванты. Его выступление об истории квантова можно посмотреть тут: https://fosdem.org/2025/schedule/event/fosdem-2025-5991-history-and-advances-of-quantization-in-llama-cpp/
Сам алгоритм квантования был изменен, качество стало выше, размер меньше. Эти кванты до сих пор везде используются как база, те самые популярные Q4_K_M или IQ4_XS.
Q4 - это 4 бита на основные веса
K - это скорее всего Kawrakow, просто отделяет Q4_0, Q5_0 кванты от Q4_K, Q5_K и т.д.
M - Medium, значит важные веса на 2 уровня выше и квантуются как Q6_K.
Супер важные тензоры остаются в fp32 или f16 (f16 - это общее название для bf16 и fp16).
В таких квантах тензоры квантованы не равномерно и суммарный BPW для Q4_K_M будет 4.82 BPW, при этом размере чуть больше чем у Q4_0, по качеству это выходит почти как 5 бит на вес, соответственно и качество ощутимо лучше.
IQ4_XS или IQ2_XSS - это уже более продвинутый тип квантования через матрицу важности imatrix, сами XS и XSS это уже именно алгоритмы квантования тензоров, количество S передает смысл сохраняемой точности, чем их больше, тем ниже точность.
В форке ik_llama есть новые кванты IQ2_KS и KSS, в данном случае K просто показывает, что это другой квант, у них точность выше чем у XS и XSS, а размер тот же.
В общем чем ниже число, тем ниже бит на вес, тем хуже качество модели. 8 бит на вес работает почти без потерь, квантование Q6_K - очень близко к без потерь, Q5_K_M процентов на 2-3% хуже, Q4_K_M процентов на 5% и т.д.
IQ кванты лучше чем статичные K кванты, поэтому IQ4_XS весит меньше, но работает на уровне Q4_K_M. Кванты из ik_llama ещё лучше, поэтому могут весить ещё меньше при том же качестве.
В общем это примерное описание, не нужно воспринимать эту информация как истину, этого достаточно, чтобы примерно понимать что к чему, но везде могут быть исключения и прочие тонкости.
Качество отличается, квантование это способ снизить размер за счет снижения качества. Весь смысл в том, сколько качества нужно потратить на каждый шаг снижения веса. Один из способов померить разницу - это замерить PPL или KLD, их описание есть в статье. Чем эти значения ниже, тем меньше отклонений от оригинальной модели.
Кроме общего представления, можно заметить, что новые кванты из ik_llama весят меньше, а PPL такой же как у более крупных квантов, квантованных старыми способами.
Например, новый квант IQ2_KS весит 196гб и имеет PPL 3.6378, а квант UD-Q2_K_XL весит 234гб и PPL 3.6062. Разницы почти нет, при этом размер на 38гб меньше. Новый квант IQ2_K_R4 имеет размер 220гб и PPL 3.5069, что ощутимо ниже чем у UD-Q2_K_XL, а вес меньше на 14гб.
Но разницы почти нет это довольно условное представление. Разницы почти нет на тексте wiki.test.raw, это узкий диапазон текстов на английском из википедии, а для другого языка или для вашего редкого сценария разница может быть куда более ощутимой.
Потребление VRAM будет разное, чем сильнее квантование, тем меньше, по сути столько, сколько весит модель физически + размер контекста, столько и нужно VRAM или RAM.
Веса распаковываются на лету, поэтому скорость работы разных квантов будет разной, так как везде разные алгоритмы, и поэтому эту скорость можно ускорить на той же пропускной способности памяти. По крайней мере для скоростей PP это заметная разница.
i-кванты обычно тяжелее по вычислительным ресурсам, чем статичные K-кванты. Я как-то давно делал простое сравнение, хотя размер по весу у моделей примерно одинаковый, но скорости отличаются. Новые IQK кванты легче старых i-квантов (в сравнении их нет):
Про сильно лучше - это сомнительно, что сильно, но лучше это да, обычно чем больше цифра и какие бы ни были символы, тем лучше.
И там разница почти 1гб, это можно дополнительно ~16к контекста вместить, это не так уж и мало, иногда как раз 0.5гб и не хватает и взять их не откуда.
Опять же, исключением для цифры может быть у разного типа квантования, например, старые из llama.cpp и новые из ik_llama.cpp. На графике выше видно, что новый IQ3_K_R4 на том же уровне как старый IQ4_XS, при этом новый весит на 33гб меньше, но это скорее исключение.
В статье есть немного про спекулятивное декодирование, в DeepSeek оно называется MTP.
Смысл в том, что нужна очень маленькая модель для черновиков, на которую не жалко потратить немного ресурсов, и они должны быть из одного семейства, иначе не заработает.
Сначала маленькая предлагает последовательность токенов, например 16 новых токенов, большая модель внедряет эти токены в свою последовательность и производит расчет, если вероятности совпадают, то большая принимает эти токены. Ускорение происходит за счет того, что большая модель не тратит время на генерацию шаг за шагом, а проверяет вероятности сразу для всех токенов параллельно. Сам алгоритм не так важен, главное, что за счет kv-кэша проверить токены быстрее, чем высчитать их с нуля.
Маленькая модель - это 0.6B, 1B или 1.5B, размеры 3B или 4B уже слишком большие, но и они могут быть полезны в редких ситуациях.
Берем gemma-3-27b UD-Q5_K_XL, она занимает 21гб. Берем gemma-3-1b Q4_K_M, она занимает 800мб. Черновой модели тоже нужен контекст, где-то суммарно будет 1.5гб VRAM, две модели влезают в 24гб + 22к контекста.
Ускорение в 1.5 раза, и никаким другим способом не получить такое ускорение столь малыми усилиями.
Если взять большую MoE Qwen3-235B-A22B, в качестве черновика маленькую dense Qwen3.
Вместо
-ot exps=CPUтеперь писать просто--cpu-moe.Qwen3-235B-A22B-2507-UD-Q4_K_XL + Qwen3-4B-UD-Q5_K_XL:
.\llama-server -m "Qwen3-235B-A22B-Instruct-2507-UD-Q4_K_XL-00001-of-00003.gguf" -ts 24,0 -ngl 99 --cpu-moe -fa -t -1 -md "Qwen3-1.7B-UD-Q4_K_XL.gguf" -ngld 99 --no-warmupПроцент принятия 56%, было 4.8 t/s, стало 7.1 t/s, ускорение в 1.5 раза, вполне нормально, можно попробовать подобрать другую модель для черновика или квант этой модели. Но черновая модель не всегда помогает, может сделать и хуже.
По умолчанию черновик генерирует последовательность в 16 токенов, шанс что будет принята такая длинная последовательность не велика, а времени тратится и на проверку и на генерацию.
Если модели очень сильно отличаются, то тут может помочь снизить длину последовательности.
Параметром
--draft-max 4или--draft-max 8можно сократить последовательность до 4/8 токенов.Тут тот случай, когда для большой Qwen3-235B-A22B-2507 в качестве черновика лучше подойдет Qwen3-4B, урезав последовательность до 4 можно получить скорость 7.5 t/s, но правда это всего на 0.2 t/s больше, чем Qwen3-1.7B, с которой 7.3 t/s.
Возьмем огромную модель Qwen3-Coder 480B-A35B, черновая Qwen3-1.7B. Модели уже совсем разные по качеству ответов. Черновая модель с базовыми настройками делает хуже, уменьшение длины последовательности помогает и увеличивает процент принятия до 73%, хотя дает прирост скорости всего 5%, с 5.9 до 6.3 t/s.
И ещё один вариант, когда модель не влезает в RAM и считывается с nvme. Снова огромная Qwen3-Coder 480B-A35B, в кванте UD-Q3_K_XL.
Тут уже черновая модель помогает намного лучше, было 2.3 t/s, стало 4.2 t/s, с натяжкой можно пользоваться.
Тут тоже информация не на 100% верная, нужно перепроверять и тестировать.
Задержки будут большими, да и нет такого функционала.
Можно использовать 2 GPU. Основную модель запустить на основной GPU, а черновую на второй карте. Не знаю, можно ли так сделать в LM Studio, в llama-server это делается командой:
.\llama-server -m "gemma-3-27b-it-UD-Q5_K_XL.gguf" -ts 24,0 -ngl 99 -fa -md "gemma-3-1b-it-Q4_K_M.gguf" -ngld 99 -devd cuda1Через
-ts 24,0запрещаем использовать вторую GPU для основной модели, через-devd cuda1направляем draft модель на устройство cuda1.-ngl 99выгрузить все слои основной модели,-ngld 99выгрузить все слои черновой модели.Вторая карта медленная 4060, поэтому ускорение слабое, но всё равно есть:
Попробуйте whisper.cpp, должно быть быстрее на 3070. Модели в формате ggml (по сути тоже самое, что gguf) лежат тут: https://huggingface.co/ggerganov/whisper.cpp. У whisper ещё вышла модель whisper-large-v3-turbo, она быстрее и легче чем просто large-v3.
На 4060ti часовая лекция разбирается:
– за 7 минут на large-v3 неквантованная, 4гб vram
– за 5.1 минуты на large-v3 в кванте q5_0, 2.5гб vram
– за 2.3 минуты на large-v3-turbo в кванте q8_0, 1.6гб vram.
Есть файнтюны для русского языка, но тоже не идеальные:
– для large-v3: Andrei1980/whisper-large-rus-ggml (обучена лучше)
– для large-v3-turbo: dvislobokov/whisper-large-v3-turbo-russian (обучена хуже, путает слова)
Для английского есть модели получше чем whisper, рейтинг тут: https://huggingface.co/spaces/hf-audio/open_asr_leaderboard
Для русского ещё есть модели: vosk, GigaAM и T-one.
Qwen устроил неделю релизов. Суммарно они представили по хронологии:
Qwen3-235B-A22B-2507
Qwen3-235B-A22B-Thinking-2507
Qwen3-Qwen3-Coder-480B-A35B
Qwen Wan2.2 размером 5B и 14B (генерация видео из текста или из картинки)
Qwen3-30B-A3B-Instruct-2507
Qwen3-30B-A3B-Thinking-2507
Qwen3-Coder-30B-A3B-Instruct
Маленький Qwen3-Coder-30B-A3B они назвали Qwen3-Coder-Flash, для своего размера он показывает не плохие результаты.
Серия маленьких 30B-A3B моделей интересна не только тем, что их можно запустить даже на CPU с нормальной скоростью, так как активных параметров всего 3B, но и тем, что увеличили нативный контекст до 256к.
Большая Qwen3-235B-A22B-Thinking-2507 сделала лучший пересказ книги, книга занимала 215к токенов и влезала целиком в 256к, теперь интересно на сколько хорош контекст у очень легковесной Qwen3-30B-A3B-Thinking-2507. Модель маленькая, и можно её сравнить с Gemma3 27B у которого 128к.
Результат Gemma3 уже есть в статье, он выдумывает и ошибается даже на 32к контексте. Поэтому тот же вопрос, что и для Gemma3 27B.
Сам ответ правильный, это при том, что в контекст загружена вся книга целиком, а не как в случае Gemma только 32к контекста, но последний момент с уходом в Лабиринт Смерти - технически правильно, но тут как будто бы это не к месту упомянуто, так как перед походом было много других событий.
Можно попробовать дать куда более сложное задание, пройти по всей книге и обобщить факты из разных эпизодов, из начала, середины и конца книги. Это частая проблема для многих моделей на SWA, так как скользящее окно контекста обычно всего 4к.
Для такой маленькой модели ответы вполне хороши. Ошибка и путаница про встречи с Маньяком, часть правильно, часть спутана, части не хватает, но это как раз и есть самая сложная часть собрать по книге все встречи.
После провала Gemma3 27B и Llama4 Scout 109B-A17B, казалось что маленькие модели не способы переваривать огромный контекст, но у Qwen3 30B-A3B на первый взгляд получилось куда лучше.
В предыдущем комментарии я слегка ошибся, для вмещения 256к контекста нужно не 8гб, а 23гб. Скорости на скриншотах низкие, так как почти всю память отдал под контекст, используя -ot exps=CPU даже тут, если контекст уменьшить, то скорости будут ожидаемо большими. Появились сборки бинарников ik_llama под Windows, бенчмарк скорости на них: https://github.com/Thireus/ik_llama.cpp
Разгрузка на одну GPU через
-ngl 99 -ot exps=CPU -faПодробнее как это работает:
Запускаем настоящую DeepSeek R1 671B на игровом ПК и смотрим вменяемая ли она на огромном контексте (160к)
Квант IQ4_K: 7гб VRAM + контекст + 134гб RAM.
Квант UD-Q2_K_XL: 5гб VRAM + контекст + 82гб RAM.
8к контекста требуют 0.7гб VRAM, 256к контекста требуют 25гб. Контекст работает через SWA, включается автоматически при использовании
-fa.Скорости выше уже были:
Сейчас вышли ещё 2 большие модели:
Qwen3-235B-A22B-Thinking-2507 на данный момент с лучшим удержанием контекста среди локальных моделей
Qwen3-Coder-480B-A35B, которую всё еще можно запустить локально
И скоро должна выйти маленькая Qwen3-30B-A3B-Instruct-2507.
Вышла от Qwen модель для видео Wan 2.2 5B и 14B, требует от 8гб VRAM, для 14B gguf уже есть.
Только что вышли GLM-4.5-355B-A32B и GLM-4.5-Air-106B-A12B от Zhipu AI:
Автор пишет, что это закрытый бенчмарк, только несколько примеров показывает. В целом можно понять, что из себя этот бенчмарк представляет:
https://www.reddit.com/r/LocalLLaMA/comments/1jbgezr/comment/mhu4nxo/?context=3
Да, если включен mmap, то всё что выгружено в VRAM уже не использует в RAM, в итоге доступный объема памяти под модель это RAM + VRAM, и если этого не хватит, то автоматически залезет на nvme.
Если mmap выключен (например, он автоматически выключается если использовать
-rtr), то такое не работает, так как без mmap модель вначале будет целиком загружена в RAM и не освободит её после разгрузки.IQ4_KSS впритык, 128гб это 119 ГиБ, а квант весит 114 ГиБ, с учётом разгрузки в VRAM влезет, если память ни на что другое не тратится. Но всегда есть IQ3_K (106 ГиБ), он всего на 3.2% по PPL отличается от BF16, а IQ4_KSS на 2.1%.
Весь 256к контекст с полной выгрузкой
-ot exps=CPUне влезает в 24гб. У модели 93 слоя, для теста с книгой я смог выгрузить только 45, это ощутимо ударило по скорости tg, и учитывая, что это размышляющая модель, если не нужен полный контекст, то лучше выгрузить все слои.Если нужен полный, то можно попробовать выгрузить на 2 gpu указав
-mg 0(main gpu X) для той, где будет контекст, а оставшиеся слои выгрузить на вторую, но тут надо экспериментировать.Сегодня вышла новая MoE модель Qwen3-235B-A22B-Thinking-2507. У неё контекст 256к, для вмещения всего контекста в q8_0 нужно примерно 8гб, модель использует GQA и SWA, через
-faэто работает.Модель относительно небольшая 235B (BF16: 437 ГиБ, PPL = 4.1898), поэтому можно спокойно взять адекватный квант IQ4_K (134 ГиБ, PPL = 4.2407) или IQ4_KSS (114 ГиБ, PPL = 4.2799) - это новые типы квантов, потери по замеру PPL всего 1-2%.
Для ik_llama: https://huggingface.co/ubergarm/Qwen3-235B-A22B-Thinking-2507-GGUF
Для llama.cpp: https://huggingface.co/unsloth/Qwen3-235B-A22B-Thinking-2507-GGUF
На длинном контексте по бенчмарку эта модель на данный момент лучше остальных опенсорсных, и конкурирует с закрытыми, кроме совсем топовых:
Решил посмотреть как эта модель покажет себя на Лабиринте Отражений. Книга на этой модели занимает 215к токенов, в 256к как раз влезает целиком:
В общем могу подтвердить, пока это самый точный пересказ книги, оценена была именно книга целиком. Модель легко разделяет двух Вик, и с другими конкретными вопросами модель тоже справляется успешно.
https://openai.com/index/memory-and-new-controls-for-chatgpt/
Цитата оттуда:
i7-14700 + 192гб (или 188 гиб) DDR5 4800 MT/s + 4090 + nvme PM9A1. 4060 не добавлял, так как не хотелось подбирать перенос тензоров. В общем запускал с самой ленивой
-ot exps=CPUкомандой.Активных параметров у модели 35B, вес кванта 216 гиб + контекст, в итоге чтение с nvme не такое большое, как по объему так и по скорости, поэтому просадка tg не такая заметная, но всё равно из-за этого скорость получилась ближе к 4 t/s, чем к 5 t/s.
Вот эта разница между гб и гиб как раз не позволяет этот квант целиком вместить даже с учетом разгрузки, поэтому добавление 4060 не сильно поможет. Пришлось снизить ub/b до 3072, чтобы выгрузить лишний слой:
Ещё когда вышла Kimi K2 размером 1026B-A32B, запускал на тот момент самый маленький квант Kimi-K2-Instruct-UD-IQ1_S, он весит 262гб, это уже ощутимо не влезает в память и необходимость постоянного чтения с nvme уже по полной просаживает скорость:
Сейчас уже добавили версию smol-IQ1_KT размером 219гб и потерей по PPL в 30%, не запускал, но думаю скорость будет примерно такой же ~4 t/s, как и у Qwen3-Coder.
На openrouter бесплатную версию уже добавили: https://openrouter.ai/qwen/qwen3-coder:free
Запускал IQ3_K (216гб), он не влез в 188гб ram памяти, поэтому частично запускался с ssd. ub/b 4096 чтобы повысить скорость PP. Так как это не размышляющая модель, то скорость tg примерно в 5 t/s будет терпимой, а скорость pp выше 100 t/s нормальной, такая позволит обрабатывать длинный контекст достаточно быстро.
У IQ3_K замер PPL всего на 1.6% хуже, чем у Q8_0 кванта (5.1808 против 5.0975).
Скорость pp: 100 t/s, tg: 4 t/s.
Можно взять квант, чтобы целиком влезал в память, например, IQ2_KS (144гб).
У IQ2_KS замер PPL на 11% хуже (5.6578 против 5.0975).
Скорость pp: 350 t/s, tg: 6 t/s
IQ2_KS хоть и просел по качеству, но с заданием справляется. Можно даже усложнить задачу, с чем у многих моделей уже сложности.
Напиши на js качественный эффект как в матрице, только используй смайлы эмодзи. Сделай так, чтобы эффект было видно только в круге по центру. В одном index.html файле.Интересно то, что Qwen3-Coder на официальном сайте не справляется с этим заданием, как и у комментатора ваше. Но в итоге с 3 раза справился, так что если кванты пишут плохой код, это не факт, что проблема именно квантов, может это модель такая.
С этим с недавних пор как раз меньше проблем. Вот запустил на домашнем ПК:
Месяц назад я писал статью о том, как запускать такие большие модели на домашнем железе: Запускаем настоящую DeepSeek R1 671B на игровом ПК и смотрим вменяемая ли она на огромном контексте (160к).
Сейчас это работает даже получше, так как в ik_llama недавно были разработаны новые кванты, которые весят меньше, а работают лучше. По ссылке на gguf ik_llama для этой новой модели они уже используются.
Размер модели 480B-A35B, размер контекста нативные 256к и 1м через Yarn. Поддерживает Agentic Coding, можно использовать вместе с Cline или Roo Code.
Рекомендуемые настройки: temperature=0.7, top_p=0.8, top_k=20, repetition_penalty=1.05
Бенчмарки от разработчиков:
gguf для llama.cpp: https://huggingface.co/unsloth/Qwen3-Coder-480B-A35B-Instruct-GGUF
gguf для ik_llama: https://huggingface.co/ubergarm/Qwen3-Coder-480B-A35B-Instruct-GGUF
Попробовать онлайн (без регистрации, но быстро наступят лимиты): https://chat.qwen.ai/
Или (тут только html/js разработка): https://huggingface.co/spaces/Qwen/Qwen3-Coder-WebDev
Не, это SD3 не мог, а Flux как раз мог, и ещё много чего мог. И для Flux и HiDream достаточно файнтюнов на civitai.com, надо только зарегаться. И для них доступны gguf версии, так что мощное железо не требуется для запуска.
У Flux есть Kontext, тот который может редактировать фото, он тоже работает как gguf, и для него тоже доступны файтнюны.
Да не, там всё проще, но запутанно для тех, кто не заходил к ним раньше.
Раньше дефолтная модель была гибридная Qwen3-235B-A22B и по умолчанию выбрано "мышление", сейчас дефолтная это новая Qwen3-235B-A22B-2507 без мышления. Если нажать "мышление", то переключиться на старую размышляющую. И сейчас они как раз явно переименовали в 2507, а в первый день там было имя тоже самое Qwen3-235B-A22B как и раньше, но по качество ответов уже было видно, что это новая модель.
Для тех кому нужно API, на openrouter уже добавили бесплатную версию: https://openrouter.ai/qwen/qwen3-235b-a22b-07-25:free
И gguf версии тоже готовы, и для llama.cpp и для ik_llama. Подобрал и сравнил 2 кванта одинакового качества, но разного квантования. Создатель k- и i- квантов (те самые Q4_K_M) недавно сделал форк ik_llama, где сосредоточился на скорости работы своих предыдущих квантов и создания новых улучшенных квантов. Я решил их сравнить, и разница в пользу ik_llama, квантованная новыми квантами модель при чуть лучшем качестве не только весит меньше, но и работает быстрее.
Ещё можно увидеть, что они добавили в чат Qwen3-Coder 480B-A35B с контекстом 1 млн токенов, видимо это и есть тот сюрприз, который они обещали и который от них давно ждали, так как их модели для программирования достаточно высокого уровня.
Стоить добавить, что llama.cpp это только половина, вторая половина это всем привычные кванты Q4_K_M или Q5_K_M, без которых сложно представить локальное использование моделей.
И вот автор всех K-квантов и i-квантов - это ikawrakow, который недавно создал форк ik_llama.cpp.
В этом форке он сосредоточен на улучшения скорости работы текущих k- и i- квантов и создании новых SOTA (передовых) квантов. Среди уже созданных новых квантов это серия IQK, которые работают быстрее и выдают лучшее качество при меньшем размере, они походят и для CPU и для GPU, кванты Trellis quants KT - эти кванты очень хороши для выполнения на CUDA, при этом имеют высокое качество, но не особо подходят для CPU, кванты с R4 - заточены на работу только на CPU.
Можно посмотреть его выступление про историю квантования: https://fosdem.org/2025/schedule/event/fosdem-2025-5991-history-and-advances-of-quantization-in-llama-cpp/
Я попробовал подобрать 2 квантованные версии, которые по качеству равны для вчера вышедшей Qwen3-235B-A22B-Instruct-2507:
Qwen3-235B-A22B-Instruct-2507-UD-Q4_K_XL для классического llama.cpp.
Qwen3-235B-A22B-Instruct-pure-IQ4_KS работающие только на ik_llama, вся модель квантована как IQ4_KS.
Модель весит ~120гб, и это намного больше размера видеопамяти GPU, поэтому ускорение достигается через -ot, а основные веса крутятся на i7-14700 + DDR5 со скоростью памяти 70 гб/с. Для ускорения скорости обработки контекста PP использую -ub 4096 -b 4096.
Показатель PPL у обоих квантов примерно равен, но новые кванты весят меньше (117гб против 125гб), а скорость генерации выше на той же конфигурации ПК. В зависимости от модели, квантования и оборудования разница может достигать до 2.5 раз.
Кроме прямых замеров ещё важна стабильность скорости. Например, обновленный qwen3-235B теперь поддерживает размер контекста 256к и скорость PP важна, так как PP ощутимо падает на длинном контексте, и на ik_llama падение скорости происходит медленнее, чем просто на llama.cpp.
Имя модели осталось как и было Qwen3-235B-A22B, а 2507 это дата релиза, такое именование часто, если не было смены архитектуры, встречается у обновлений, а в официальных чатах оставляют базовое имя модели. Instruct - это тоже стандартное именование означающее пост-обучение модели на следование инструкциям, кто-то это указывает, кто-то нет, потому что бывает ещё Base модель.
Такая же путаница была с обновлением DeepSeek V3-0324 и R1-0528, когда не понятно обновили в чате или нет.
Официальный пост от Qwen указывает, что новая модель это теперь дефолтная модель в их чате:
Довольно популярный миф, но чтение с SSD не влияет на износ диска и не снижает его ресурс, только запись на диск.
Показатель TBW, который используют для оценки ресурса и износа, расшифровывается как раз как Total Bytes Written.
Любые замеры качества при квантовании кэша q4_0 не имеют смысла, так как любое квантование кэша даёт непредсказуемый результат качества, а на столько экстремальное тем более.
q4_0 это опция только для тех, кому любой ценой надо сэкономить память. Только q8_0 можно считать условно не влияющим на качество, но надо держать в голове, что что-то может пойти не так, особенно в программирование, где каждый символ имеет значение.
Динамическое квантование UD, то есть улучшенное качество по сравнению с обычными квантами, имеют только UD-...-XL кванты, остальные кванты имеют обычное квантование, поэтому UD-IQ2_M так отличается.
UD-Q2_K_XL с натяжкой всё еще влезает в 256гб памяти, с учётом разгрузки на GPU.
Если интересует малый размер и повышенное качество - стоит попробовать ik_llama.cpp. Бонусом будет в 1.5-2 раза возросшая скорость.
Создатель форка ik_llama.cpp и есть создатель того самого квантования в llama.cpp, большинство квантов сделаны им, включая K кванты и лучшие i-кванты. Можно посмотреть его выступление на Fosdem: https://fosdem.org/2025/schedule/event/fosdem-2025-5991-history-and-advances-of-quantization-in-llama-cpp/
В ik_llama представлена серия новых SOTA квантов, которые работают быстрее, весят меньше, и дают качество лучше.
Например, среди них DeepSeek-R1-0528-IQ2_K_R4, размер 220гб, с запасом укладывается в 256гб, при этом падение качества ppl всего 9%, с 3.21 до 3.5. PPL не лучший показатель, но он является быстрым замером примерного уровеня.
И ik_llama позволяет получить лучшую скорость, что даже на домашнем ПК минимальный квант можно запустить и пользоваться этим: Запускаем настоящую DeepSeek R1 671B на игровом ПК и смотрим вменяемая ли она на огромном контексте (160к)
Интересно, спасибо. С контекстом правда у Hunyuan для русского языка не очень, хоть он и 256к, но он примерно в 1.35 раза менее эффективен чем у DeepSeek для токенов на русском, поэтому книга целиком не влезла в контекст, требуется 289к, у deepseek 215к.
Сегодня появился новый претендент. Kimi K2 - новая открытая MoE модель на 1T параметров, если точнее 1026B, с 32B активными. Сделана на архитектуре deepseek, поэтому MLA присутствует, и поддержка должна появиться довольно быстро.
И самое главное, это не мыслящая модель, значит не будет тысячами бесполезных токенов размышления, при этом качество по бенчмаркам конкурентоспособное: