Размер модели 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 присутствует, и поддержка должна появиться довольно быстро.
И самое главное, это не мыслящая модель, значит не будет тысячами бесполезных токенов размышления, при этом качество по бенчмаркам конкурентоспособное:
Было бы ещё понятно, ради чего эти нюансы. Хорошо если процентов 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. Скорее температура за окном сильнее повлияет на результат, чем этот нюанс.
ktransformers посмотрел, но как-то уже слишком муторно его запускать... Сложно как-то.
Запустить просто ktransformers тот ещё квест, при том, что они не любой квант поддерживают в принципе.
Так что да, скорее всего нет смысла пытаться запустить, их секрет ускорения был в -ot флаге и реализации MLA, что сейчас есть везде, и если в llama.cpp поддержка AMX работает, то там уже не должно быть заметной разницы в скорости.
У меня всё на Ubuntu, так что aida64 я запустить не могу - оно только для Windows.
В целом mlc достаточно, у меня цифры в mlc ниже, чем в аиде, но в пределах 10%. Но если есть интерес, то можно запускать через PortProton, aida64 запускается по двойному клику в виндой, бенчмарк скоростей работает и совпадает с виндовым запуском.
Сейчас попробую llama.cpp. Её надо компилировать? Или можно запустить через Docker?
Раньше у них были отдельные билды для avx2 и avx512, сейчас единый билд, только не понятно, всё теперь объединено или нет. Может и не нужно компилировать и всё уже добавлено, но проверить это можно только при запуске, посмотрев какие флаги включены.
Надеюсь, если получится настроить 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.
Есть в 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.
Никто не пробовал связку 2x4060Ti (или подобных недорогих 16Gb видеокарт).
Всё работает отлично, разве что вместо 4060ti сейчас актуальнее 5060ti, там память в 1.5 раза быстрее, что очень важно для инференса, а стоит столько же.
Благодаря llama.cpp, она сама и любой софт основанный на ней, позволяют запускать модели на любых GPU (amd, nvidia, intel) в любом количестве, все видеокарты подхватятся автоматически и модель размажется по ним, и можно управлять пропорциями.
В LM Studion можно управлять приоритетом и отключать ненужные
Если использовать vulkan версию llama.cpp (можно выбрать в Runtime), то можно объединять amd + nvidia + intel.
В таком режиме "толстые" модели могут использовать видеопамять обеих карт?
Для 32B всё будет работать отлично, так как памяти уже будет с запасом, но "толстые" это скорее про 70B модели. И тут есть 2 вида толстых моделей:
Dense, то есть сплошные, это Qwen3 72B или Llama3.3 70B - для запуска таких моделей в Q4_K_M кванте нужно 44гб. Выходом для двух карт по 16гб - это использовать квантование от Unsloth с их Unsloth Dynamic 2.0 GGUFs квантованием, они важные тензоры оставляют в высоком качества, а менее важные квантуют сильнее. 70B UD-Q2_K_XL как раз весит 27гб и останется место под контекст, а уже 72B UD-Q2_K_XL немного впритык, занимает 30.3гб, и если нужна память под систему и контекст, то уже придётся ужиматься.
MoE модели, у них только часть параметров активна, это Llama 4 Maverick/Scout, Qwen3-235b-a22b, DeepSeek R1. Для их запуска хватит 1 gpu, лламу 4 можно и на 8гб запускать. Это делается сейчас по другому, не просто запуском на GPU, а трюком с override-tensor параметром, если хватает обычной памяти.
Вот тут я запускаю на домашнем ПК настоящую толстую DeepSeek R1 671B на огромном контексте, там же вся теория почему и как это работает: https://habr.com/ru/articles/921540/
Правильно ли я понял, что 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.
Ну доля Linux в стиме и правда почти на пол процента выросла, а у Windows как раз упала сильнее, чем выросла Win11. Кто знает, кто знает, может пол процента это и есть те не достающие 400 млн.
На ум приходит аналогия с совместным использованием библиотек процессами (одна либа в памяти, и разные процессы ее юзают).
Есть параметр --parallel N, где N количество параллельных запросы к одной и той же модели. Памяти расходуется столько же, так как на N слотов будет общий размер контекста, но чтобы это нормально работало, должно хватать вычислительных мощностей, чтобы справиться с параллельной работой.
1 запрос, скорость 41 t/s:
4 одновременных запроса, скорость одного слота упала до 28 t/s, но суммарно 112 t/s:
Сделал это на онлайн-версии, получил сообщение, что загрузилось 85% текста, никакой контекст шифт не включился, я так понял, она просто обрезала текст.
context shift это в ik_llama/llama.cpp, это их придумка, которая скорее мешает, чем помогает если про неё не знать, в нативной версии трансформера такого нет.
а это как сделать?
Из txt файла удалять куски текста с конца и смотреть через llama-tokenize результат, когда будет 100к, значит достаточно.
Есть ли разница и повышение хэшрейта аж на 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 не вырастет в размерах, то этого хватит, если разжиреет, то да, снова эпики и зеоны будут единственным вариантом.
Размер модели 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 присутствует, и поддержка должна появиться довольно быстро.
И самое главное, это не мыслящая модель, значит не будет тысячами бесполезных токенов размышления, при этом качество по бенчмаркам конкурентоспособное:
Было бы ещё понятно, ради чего эти нюансы. Хорошо если процентов 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. Скорее температура за окном сильнее повлияет на результат, чем этот нюанс.Запустить просто ktransformers тот ещё квест, при том, что они не любой квант поддерживают в принципе.
Так что да, скорее всего нет смысла пытаться запустить, их секрет ускорения был в -ot флаге и реализации MLA, что сейчас есть везде, и если в llama.cpp поддержка AMX работает, то там уже не должно быть заметной разницы в скорости.
В целом mlc достаточно, у меня цифры в mlc ниже, чем в аиде, но в пределах 10%.
Но если есть интерес, то можно запускать через PortProton, aida64 запускается по двойному клику в виндой, бенчмарк скоростей работает и совпадает с виндовым запуском.
Раньше у них были отдельные билды для avx2 и avx512, сейчас единый билд, только не понятно, всё теперь объединено или нет.
Может и не нужно компилировать и всё уже добавлено, но проверить это можно только при запуске, посмотрев какие флаги включены.
Если не сложно, выложите замер скорости в aida64, чтобы примерно ориентироваться.
Если переносить на GPU кванты R4 (большинство ffn как раз такие), которые предназначены только для работы на CPU, то ускорения не будет, это работает просто как быстрая RAM, если обычной не хватает. Квантованные в R4 тензоры нужно перепаковать на лету, поэтому попробуйте компилировать с
-DGGML_CUDA_IQK_FORCE_BF16=1.Ещё при multi-GPU рекомендуют убирать параметр -ts и работать только с -ot, чтобы сэкономить память.
В 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.
Всё работает отлично, разве что вместо 4060ti сейчас актуальнее 5060ti, там память в 1.5 раза быстрее, что очень важно для инференса, а стоит столько же.
Благодаря llama.cpp, она сама и любой софт основанный на ней, позволяют запускать модели на любых GPU (amd, nvidia, intel) в любом количестве, все видеокарты подхватятся автоматически и модель размажется по ним, и можно управлять пропорциями.
Если использовать vulkan версию llama.cpp (можно выбрать в Runtime), то можно объединять amd + nvidia + intel.
Для 32B всё будет работать отлично, так как памяти уже будет с запасом, но "толстые" это скорее про 70B модели. И тут есть 2 вида толстых моделей:
Dense, то есть сплошные, это Qwen3 72B или Llama3.3 70B - для запуска таких моделей в Q4_K_M кванте нужно 44гб. Выходом для двух карт по 16гб - это использовать квантование от Unsloth с их Unsloth Dynamic 2.0 GGUFs квантованием, они важные тензоры оставляют в высоком качества, а менее важные квантуют сильнее. 70B UD-Q2_K_XL как раз весит 27гб и останется место под контекст, а уже 72B UD-Q2_K_XL немного впритык, занимает 30.3гб, и если нужна память под систему и контекст, то уже придётся ужиматься.
MoE модели, у них только часть параметров активна, это Llama 4 Maverick/Scout, Qwen3-235b-a22b, DeepSeek R1. Для их запуска хватит 1 gpu, лламу 4 можно и на 8гб запускать. Это делается сейчас по другому, не просто запуском на GPU, а трюком с override-tensor параметром, если хватает обычной памяти.
Вот тут я запускаю на домашнем ПК настоящую толстую DeepSeek R1 671B на огромном контексте, там же вся теория почему и как это работает: https://habr.com/ru/articles/921540/
На данный момент да, пока не было замечено других моделей на MLA.
Есть такой проект TransMLA через который можно мигрировать через пост-обучение с GQA на MLA. По их замерам преобразованная модель лучше себя показывает чем исходная:
Если сравнивать с моделями на GQA (Group Query Attention), это примерно все открытые модели на момент выхода R1, то да. Если сравнивать с закрытыми моделями, то там по разному, есть явные лидеры, вроде Gemini 2.5 pro, которые обгоняют всех, а есть такие с кем R1 сравнима или лучше их.
Ещё бывают и другие эксперименты с вниманием, вот, например, недавно вышла открытая модель Minimax M1, они используют гибридный Lightning Attention, как раз только что вышла статья разбора архитектуры (https://habr.com/ru/articles/923588/), она ещё дешевле в обучение, ей нужно меньше вычислений чем R1 и у неё контекст 1м, но нет такой эффективной экономии памяти как у MLA.
В общем тут нет какого-то однозначного ответа:
Для тех, кому тоже интересен ответ, протестировал этот квант на 160к контексте:
https://habr.com/ru/articles/921540/
При 1 запрос: cpu 11%, gpu 95%
При 4 запросах: cpu 16%, gpu 86%
Это возможно проблема или особенность llama.cpp, сейчас там общий kv-кэш, параллельный вариант пока не реализован: https://github.com/ggml-org/llama.cpp/issues/10860
Бенчмарк Qwen3 32B Q4_K_M на 4060ti 16gb, влезло 48 слоев из 65:
Ну доля Linux в стиме и правда почти на пол процента выросла, а у Windows как раз упала сильнее, чем выросла Win11. Кто знает, кто знает, может пол процента это и есть те не достающие 400 млн.
Есть параметр
--parallel N, где N количество параллельных запросы к одной и той же модели. Памяти расходуется столько же, так как на N слотов будет общий размер контекста, но чтобы это нормально работало, должно хватать вычислительных мощностей, чтобы справиться с параллельной работой.1 запрос, скорость 41 t/s:
4 одновременных запроса, скорость одного слота упала до 28 t/s, но суммарно 112 t/s:
context shift это в ik_llama/llama.cpp, это их придумка, которая скорее мешает, чем помогает если про неё не знать, в нативной версии трансформера такого нет.
Из txt файла удалять куски текста с конца и смотреть через llama-tokenize результат, когда будет 100к, значит достаточно.
Я тестировал сразу на Linux, мне уже не хотелось собирать ik_llama под Windows, так как под виндой у меня не настроено окружения для сборки, и я на эту статью потратил 5 дней и уже немного устал от всего этого.
У 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 может быть полезно.
V100 на 32гб отлично впишется, говорят на таобао они щас дешевые.
Если устраивает турбинный шум, то лучше китайскую 4090 на 48гб.
Эпики быстрые, много быстрой памяти, но ни нормальную тихую башню не поставить, ни корпус нормальный, ни дорогущую память потом ни куда не деть. Это подходит тем, кто точно знает зачем ему эпики, и зачем ему именно квант Q4 или даже Q8.
Просто принципиально кванты выше чем UD-Q2_K_XL по сути ничего не дают, несколько процентов это не существенно, тут нужен DeepSeek R2 чтобы качество принципиально выросло, гнаться за Q8 квантом не имеет практического смысла.
Сейчас в продаже появляются планки 64гб DDR5, это будет 256гб в домашний комп, туда влезает UD-Q2_K_XL, если DeepSeek R2 не вырастет в размерах, то этого хватит, если разжиреет, то да, снова эпики и зеоны будут единственным вариантом.