Comments 95
Есть ли возможность увеличить контекст, используя несколько GPU?
Среди MoE моделей вчера вышла новинка Hunyuan 80B-A13B с 256к контекстом, добавление поддержки в llama.cpp в работе.
Интересно, спасибо. С контекстом правда у Hunyuan для русского языка не очень, хоть он и 256к, но он примерно в 1.35 раза менее эффективен чем у DeepSeek для токенов на русском, поэтому книга целиком не влезла в контекст, требуется 289к, у deepseek 215к.
Сегодня появился новый претендент. Kimi K2 - новая открытая MoE модель на 1T параметров, если точнее 1026B, с 32B активными. Сделана на архитектуре deepseek, поэтому MLA присутствует, и поддержка должна появиться довольно быстро.
И самое главное, это не мыслящая модель, значит не будет тысячами бесполезных токенов размышления, при этом качество по бенчмаркам конкурентоспособное:
А что для пользователей 3060 (12) с многоядерными зионами и озу 128 ? Есть ли свет в конце туннеля? У меня полноценный дипсик работал со скоростью 0.1 t/s с подкачкой с nvme...Не, ну работал то нормально, правда неделю ждать приходилось.
А что для пользователей 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-битную уменьшить на это чуть-чуть, особо выигрыша по размеру не будет.
Спасибо! (Лайк и подписка).
Есть ли разница и повышение хэшрейта аж на 30% при переходе с Windows на Linux?
Справедливо ли всё написанное для AMD/Radeon? Для каких карт ROCm есть? Можно заставить работать? Не факт что соберётся? Не взлетит? RX 7600 XT 16GB?
Б/у-шные Tesla с Ali?
Где находится предел выгоды перехода с 3090/4090 на "профессиональные" Radeon Pro W7000 (W7800/w7900)?
Начали ли появляться ARM-платы (одноплатники со встроенными процессорами) c PCIe-4.0/5.0 способные задействовать больше 1ТБ памяти? Больше 100 ГБ?
Б/у AMD Epyc по-прежнему наше "всё" - если хотим впихнуть взрослый ДикПик в оперативу целиком?
Есть ли разница и повышение хэшрейта аж на 30% при переходе с Windows на Linux?
Я тестировал сразу на Linux, мне уже не хотелось собирать ik_llama под Windows, так как под виндой у меня не настроено окружения для сборки, и я на эту статью потратил 5 дней и уже немного устал от всего этого.
Справедливо ли всё написанное для AMD/Radeon? Для каких карт ROCm есть? Можно заставить работать? Не факт что соберётся? Не взлетит? RX 7600 XT 16GB?
У ik_llama фокус на CPU и CUDA. Позавчера я собирал ik_llama vulkan, хотел добавить в сравнение RX 6600, и он работал в разы медленнее чем в vulkan в llama.cpp, поэтому смысла нет. Не тестировал на ROCm, но думаю там такой же результат будет.
В плане llama.cpp всё будет работать нормально с -ot и на rocm, и на вулкане, только не удастся воспользоваться этими квантами от ik_llama и нужно будет подобрать квант от unsloth или bartowski.
А в плане RX7600 лучше подождать и посмотреть на Intel B60 24гб и цену, у интелов обычно шина больше и поэтому память быстрее, а XPU поддержку intel уже добавили в pytorch, что и вне llm может быть полезно.
Б/у-шные Tesla с Ali?
V100 на 32гб отлично впишется, говорят на таобао они щас дешевые.
Где находится предел выгоды перехода с 3090/4090 на "профессиональные" Radeon Pro W7000 (W7800/w7900)?
Если устраивает турбинный шум, то лучше китайскую 4090 на 48гб.
Б/у AMD Epyc по-прежнему наше "всё" - если хотим впихнуть взрослый ДикПик в оперативу целиком?
Эпики быстрые, много быстрой памяти, но ни нормальную тихую башню не поставить, ни корпус нормальный, ни дорогущую память потом ни куда не деть. Это подходит тем, кто точно знает зачем ему эпики, и зачем ему именно квант Q4 или даже Q8.
Просто принципиально кванты выше чем UD-Q2_K_XL по сути ничего не дают, несколько процентов это не существенно, тут нужен DeepSeek R2 чтобы качество принципиально выросло, гнаться за Q8 квантом не имеет практического смысла.
Сейчас в продаже появляются планки 64гб DDR5, это будет 256гб в домашний комп, туда влезает UD-Q2_K_XL, если DeepSeek R2 не вырастет в размерах, то этого хватит, если разжиреет, то да, снова эпики и зеоны будут единственным вариантом.
Б/у AMD Epyc по-прежнему наше "всё" - если хотим впихнуть взрослый ДикПик в оперативу целиком?
У AMD появилась какая-то новая игрушка: AMD Ryzen AI Max+395, 128Гб общей для ГПУ и ЦПУ памяти, где под ГПУ отводится до 112Гб. Но все это лаптоп, а не десктоп: https://www.amd.com/en/developer/resources/technical-articles/2025/amd-ryzen-ai-max-395--a-leap-forward-in-generative-ai-performanc.html
Если нормально зайдет аудитории, есть ненулевой шанс, что раскрутят и на десктопы с большим объемом памяти.
Зашла нормально, на ютубе и реддите полно сравнений с M4 Max, rtx 4090 и т.д. По соотношению цена/скорость лучше всего видеокарты с широкой шиной памяти (nvidia xx90), но если нужно более 24 Гб, то или китайские 4090 48g или тогда уже этот AI Max+395 (у обоих решений цена 2к+).
Вот хороший обзор
Исходя из опыта и обсуждений различных конфигураций. Скорость генерации токенов - inference - напрямую зависит от результирующей псп. Влияние ОС на ПСП - вроде меньше 2%(кроме случае нестабильной работы).
>AMD/Radeon? - сделали два шага вперед, можно запустить все что может запустить inference, но в долгую можете столько камней насобирать, что никто не рискуют за свои деньги.
Б/у-шные Tesla с Ali?
В зависимости от поколения могут не поддерживать определенные виды вычислений - страдает скорость.
>Где находится предел выгоды перехода с 3090
1x3060 12gb - входной порог.
1x3090 24gb - можно поиграться дома.
2x3090 ~48gb - можно обзапускаться всякого локального, работает хорошо. Но хочет кушать и охлаждаться.
3x3090 самое интересное дома. Дальше одна 96gb карточка. Но есть предположение, что это оверкил. Интересно поиграться - не интересно работать - реальная скорость работы слишком низкая. Проще взять подписку у большого провайдера за 20-200$$ в месяц.
>Б/у AMD Epyc по-прежнему наше "всё"
Рынок говорит что да. В какой то момент их раскупили и они не стали проседать в цене.
Но зреют модели с унифицированной памятью, в теории могут быть хорошим сдвигом в сторону LLM, на практике - мало кто рискует за свои деньги. 3090 за 50к в рублях интереснее.
Буквально на днях проверял работу в лине на облачном gpu и сравнивал с win-домашним. На удивление домашний даже чуть побыстрее был. Разница в районе единиц процентов. С другой стороны на облачном еще может влиять интерференция от других пользователей. Но в любом случае речь не про десятки процентов.
Могу предположить, что речь про десятки процентов пошла оттого, что в своё время рендеринг в blender 3d под линуксом оказался быстрее на 30%, чем на том же компьютере, но в винде. Сейчас ситуация даже там выровнялась (винда всё ещё показывает просадку скорости, но разница - от 2 до 6%), но осадочек в народной памяти остался.
Спасибо, полезная статья и подталкивает уже начать собирать своего «домового». Вопрос знатокам: если взять GeForce RTX 5060 Ti 16GB + материнку с PCIe 5.0 + AMD Ryzen 9 9950X3D + 192 ГБ DDR5, будет ли комфортно использовать модели, например, Q4 32b, а также подобные, как в статье? Перебирал разные варианты, и ниже 300 т.р. не выходит c 2мя GPU картами.
Самое эффективное железо которое вы можете купить - б/у 3090, в любом количестве. Только оно все горячее.
Из интересных альтернатив - железо на унифицированной памяти - mac a3/a4, amd ryzen ai 395. Но - половина софта может не запуститься с коробки. Так что на свой страх.
да и топовый процессор с X3D и кучей ядер не ускорит особо инференс, упор идёт в скорость ОЗУ (~100 Гб/сек для DDR5 6400). 1 ядро обрабатывает 20гб/сек, можете ради экономии купить что-то на 6-8 ядер, а на сдачу возьмите 3090.
Пока кажется, что две б/у видеокарты GeForce RTX 3090 с 24 ГБ памяти (в сумме 48)— оптимальный выбор для домашнего использования в пределах до 300 тысяч рублей. Однако есть риск, что GPU может быть «уставшей».
Бенчмарк Qwen3 32B Q4_K_M на 4060ti 16gb, влезло 48 слоев из 65:
В системный промпт скопирован текст всей книги, context shift включается автоматически, попросим пересказать сюжет:
Сделал это на онлайн-версии, получил сообщение, что загрузилось 85% текста, никакой контекст шифт не включился, я так понял, она просто обрезала текст.
попросить точно процитировать эпиграф из самого начала. В ответе полностью выдуманный текст, ничего общего с оригиналом:
при этом эпиграф процитирован идеально (что ожидаемо)
Урежем книгу до 100к токенов, теперь текст полностью влезает в контекст.
а это как сделать?
В каком месте книги кто-то сказал "Звёзды слишком яркие."? Процитируй весь диалог
А вот тут он вчистую нафантазировал
Сделал это на онлайн-версии, получил сообщение, что загрузилось 85% текста, никакой контекст шифт не включился, я так понял, она просто обрезала текст.
context shift это в ik_llama/llama.cpp, это их придумка, которая скорее мешает, чем помогает если про неё не знать, в нативной версии трансформера такого нет.
а это как сделать?
Из txt файла удалять куски текста с конца и смотреть через llama-tokenize результат, когда будет 100к, значит достаточно.
Хороший специалист и плохой русский язык. Теперь стало обычным явлением писать плохо.
Добрый день
Подскажите, а вы не встречали, можно ли с MoE моделькой провернуть следующее:
Есть RAM для одного экземпляра модели, 2x GPU (с объемом VRAM одного GPU достаточном для загрузки слоёв активного эксперта).
В RAM загрузить один экземпляр модели, а в VRAM одного GPU загрузить слои активного эксперта, а в VRAM второй GPU - ещё один экземпляр эксперта активного эксперта.. И отдельными процессами запускать инференс, параллельно через роутинг.
В плане, я видел как в RAM 2х экземпляра грузят модели, и двумя процессами отдельно инференсят используя роутинг. Например, есть 1024 GB RAM и 2 GPU, и параллельно запускают два отдельных Qwen3-235B-A22B + Qwen3-235B-A22B.
Но, если RAM мало, то может есть хаки с тем, чтобы оставить один экзепляр всей модели в RAM.
На ум приходит аналогия с совместным использованием библиотек процессами (одна либа в памяти, и разные процессы ее юзают).
На ум приходит аналогия с совместным использованием библиотек процессами (одна либа в памяти, и разные процессы ее юзают).
Есть параметр --parallel N, где N количество параллельных запросы к одной и той же модели. Памяти расходуется столько же, так как на N слотов будет общий размер контекста, но чтобы это нормально работало, должно хватать вычислительных мощностей, чтобы справиться с параллельной работой.
1 запрос, скорость 41 t/s:
4 одновременных запроса, скорость одного слота упала до 28 t/s, но суммарно 112 t/s:
Да вот как раз, чтобы скорость не падала и поднимают несколько экземпляров.
Две модели и каждой выделить узел Numa + свою GPU норм, если достаточно RAM..
А насколько GPU Загружена была при 4х параллельных запросах?
А насколько GPU Загружена была при 4х параллельных запросах?
При 1 запрос: cpu 11%, gpu 95%
При 4 запросах: cpu 16%, gpu 86%
Это возможно проблема или особенность llama.cpp, сейчас там общий kv-кэш, параллельный вариант пока не реализован: https://github.com/ggml-org/llama.cpp/issues/10860
Как я понимаю, все эти LLM локально запускать на личных ноутбуках вообще никто не сможет ещё N лет.
Сильно зависит от размера, а размер зависит от требуемых задач. Методы квантизации развиваются, методы сгружения части работы в оперативку тоже улучшаются. Так что никто не знает.
Плюс есть подключаемые по USB ускорители нейронок. Они и сейчас есть, но они маленькие - их создатели не ожидали такого повышения спроса на размер, и раньше стремились к уменьшению энергопотребления. Тоже могут скоро выдать рабочий вариант.
Ну вот у меня ноут купленный еще во времена ковида с мобильной 3080 правда с 16Гб видеопамяти, phi-4 reasoning c 14b параметров вся влезает в видеопамять и выдает 30 токенов в секунду, сильно быстрее чем человек может читать:
mistral-small3.2 на 24b параметров занимает 26Гб, влезает на 59% в видеопамять и на 41% в обычную, она выдает 19 токенов в секунду, все также сильно быстрее, чем успеваешь прочитать.
Больше чем на 24 миллиарда параметров запускать не пробовал. Так что все реально даже на старых ноутах их запускать. Правда небольшие модели.
Жоска. Я бы, наверное, игрался под жирным (по памяти) маком на М чипе.
умеют ли современные LLM запрос аля "найди в книге фрагмент" превращать вместо долгой работы "нейронов" в типичный Select from ... Where Text like "искомый фрагмент" и исполнить его ? наверное это было бы в тысячи раз экономичнее
Так это узкий кейс. Кто в здравом уме использует модели как ctrl+f, если это не для тестирования? Тут это тестирование на хранение контекста, а в реальной жизни “искомого фрамента” не будет, а будет вопрос на человеческом языке “а какое пиво пил главный герой с этим, как его, у него еще ник странный был, “убийца” или что-то типа того?"
не специалист в этой теме, но возникает закономерный вопрос, а ии-модели могут предварительно делать какую то индексацию/нормализацию контекста, выделять ключевые признаки, индексировать только их и держать в памяти, а конкретику кэшировать и возвращаться к ней при необходимости? это вопрос в контексте использования для базы нормативных документов например
Ищите по слову RAG
А насколько теоретически топовый MBP16 с 128 под это дело годится?
Мне просто под обычные задачи такое совсем не надо, но если есть возможность прилично запускать LLM, то можно подумать над переплатой тыщи в полторы прям за топ.
Спасибо за статью - узнал много нового про параметры запуска в которых трудно было разобраться самому.
Правильно ли я понял, что MLA есть только у DeepSeek и поэтому на больших контекстах DeepSeek работает лучше любых других моделей?
Правильно ли я понял, что MLA есть только у DeepSeek
На данный момент да, пока не было замечено других моделей на MLA.
Есть такой проект TransMLA через который можно мигрировать через пост-обучение с GQA на MLA. По их замерам преобразованная модель лучше себя показывает чем исходная:
и поэтому на больших контекстах DeepSeek работает лучше любых других моделей?
Если сравнивать с моделями на GQA (Group Query Attention), это примерно все открытые модели на момент выхода R1, то да. Если сравнивать с закрытыми моделями, то там по разному, есть явные лидеры, вроде Gemini 2.5 pro, которые обгоняют всех, а есть такие с кем R1 сравнима или лучше их.
Ещё бывают и другие эксперименты с вниманием, вот, например, недавно вышла открытая модель Minimax M1, они используют гибридный Lightning Attention, как раз только что вышла статья разбора архитектуры (https://habr.com/ru/articles/923588/), она ещё дешевле в обучение, ей нужно меньше вычислений чем R1 и у неё контекст 1м, но нет такой эффективной экономии памяти как у MLA.
В общем тут нет какого-то однозначного ответа:
А вы не знаете, ik_llama.cpp так же поддерживает xpu (intel), как и llama.cpp? При загрузке слоев вы указываете CUDA0, CUDA1, а для XPU тоже есть аналогичный выбор устройства в ik_llama.cpp?
Фантастическая работа проделана! Даже не могу выразить под каким впечатлением нахожусь.
Как такое можно использовать на практике, если сам обычно за ноутом, а GPU подключены к серверу?
В основном интересует Roocode. Наверное, Copilot можно на "удаленную локальную" модель натравить..
Есть ли обертка а-ля OpenAI, позволяющая так гибко управлять выгрузкой на разные GPU и прочим? Даже обычные модели с увеличенным контекстом были бы интересны.
./llama-server - запускает сервер, есть OpenAI-совместимое API (http://127.0.0.1:8080/v1), можно защитить токеном (задается через --api-key) или через SSH-подключение запросы гонять.
--host 0.0.0.0 можно дополнительно задать, чтобы был порт доступен извне (по умолчанию - 127.0.0.1).
В целом, практически весь софт умеет OpenAI-совместимое API предоставлять, с которым Roo Code работает.
Без GUI (а-ля LM Studio / Ollama) я проживу. Если llama-server позволяет кучу параметров задать (как в статье, кого куда загружать) и обращаться к нему через OpenAI совместимое API - это прекрасно.
Но если этот llama-server надо ручками сопрягать с используемым в статье ik_llama.cpp, это мне, скорее всего, уже сложновато будет.
Поиграюсь. Спасибо!
За статью респект, очень интересно. Вот только не понял уверенности, что китайцы не использовали для обучения своих моделей разного рода Флибусты и русские (и не только) книги им прекрасно известны, может и не наизусть. У них там с авторским правом как-то "попроще" отношения, есть ощущение, что и модели во многом из-за этого получаются сильные.
Отличная статья, но внезапнее всего было упоминание Лабиринта отражений. Не так часто вспоминаю об этой книге, а зря.
предпологаю есть ещё вариант, есть raid ssd через pci вроде как до 24шт на одной плате видел, говорят скорости близкие к ram
PCIe 5.0 x16 обеспечивает теоретическую пропускную способность в 64 ГБ/с, что в лучшем случае соответствует скорости двухканальной памяти.
Для больших моделей этого слишком мало.
Да и стоимость такого решения вызывает сомнения - подозреваю, что проще взять б/у сервер на AMD EPYC.
а если 2 таких и будет уже лучше скорость, при этом объём можно любой будет использовать
Ага. Только 32 линии PCIe не у каждого процессора есть (актуальные потребительские процессоры по 24 линии имеют).
Так что старый AMD EPYC, с его 8 каналами DDR4 все равно впереди. А у современных AMD EPYC 12 каналов DDR5, что еще примерно в 2-3 раза быстрее получается.
А уж если добавить двухпроцессорные материнки, где по 8/12 каналов паяти на каждый процессор...
Ну а объем... Сколько там его надо? Самая большая модель сейчас - Deepseek-R1 весит 700GB с чем-то (неквантованная), что с лихвой перекрывается подобными монстрами.
Хотя llama 4 Behemoth может выйдет - она да, весить побольше будет ) Но там скорость работы на CPU уже совсем печальной будет, не смотря на все 24 канала памяти...
а что насчёт этих результатов?
Скрытый текст
Поискал - использовали 3 карты PCIe 5.0 x16 и Ryzen Threadripper PRO 7985WX (с 128 каналами PCIe 5.0). И да, там 8 каналов DDR5, что обеспечивает примерно в 3 раза большую скорость оперативной памяти относительно показанной.
Матрица RAID 0, представленная на выставке Computex в этом году, включает три карты Apex Storage X16 Gen5 и 32 новых твердотельных накопителя E28 PCie 5.0 NVMe от Phison. Такая конфигурация достигает 113,6 ГБ/с при последовательном чтении и 104,6 ГБ/с при записи, а смешанная скорость достигает 146 ГБ/с.
P.S. интересно, а если все 128 канала PCIe 5.0 забить по максимуму - будет быстрее оперативки?
С AMD Ryzen Al Max+ 395 128gb 8000MHz на что можно рассчитывать?
все вроде как запускают 70b
@rodial Это просто процессор для x86 архитектуры, он не решит ее основную проблему узкой шины для памяти. Он совершенно не подходит для запуска gpt ИИ.
Самое доступное на текущий момент это GPU, причем благодаря некоторым ухищрениям теперь даже не нужно размещать всю модель именно в GPU.
"Он совершенно не подходит" чепуха, вполне себе на нём запускают gpt и имеют не самую худшую производительность, и используют не cpu, а встроенный gpu, который в играх имеет fps на уровне rtx 4060, например 90b занимает почти всю память и имеет скорость 3,5т/с, в более лёгких моделях скорость выше, к тому же пока не используется npu ядра, а их скоро обещают начать использовать в том же lm studio
Купил себе Intel Xeon 3425 (12 cores / 24 threads), есть AMX.
Память 8 каналов * 64GB DDR5-4800. Но почему то скорость памяти тормозит, BIOS пишет, что у меня Memory Channel Mode: Mixed. Из-за этого скорость около половины от того, что должно быть. Разбираюсь...
Запустил build от 2025-July-04.
Модель ubergarm/DeepSeek-R1-0528-GGUF, квант IQ2_K_R4 - это 220GB
Если запускаю с RTX 3090 24GB VRAM, получаю:
PP 131 t/s
TG 7.5 t/s
Если запускаю с RTX 4090D 48GB VRAM, получаю:
PP 164 t/s
TG 8.5 t/s
Надеюсь, если получится настроить RAM, то получится разогнать TG раза в два.
CUDA_VISIBLE_DEVICES=0 ./build/bin/llama-sweep-bench \
--model ./IQ2_K_R4/DeepSeek-R1-0528-IQ2_K_R4-00001-of-00005.gguf \
--ctx-size 32768 \
-ctk q8_0 -fa -mla 3 \
-amb 256 \
-ser 6,1 \
-fmoe \
-b 4096 -ub 4096 \
--temp 0.6 --top-p 0.95 \
--n-gpu-layers 999 \
--override-tensor "blk\.(3|4|5|6|7|8|9|10)\.ffn_.*=CUDA0" \
--override-tensor exps=CPU \
--parallel 1 \
--threads 12
Если запускаю сразу на двух карточках - то скорость получается на 5-6% быстрее чем на одной RTX 4090D, то есть смысла гонять на обоих карточках нет.
а если запустить сразу два процесса, одному отдать первую видеокарту, другому вторую? не уверен именно про deepseek как он может работать на 128гб ram для меня загадка, но так как используется mmap, т.е. файл мапится на память а значит кешируется сразу для всех процессов, возможно это позволит буквально удвоить производительность.
Надеюсь, если получится настроить RAM, то получится разогнать TG раза в два.
Если не сложно, выложите замер скорости в aida64, чтобы примерно ориентироваться.
Если запускаю сразу на двух карточках - то скорость получается на 5-6% быстрее чем на одной RTX 4090D, то есть смысла гонять на обоих карточках нет.
--override-tensor "blk.(3|4|5|6|7|8|9|10).ffn_.*=CUDA0"
Если переносить на GPU кванты R4 (большинство ffn как раз такие), которые предназначены только для работы на CPU, то ускорения не будет, это работает просто как быстрая RAM, если обычной не хватает. Квантованные в R4 тензоры нужно перепаковать на лету, поэтому попробуйте компилировать с -DGGML_CUDA_IQK_FORCE_BF16=1.
Ещё при multi-GPU рекомендуют убирать параметр -ts и работать только с -ot, чтобы сэкономить память.
Intel Xeon 3425 (12 cores / 24 threads), есть AMX.
В ik_llama сейчас нет поддержки AMX.
Есть в llama.cpp, поэтому стоит попробовать UD-...-XL кванты и скомпилировать с флагами:
-DGGML_NATIVE=OFF -DGGML_AVX512=ON -DGGML_AVX512_BF16=ON -DGGML_AVX512_VBMI=ON -DGGML_AVX512_VNNI=ON -DGGML_AMX_TILE=ON -DGGML_AMX_INT8=ON -DGGML_AMX_BF16=ON
Но в первую очередь для AMX стоит попробовать https://github.com/kvcache-ai/ktransformers
Они сосредоточены на оптимизации AMX, не знаю, что у них со скоростью памяти, но когда-то их цифры tg были выше, чем у остальных. Не знаю как сейчас после внедрения AMX и -ot в llama.cpp.
Боже, как все сложно, сколько нюансов...
IMHO такие посты и комменты надо прицельно скармливать ИИ, чтобы получить набор флагов под свое железо. Простому смертному, не специализирующемуся на всем этом, без шансов...
Боже, как все сложно, сколько нюансов...
Было бы ещё понятно, ради чего эти нюансы. Хорошо если процентов 20% удастся получить прироста, а с другой стороны за счет чего? Скорость памяти же осталась той же, так что может и 20% не будет.
Даже про AVX-512 мало информации, при том, что AVX-512 есть на десктопных Ryzen 9000 процессорах, но найти информацию про разницу AVX2 и AVX512 на одном проце по прежнему нереально.
А если будет, ну было 8 t/s, станет 9.6 t/s, на практике это не та разница которая переворачивает всё, если вы про эти нюансы не знали.
-DGGML_CUDA_IQK_FORCE_BF16=1 в моём случае дает прирост 4.5%, вроде не плохо, но в цифрах это всего лишь с 8.6 t/s до 8.99 t/s. Скорее температура за окном сильнее повлияет на результат, чем этот нюанс.
## 1. ktransformers посмотрел, но как-то уже слишком муторно его запускать... Сложно как-то.
## 2. DGGML_CUDA_IQK_FORCE_BF16=1
Я изначально компилировал с этим параметром
## 3. У меня всё на Ubuntu, так что aida64 я запустить не могу - оно только для Windows.
Теоретически, скорость памяти у меня должна быть 307GB/s.
Запускаю mlc:
./mlc
Intel(R) Memory Latency Checker - v3.11a
ALL Reads : 124753.4
3:1 Reads-Writes : 162175.4
2:1 Reads-Writes : 168777.0
1:1 Reads-Writes : 187221.9
Stream-triad like: 149692.6
## 4. Сейчас попробую llama.cpp. Её надо компилировать? Или можно запустить через Docker?
ktransformers посмотрел, но как-то уже слишком муторно его запускать... Сложно как-то.
Запустить просто ktransformers тот ещё квест, при том, что они не любой квант поддерживают в принципе.
Так что да, скорее всего нет смысла пытаться запустить, их секрет ускорения был в -ot флаге и реализации MLA, что сейчас есть везде, и если в llama.cpp поддержка AMX работает, то там уже не должно быть заметной разницы в скорости.
У меня всё на Ubuntu, так что aida64 я запустить не могу - оно только для Windows.
В целом mlc достаточно, у меня цифры в mlc ниже, чем в аиде, но в пределах 10%.
Но если есть интерес, то можно запускать через PortProton, aida64 запускается по двойному клику в виндой, бенчмарк скоростей работает и совпадает с виндовым запуском.
Сейчас попробую llama.cpp. Её надо компилировать? Или можно запустить через Docker?
Раньше у них были отдельные билды для avx2 и avx512, сейчас единый билд, только не понятно, всё теперь объединено или нет.
Может и не нужно компилировать и всё уже добавлено, но проверить это можно только при запуске, посмотрев какие флаги включены.
Запустить эту же самую модель на llama.cpp я не могу, так как она несовместима.
Запустил другую: недавно вышла интересная модель: https://huggingface.co/unsloth/DeepSeek-TNG-R1T2-Chimera-GGUF
Я запустил квант UD-IQ2_M (213 GB) - это приблизительно такой же размер, как и в моём сообщении выше. Запускал llama.cpp с параметрами:
--model ./models--unsloth--DeepSeek-TNG-R1T2-Chimera-GGUF/UD-IQ2_M
--ctx-size 32768
--cache-type-k q8_0
--cache-type-v q8_0
--flash-attn
--threads 12
--host 0.0.0.0 --port 37000
--temp 0.6 --top-p 0.95
--n-gpu-layers 999
--override-tensor "blk\.(3|4|5|6|7|8|9|10|11)\.ffn_.*=CUDA0"
--override-tensor "blk\.(12|13|14|15|16)\.ffn_.*=CUDA1"
--override-tensor exps=CPU
лог:
ggml_cuda_init: GGML_CUDA_FORCE_MMQ: no
ggml_cuda_init: GGML_CUDA_FORCE_CUBLAS: no
ggml_cuda_init:
found 2 CUDA devices:
Device 0: NVIDIA GeForce RTX 4090 D, compute capability 8.9, VMM: yes
Device 1: NVIDIA GeForce RTX 3090, compute capability 8.6, VMM: yes load_backend: loaded CUDA backend from /app/libggml-cuda.so
load_backend: loaded CPU backend from /app/libggml-cpu-sapphirerapids.so
build: 5830 (bac8bed2) with cc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 for x86_64-linux-gnu
system_info: n_threads = 12 (n_threads_batch = 12) / 12
| CUDA : ARCHS = 500,610,700,750,800,860,890
| USE_GRAPHS = 1
| PEER_MAX_BATCH_SIZE = 128
| CPU : SSE3 = 1
| SSSE3 = 1
| AVX = 1
| AVX2 = 1
| F16C = 1
| FMA = 1
| BMI2 = 1
| AVX512 = 1
| AVX512_VBMI = 1
| AVX512_VNNI = 1
| AVX512_BF16 = 1
| AMX_INT8 = 1
| LLAMAFILE = 1
| OPENMP = 1
| REPACK = 1
Получил скорость на 2 GPU:prompt eval time = 53671.03 ms / 1268 tokens ( 42.33 ms per token, 23.63 tokens per second)
eval time = 389557.42 ms / 1731 tokens ( 225.05 ms per token, 4.44 tokens per second)
На одном RTX 4090D 48GB:prompt eval time = 58561.21 ms / 1273 tokens ( 46.00 ms per token, 21.74 tokens per second)
eval time = 371584.74 ms / 1566 tokens ( 237.28 ms per token, 4.21 tokens per second)
Запустил эту же модель на ik_llama.cpp на одной RTX 4090D:
prompt eval time = 21474.45 ms / 1265 tokens ( 16.98 ms per token, 58.91 tokens per second)
generation eval time = 396856.15 ms / 1690 runs ( 234.83 ms per token, 4.26 tokens per second)
Вывод:
Для обычных моделей llama.cpp и ik_llama.cpp приблизительно одинаковы по скорости генерации токенов. По обработке промпта llama.cpp в 2.7 раза быстрее, - думаю что это из-за AMX.
ik_llama.cpp работает в 2-3 раза быстрее только с оптимизированными моделями (_R4):
PP: 164 t/s vs 58 t/s
TG: 8.5 t/s vs 4.2 t/s
Интересно, если в ik_llama.cpp завезут AMX, - она вообще уйдёт в отрыв по скорости обработки промпта?
Отправил инфо про это разрабам тоже: https://github.com/ikawrakow/ik_llama.cpp/issues/437#issuecomment-3040885214
Сегодня вышла новая 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к как раз влезает целиком:
В общем могу подтвердить, пока это самый точный пересказ книги, оценена была именно книга целиком. Модель легко разделяет двух Вик, и с другими конкретными вопросами модель тоже справляется успешно.
по ссылке пишут
Some of ik's new quants are supported with Nexesenex/croco.cpp fork of KoboldCPP.
These quants provide best in class perplexity for the given memory footprint.
и судя по всему 128гб ram должно в притык хватить (я верно понимаю, что часть, выгруженная в vram в ram уже не используется?) если учитывать видеокарту, при этом на весь объем контекста!?
и судя по всему 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) для той, где будет контекст, а оставшиеся слои выгрузить на вторую, но тут надо экспериментировать.
Я нашел картинку этого бенчмарка но где взять сам бенчмарк что бы покрутить его самому
Автор пишет, что это закрытый бенчмарк, только несколько примеров показывает. В целом можно понять, что из себя этот бенчмарк представляет:
https://www.reddit.com/r/LocalLLaMA/comments/1jbgezr/comment/mhu4nxo/?context=3
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? Что произошло дальше?
Сам ответ правильный, это при том, что в контекст загружена вся книга целиком, а не как в случае Gemma только 32к контекста, но последний момент с уходом в Лабиринт Смерти - технически правильно, но тут как будто бы это не к месту упомянуто, так как перед походом было много других событий.
Можно попробовать дать куда более сложное задание, пройти по всей книге и обобщить факты из разных эпизодов, из начала, середины и конца книги. Это частая проблема для многих моделей на SWA, так как скользящее окно контекста обычно всего 4к.
Ответь на 3 вопроса по книге:
Какие по ходу книги были ники у гг
Кто такая Вика, почему их две
Сколько раз гг встречался с Маньяком, а сколько раз с Человеком без Лица
Для такой маленькой модели ответы вполне хороши. Ошибка и путаница про встречи с Маньяком, часть правильно, часть спутана, части не хватает, но это как раз и есть самая сложная часть собрать по книге все встречи.
После провала 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
Не подскажешь, как лучше всего подключить Qwen3-coder-flash к Qwen3 Code CLI для агентских дел? Я пробовал через LMStudio, но qwen крешится при попытке доступа к файловой системе.
Большое спасибо за наводку. Действительно qwen/qwen3-coder-30b запущенная через LM Studio вполне прилично сработала.
И, если позволите, я накидаю пару вопросов в надежде на последующие статьи :)
1) Квантизация.
Что нижняя (qwen3-coder-30b размером аж 25GB хороша, я не сильно удивился. А что с остальными двумя?
Между ними разница на треть по размеру дискового пространства, но и алгоритмы сильно разные. Качество тоже разнится? Или "экономия диска" (и более быстрая загрузка?), а потребление VRAM одинаковое в итоге? Или действительно IQ2_M так хорош, что при экономии всего (и диска, и VRAM) даст сравнимое качество с Q3_K_L?
Или вот IQ1M и IQ2_XXS - по размеру на диске разница не принципиальная. В 8GB VRAM ни одна не влезел, а в 12 любая (наверное). При этом IQ2, наверное, сильно лучше IQ1?
2) Speculative decoding (в RooCode для LM Studio есть такая галочка - хоть это и не в рамках подхода из данного поста)
Draft Generation: A smaller, faster “draft” model predicts several tokens ahead, akin to quickly sketching a rough outline.
Verification: A larger, more accurate “target” model then verifies those draft tokens. Tokens matching the target model’s expectations are accepted, and any discrepancies are regenerated.
По табличкам получается, что качество как у большой модели (ибо она верифицирует), а скорость чуть ли не на треть выше, ибо значительную часть работы выполняет быстрая модель.
Ну и получается, что помимо большой модели (которую хочется максимальную по локальным ресурсам запустить) надо еще и мелкую стартовать? (в таком не вижу большого смысла, лоакльные ресурсы и так ограничены).
Или они независимы и можно draft запустить через API где-то за копейки (модель легкая и супербыстрая), а финал локально доделать (не слишком долго, ибо только верификация)?
Или наоборот - легкая локальная модель быстро основное подготовит, а через API мощная модель только "полирнет" ответ (безо всяких "дай-те как я проверю такие строчки в таком-то файле... ой, не попало, покажите мне побольше...)...
Вообще не понимаю, как это работает...
Квантизация.
Я не знаю на сколько из далека вам нужна теория, поэтому с самого начала, если что просто переходите на следующий пункт.
Про квантизацию
Веса модели это массив млрд цифр типа 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, оно чуть получше, но эти типы работали плохо и качество сильно падало.
Потом пришел 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 одинаковое в итоге? Или действительно 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к контекста.
Ускорение в 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% верная, нужно перепроверять и тестировать.
Или они независимы и можно 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, поэтому ускорение слабое, но всё равно есть:
На сколько может расходиться качество результата с использованием Speculative decoding? вероятность вероятностями, но речь же не идет об одном токене, а сразу о нескольких, и их количество наверное фиксированное или при сравнении выбираются первые правильные? (по гуглил вроде пишут не падает).
p.s. ваши комментарии круче и информативнее 99% постов на хабре, спасибо
но речь же не идет об одном токене, а сразу о нескольких, и их количество наверное фиксированное
Если речь про черновую последовательность, то её размер не фиксированный, есть максимальное и минимальное значение (от 0 до 16 по-умолчанию), генерация черновика прерывается как только токены перестают попадать в greedy семплинг значения --draft-p-min, по умолчанию 0.8.
Большая модель могла бы легко генерировать и 2, и 3, и 4 токена за раз, но чтобы сгенерировать токен в позиции n+1, нужно знать токен в позиции n, а у нас доступен только токен в позиции n-1. Поэтому модель вынуждена генерировать всё последовательно, шаг за шагом, хотя может параллельно высчитать сразу несколько токенов за тоже время.
Как-то делал демонстрацию на тему, что в llama.cpp есть параметр --parallel N, и можно почти без потерь, если хватает вычислительных ресурсов, генерировать даже 8 параллельных запросов:
Спекулятивное декодирование работает так:
Черновая модель на основе текущей последовательности генерирует продолжение, допустим последовательность из 8 новых токенов.
Большая модель получает эти 8 токенов и создает 8 гипотетических последовательностей, каждая на 1 токен больше. "Стартовая + n", "Стартовая + n + n+1" и т.д.
Большая модель запускает параллельные вычисления для этих 8 вариантов будущего, она параллельно высчитывает 8 новых токенов и если они совпадут с черновой, то те будут приняты.
Получаем 8 вариантов logits и начиная с 1 токена сравниваем вероятности большой модели и черновика, первое не соответствие и остальные отбрасываются, а начальные принимаются.
Так за счет параллельных вычислений мы получили больше новых токенов за плюс-минус время вычисления 1 токена и накладных расходов. Так что снижение --draft (синоним -draft-max) до 4 - это не только повышает шанс принятия нового токена, но и снижает количество параллельных вычислений, что на больших MoE-моделях, которые вычисляются на CPU, где ядер мало, дает дополнительный смысл.
Если нужны детали, можно почитать их тут: https://arxiv.org/abs/2302.01318
На сколько может расходиться качество результата с использованием Speculative decoding?
Допустим, стартовая последовательность: Кот
Черновая предлагает: любит есть колбасу и спать
Для большой модели создается 5 последовательностей, которые считаются одновременно:
За 1 шаг готовы все 5 вариантов, но если большая считает, что "кот любит есть рыбу", то вместо +5 принятых черновых будет +2 и +1 токен от большой модели, итого +3 токена вместо +1.
P("любит" | "Кот") - это вычисление вероятности, то есть это не 1 в 1 совпадение токена черновой и большой, а вероятность с которой большая модель согласна с тем, что тут может быть такой токен.
Поэтому, черновая модель может увести большую не туда, то есть её качество тоже играет роль, но на сколько расходится качество - нет точного ответа.
(по гуглил вроде пишут не падает).
Есть шанс заруинить. Допустим взяли черновую очень маленькую 0.6B, поэтому она качественно не очень хороша для большой модели, но в среднем работает. И тут может быть такая ситуация:
Модель: Qwen3-235B-A22B-Instruct-2507-UD-Q4_K_XL + Qwen3-0.6B-Q8_0
Температура: 0.01, top_k: 20, top_p: 0.95, min_p: 0.05
Запрос: Напиши эффект матрицы из эмодзи в одном index.html
Выставил температуру минимально, результаты должны быть максимально близки.
Без черновика: 6 прогонов, каждый раз результат правильный.
--draft 4: 6 прогонов, результат правильный.
--draft 10: 6 прогонов, результат правильный 50 на 50.
--draft 16: 10 прогонов, каждый раз результат не корректный.
Поэтому предсказывать значение по умолчанию в 16 токенов качественно не выгодно.
Модуль спекулятивного декодирования MTP, который из DeepSeek, а теперь ещё и из GLM 4.5, обучается вместе с основной моделью, поэтому такой вариант должен работать лучше, но поддержки MTP в llama.cpp пока нет. В отчете про DeepSeek (раздел 5.4.3. Multi-Token Prediction Evaluation) описывают, что в MTP предсказывают только 2 следующих токена, видимо как раз из-за лучшего качества результата.
По поводу понижения качества генерации... чисто поразмышлять, если основная модель только как проверочная, значит варианты генерации, основанные на более глубоком понимании задачи тупо ей будут не доступны, либо вероятность такого ответа значительно понизится... в принципе -parallel должна эту вероятность поднять... но все равно я удивлен что это работает.
чисто поразмышлять, если основная модель только как проверочная, значит варианты генерации, основанные на более глубоком понимании задачи тупо ей будут не доступны, либо вероятность такого ответа значительно понизится
Не, никаких отличий от использования просто основной модели и модели с черновиком в плане глубокого понимания или вероятностей нет. Основная просто отвергнет все токены и сгенерирует ответ сама.
Просто задача с эмодзи сложная, и если основная модель плавает в решение, то черновая может повести её по пути, где решение не рабочее, но просто потому, что такая ветка могла бы возникнуть и при генерации основной моделью самой по себе.
Вот тот же запрос прям у оригинальной Qwen3-235B-A22B-2507 на их сайте. С первой же попытки модель не справилась:
То, что задача не простая, вот, например, что сгенерировал Gemini 2.5 Pro, эмодзи пропали, потому что вместо массива, он сделал строку и не правильно её нарезал:
Вот именно тот факт что при плохой draft модели получается фигня и показывает что результат ухудшается но в самом сложном для отлова варианте.
Драфт модель может предложить токен, близкий по вероятности к верному, но не лучший. Полагаю speculative decoding начинает плохо работать с большими значениями температуры.
Вот именно тот факт что при плохой draft модели получается фигня и показывает что результат ухудшается но в самом сложном для отлова варианте.
Драфт модель может предложить токен, близкий по вероятности к верному, но не лучший.
Это на столько редкие и не критичные события, что их в 99% случаях даже нет смысла учитывать. Если она сгенерирует не правильный вариант - это тоже самое, что оригинал сгенерировал выше не правильный вариант.
То, что выбор черновой модели важная часть, это да. Для той же 235B лучше взять 4B вместо 0.6B, скорость и процент принятия будет куда лучше.
Модели в целом не идеальны, особенно квантованные, они на пустом месте могут выдать рандомный ответ, и небольшие редкие искажения черновика не сильно повлияют на итоговый результат. Ускорение оправдано, 4 t/s или 7 t/s это ощутимая разница.
Тот сценарий я создал зная слабость модели, это просто, чтобы показать, что спекулятивное декодирование не 1 в 1 работает, и это можно учитывать, например, выбирая черновую модель получше, но критичного тут ничего нет.
Достаточно вернуть температуру на 0.6, и даже с 16 токенами на черновой 0.6B модель генерирует правильный ответ 4 из 6 раз. Ускорение тоже продолжает работать.
Полагаю speculative decoding начинает плохо работать с большими значениями температуры.
Температура не играет роли. Первичная идея спекулятивного декодирования это завершать очевидные варианты, а не подменить собой основную модель.
Есть такая последовательность "И вот таким образом сп", черновая модель предложить ['сп', 'ек', 'у', 'ля', 'тив', 'ное', ' дек', 'од', 'ирование', ' это', ' большое', ' я', 'бл', 'око'], основная модель примет только 9 токенов, остальные отбросит, а что-то вроде <meta name="viewport" content="width=device-width, initial-scale=1.0"/> вообще сразу принимается целиком.
Тут нет сценария, что основная модель только проверяет, потому что основная модель отвергает почти 50% токенов, и оставляет только очевидные продолжения, это не влияет на её глубину понимания вопроса.
Прямо чувствую продолжение развитие идеи такой генерации дальше. Кто сказал что драфт модель должна быть моделью gpt, куча задач может быть решена другими алгоритмами, по проще. Собственно один из примеров - это способность модели управлять внешними утилитами... но это модель должна уметь. Т.е. можно специально обучить модель выбирать внешнюю утилиту по контексту, которая будет заполнять основной контекст... пример - при написании кода в классических IDE популярны средства intellisence/code completion, можно в соседнюю модель подавать вывод вариантов от этих алгоритмов (типа список доступных методов, список идентификаторов проекта в области видимости, и т.п.),
В самую точку!
Какое счастье, что в закладки можно добавлять не только статьи но и такие вот комментарии! Хотя и в заметки экспортировать - тоже мастхэв.
Запускаем настоящую DeepSeek R1 671B на игровом ПК и смотрим вменяемая ли она на огромном контексте (160к)