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