Сейчас, по итогу, я ушел с llama.cpp на ik_llama.cpp. Это fork ориентированный на MOE модели и совместную работу CPU-GPU. Путем тонкой настройки (мне надо еще и много контекста) получилось 60+ т/с. Что делал: - включил квантование KV-кэша в режиме q8_0 (q4_0 не рекомендую) - через n-cpu-moe постарался минимум слоев выгружать на CPU - подбирал постепенно, пока влезает в память
Сейчас доставил вторую видеокарту, получил стабильные 75-80 т/с. Казалось бы немного прибавил, но есть момент, который многие не учитывают - время первого токена. На архитектуре cpu-moe у меня это иногда 5 секунд занимало, а сейчас 1 секунда. Очень сказалось на opencode - анализ крупного проекта на C# ускорился раза в 3!!! То есть на диалогах cpu-moe хорошее решение, а вот на потоке сильно проседает.
Сам себя исправляю. С 16 мая mtp в основной ветке. Поигрался с 27b, эффект есть, но с 18 т/с на 27 т/с - все равно грустно. А вот на 35b прирост всего 3 т/с - с 57 на 60, о чем многие пишут. В то же время ik_llama дает 77-80 без всяких mtp.
Исполняю сейчас все на 5060 ti и tesla t10, обе по 16 гб. Слабые, конечно, плюс pcie 3.0 (у 5060 вообще 8х), возможно упираюсь в скорость памяти и взаимный обмен
По факту у меня сейчас форк ik_llama, который не умеет в MTP, крутит Qwen3.6-35B-A3B заметно быстрее, чем ветка llama с поддержкой MTP. В ближайшие дни буду разбираться, но у меня пока эффект от MTP скорее обратный. Даже на плотной модели 27b. Но тут возможно сказывается то, что кручу на двух видеокартах, а не на одной и, возможно, с MTP этим как-то конфликтует - это же пока в экспериментальной ветке.
Сейчас реально круче: ушел на форк ik_llama.cpp, вместо cpu-moe использовал n-cpu-moe - раскидал сколько смог слоев в видеокарту. n-cpu-moe на обычной llama.cpp дал 50 т/с, на ik_llama.cpp получил 60 т/с и заметно уменьшившееся время первого токена. Правда вчера добавил вторую видеокарту и от cpu-moe отказался. Получил 75-80 т/с и почти мгновенный первый токен (на opencode разница в анализе крупного C# проекта аж в 3 (!!!ТРИ) раза)
Я проводил эксперименты для себя. Чисто субъективно оценивая результат. Действительно, в обычных диалогах зачастую экстремально квантованная модель не отличается. Но в практическом применении, например opencode анализирующий проект из нескольких десятков файлов начинаются чудеса, вплоть до зацикливания модели. Однако уже квантование iq4 вполне себе работает и в большинстве примененийявляется разумным кокомпромиссом.
Есть другая похожая/сопутствующая проблема. При попытках ужаться во vram приходится включать квантование kv кэша. И если q8 ещё нормально проходит, то q4 сводит модель на длинных диалогах и задачах с ума. Особенно это касается v кэша, так как ошибка там итерационно накапливается.
Но зря вы откинули nextcloud. На этом железе будет очень прилично работать. У меня еще на древнем Asus eeePC с двухъядерным atom очень даже приемлимо работал, даже редактирование документов через браузер шевелилось (единственное, где было заметно, что процессор хилый). У вас будет если не летать, то вполне себе резво бегать. У меня поднят без докера, но и в докере он есть.
Сейчас e5-2690v4 -16 вт (задач стало сильно больше, включая локальный ии и виртуалки). Можно немного, а иногда ощутимо снизить потребление и ограничить tdp через intel-undervolt
Ну не прям со свистом. Но влезает. Если вам будет полезно субъективное мнение и опыт, то: относительно qwen3.6-35b с включенным cpu-moe по производительности на практике несколько, но не кардинально быстрее, но по качеству работы с кодом очееь заметно хуже. Железо 5060ti 16 gb + xeon e5 2690v4.
Подтверждаю. Плотно тестировал. Практически все что смог скачать с хаггинфейс до 14b. В итоге что-то действительно полезное оказалось только qwen3.6 35b и плотный вариант 27b в экстремальном квантовании. После них разве что на gpt-oss-20b можно смотреть без отвращения
.. а если разобраться с cpu-moe для 35b модели qwen3.6 и квантованием контекста, то на относительно простой видеокарте получается весьма неплохой результат. У меня 36токенов/с, 260000 контекст на xeon 2690v4, 5060 ti 16gb. Я правда за 5 минут не разобрался и сделал это на llama.cpp. Но мне просто лень было копаться, а так по идее не сложно.
Спасибо за подсказку! У меня lm studio через llmster на домашнем сервере (Xeon 2690v4, 64 gb RAM, 5060 ti 16 gb). Попробовал поиграться ключами аналогично вам, не взлетело. Однако как второй вариант у меня стоит сам llama.cpp без оберток. Включил moe на cpu и квантование кэша. В итоге с контекстом 260000 получил около 36 токенов/с
Строка на запуск (вдруг кому-то надо будет, пока на отладке "гажу" в /root): /root/llama.cpp/build/bin/llama-server -m “/root/.lmstudio/models/lmstudio-community/Qwen3.6-35B-A3B-GGUF/Qwen3.6-35B-A3B-Q4_K_M.gguf” --host 0.0.0.0 --port 1234 -c 240000 -ngl 99 -t 16 --cpu-moe --cache-type-k q8_0 --cache-type-v q8_0 -b 1024
А как сервис llama.cpp отконфигурирована так:
[Unit] Description=llama-server for Qwen3.6-35B-A3B-Q4_K_M.gguf After=network.target
Честно говоря когда захотелось тупо попробовать альтернативу ollama/lm studio (все cli) спросил бесплатный deepseek как поднять llama.cpp на домашнем сервере. Получил вполне приличную инструкцию шагов на 5, включая скачивание, которая дала результат сразу. Через openai сразу заработали и home assistant и open webui, поправил только ururl.
А по статье могу подтвердить, что ollama cli тупо раза почти в 2 медленнее что lm studio, что llama.cpp. Ещё и ram жрет при работе иногда непонятно зачем
Аналогично. Что только не пробовал (ограничен 16 гб vram 5060 ti), но наиболее адекватным и производительным оказалась qwen3.5-9b. Жаль, в отличие от более старых версий, нет варианта 14b. Более менее по субъективному ощущению 'интеллекта' сопоставима gpt-oss-20b, но gpt раза в 2-3 медленнее. В то же время старые модели qwen до 3.5 ощущаются какими-то кривыми: то с home assistant не дружат, то зацикливаются в ответах, то имеют кривоватый русский язык.
Читаешь и сначала думаешь, но ведь такое элементарно и обычно и все должны понимать, что всегда есть такой путь. Но оказывается многие и не задумываются о такой возможности и продолжают мучаться через gui. В моих задачах с iar нет необходимости в таком количестве вариантов сборки и все равно я еще лет 15 назад такие возможности изучил, удивив коллег. Так что статья очень полезна и кому-то откроет глаза.
Самое конечно веселое было с ПЛК icp-das. Под них до сих пор ПО пишется на borland c 3.1. Для автоматизации сборки пришлось написать скрипт на python, который запускает dosbox, в нем borland с необходимыми ключами и в итоге получается необходимый exe.
Именно. Путем автора вполне прошел, правда не дойдя до упаковки в корпус:
Для поиграться купил когда-то спонтанно cubieboard 2. Изначально задумывал embedded применение, но не пошло. В отличие от автора у cubieboard сразу было sata и преобразователь питания на плате, так что с ноутбучным винчестером вполне себе это работало сразу. Но очень быстро у меня вырос аппетит, захотелось не только файлопомойку, а ещё и на много дисков, свое облако и тп. В итоге пришлось идти по пути x86 железа. Что-то покупал новое, что-то б/у, за годы было несколько итераций смены платформы. Сейчас в итоге конфигурация такая:
Xeon 1240l-v3 (25 watt tdp)
Asus h97m-e (microatx lga1150)
32 gb ram (хватало для всего и 16, но оказалось ollama память любит)
4 hdd
2 sata ssd
1 nvme ssd
5060 ti 16 gb
Gh
На всем этом крутится свое облако nextcloud, home assistant, git, svn, transmission, samba, локальный ИИ в виде lm studio и ollama. Ну и всякая мелочевка.
Я ни разу автора не критикую. Как поиграться и что-то освоить почему бы и нет. Но очень быстро приходит осознание того, что решение крайне ограничено и надо что-то менять. К примеру свое облако на таком железе будет просто шевелиться, не бегать, а о возможности использовать nextcloud office/Collabora придется только мечтать.
Чисто по личному опыту (неделю вожусь с локальными llm, на личном сервере xeon 1240lv3, 16g ram, 5060 ti 16 gb): - lm studio на linux сервере значительно быстрее чем ollama (начинал с нее), а главное не жрет так память - перепробовал много моделей, пока для общего применения оптимальна openai/gpt-oss-20b - влезла в 12.2 gb VRAM с контекстом 65536 - отлично интегрировалась с open webui (через openai) - при желании ставится вообще без gui - при некоторых танцах с бубном заработала с home assistant
Сейчас, по итогу, я ушел с llama.cpp на ik_llama.cpp. Это fork ориентированный на MOE модели и совместную работу CPU-GPU. Путем тонкой настройки (мне надо еще и много контекста) получилось 60+ т/с. Что делал:
- включил квантование KV-кэша в режиме q8_0 (q4_0 не рекомендую)
- через n-cpu-moe постарался минимум слоев выгружать на CPU - подбирал постепенно, пока влезает в память
Сейчас доставил вторую видеокарту, получил стабильные 75-80 т/с. Казалось бы немного прибавил, но есть момент, который многие не учитывают - время первого токена. На архитектуре cpu-moe у меня это иногда 5 секунд занимало, а сейчас 1 секунда. Очень сказалось на opencode - анализ крупного проекта на C# ускорился раза в 3!!! То есть на диалогах cpu-moe хорошее решение, а вот на потоке сильно проседает.
Сам себя исправляю. С 16 мая mtp в основной ветке. Поигрался с 27b, эффект есть, но с 18 т/с на 27 т/с - все равно грустно. А вот на 35b прирост всего 3 т/с - с 57 на 60, о чем многие пишут. В то же время ik_llama дает 77-80 без всяких mtp.
Исполняю сейчас все на 5060 ti и tesla t10, обе по 16 гб. Слабые, конечно, плюс pcie 3.0 (у 5060 вообще 8х), возможно упираюсь в скорость памяти и взаимный обмен
По факту у меня сейчас форк ik_llama, который не умеет в MTP, крутит Qwen3.6-35B-A3B заметно быстрее, чем ветка llama с поддержкой MTP. В ближайшие дни буду разбираться, но у меня пока эффект от MTP скорее обратный. Даже на плотной модели 27b. Но тут возможно сказывается то, что кручу на двух видеокартах, а не на одной и, возможно, с MTP этим как-то конфликтует - это же пока в экспериментальной ветке.
Сейчас реально круче: ушел на форк ik_llama.cpp, вместо cpu-moe использовал n-cpu-moe - раскидал сколько смог слоев в видеокарту. n-cpu-moe на обычной llama.cpp дал 50 т/с, на ik_llama.cpp получил 60 т/с и заметно уменьшившееся время первого токена.
Правда вчера добавил вторую видеокарту и от cpu-moe отказался. Получил 75-80 т/с и почти мгновенный первый токен (на opencode разница в анализе крупного C# проекта аж в 3 (!!!ТРИ) раза)
Я проводил эксперименты для себя. Чисто субъективно оценивая результат. Действительно, в обычных диалогах зачастую экстремально квантованная модель не отличается. Но в практическом применении, например opencode анализирующий проект из нескольких десятков файлов начинаются чудеса, вплоть до зацикливания модели. Однако уже квантование iq4 вполне себе работает и в большинстве примененийявляется разумным кокомпромиссом.
Есть другая похожая/сопутствующая проблема. При попытках ужаться во vram приходится включать квантование kv кэша. И если q8 ещё нормально проходит, то q4 сводит модель на длинных диалогах и задачах с ума. Особенно это касается v кэша, так как ошибка там итерационно накапливается.
Все по делу и системно. Спасибо!
Но зря вы откинули nextcloud. На этом железе будет очень прилично работать. У меня еще на древнем Asus eeePC с двухъядерным atom очень даже приемлимо работал, даже редактирование документов через браузер шевелилось (единственное, где было заметно, что процессор хилый). У вас будет если не летать, то вполне себе резво бегать. У меня поднят без докера, но и в докере он есть.
У меня началось с cubieboard. Сейчас в итоге самосбор в корпусе от сервера. Аппетит приходит во время еды
По факту на xeon:
E3-1230lv3 и e3-1285v4 в idle 6-10 вт
Сейчас e5-2690v4 -16 вт (задач стало сильно больше, включая локальный ии и виртуалки). Можно немного, а иногда ощутимо снизить потребление и ограничить tdp через intel-undervolt
Ну не прям со свистом. Но влезает. Если вам будет полезно субъективное мнение и опыт, то: относительно qwen3.6-35b с включенным cpu-moe по производительности на практике несколько, но не кардинально быстрее, но по качеству работы с кодом очееь заметно хуже. Железо 5060ti 16 gb + xeon e5 2690v4.
Прочитал ваш комментарий, чувствуется профдеформация. Сам такой временами. Но все-таки иногда стоит 'живости' добавить в текст.
Никак, если что, задеть не хотел.
Подтверждаю. Плотно тестировал. Практически все что смог скачать с хаггинфейс до 14b. В итоге что-то действительно полезное оказалось только qwen3.6 35b и плотный вариант 27b в экстремальном квантовании. После них разве что на gpt-oss-20b можно смотреть без отвращения
Эээ... Вы статью не через ии же генерили? Уж очень на нейрослоп похоже. Либо как-то не очень с подачей получилось
.. а если разобраться с cpu-moe для 35b модели qwen3.6 и квантованием контекста, то на относительно простой видеокарте получается весьма неплохой результат. У меня 36токенов/с, 260000 контекст на xeon 2690v4, 5060 ti 16gb. Я правда за 5 минут не разобрался и сделал это на llama.cpp. Но мне просто лень было копаться, а так по идее не сложно.
Спасибо за подсказку!
У меня lm studio через llmster на домашнем сервере (Xeon 2690v4, 64 gb RAM, 5060 ti 16 gb). Попробовал поиграться ключами аналогично вам, не взлетело.
Однако как второй вариант у меня стоит сам llama.cpp без оберток. Включил moe на cpu и квантование кэша. В итоге с контекстом 260000 получил около 36 токенов/с
Строка на запуск (вдруг кому-то надо будет, пока на отладке "гажу" в /root):
/root/llama.cpp/build/bin/llama-server -m “/root/.lmstudio/models/lmstudio-community/Qwen3.6-35B-A3B-GGUF/Qwen3.6-35B-A3B-Q4_K_M.gguf” --host 0.0.0.0 --port 1234 -c 240000 -ngl 99 -t 16 --cpu-moe --cache-type-k q8_0 --cache-type-v q8_0 -b 1024
А как сервис llama.cpp отконфигурирована так:
[Unit] Description=llama-server for Qwen3.6-35B-A3B-Q4_K_M.gguf After=network.target
[Service] Type=simple User=root ExecStart=/root/llama.cpp/build/bin/llama-server -m “/root/.lmstudio/models/lmstudio-community/Qwen3.6-35B-A3B-GGUF/Qwen3.6-35B-A3B-Q4_K_M.gguf” --host 0.0.0.0 --port 1234 -c 240000 -ngl 99 -t 16 --cpu-moe --cache-type-k q8_0 --cache-type-v q8_0 -b 1024 Restart=on-failure RestartSec=10
[Install] WantedBy=multi-user.target
Честно говоря когда захотелось тупо попробовать альтернативу ollama/lm studio (все cli) спросил бесплатный deepseek как поднять llama.cpp на домашнем сервере. Получил вполне приличную инструкцию шагов на 5, включая скачивание, которая дала результат сразу. Через openai сразу заработали и home assistant и open webui, поправил только ururl.
А по статье могу подтвердить, что ollama cli тупо раза почти в 2 медленнее что lm studio, что llama.cpp. Ещё и ram жрет при работе иногда непонятно зачем
Аналогично. Что только не пробовал (ограничен 16 гб vram 5060 ti), но наиболее адекватным и производительным оказалась qwen3.5-9b. Жаль, в отличие от более старых версий, нет варианта 14b. Более менее по субъективному ощущению 'интеллекта' сопоставима gpt-oss-20b, но gpt раза в 2-3 медленнее. В то же время старые модели qwen до 3.5 ощущаются какими-то кривыми: то с home assistant не дружат, то зацикливаются в ответах, то имеют кривоватый русский язык.
Читаешь и сначала думаешь, но ведь такое элементарно и обычно и все должны понимать, что всегда есть такой путь. Но оказывается многие и не задумываются о такой возможности и продолжают мучаться через gui. В моих задачах с iar нет необходимости в таком количестве вариантов сборки и все равно я еще лет 15 назад такие возможности изучил, удивив коллег. Так что статья очень полезна и кому-то откроет глаза.
Самое конечно веселое было с ПЛК icp-das. Под них до сих пор ПО пишется на borland c 3.1. Для автоматизации сборки пришлось написать скрипт на python, который запускает dosbox, в нем borland с необходимыми ключами и в итоге получается необходимый exe.
Именно. Путем автора вполне прошел, правда не дойдя до упаковки в корпус:
Для поиграться купил когда-то спонтанно cubieboard 2. Изначально задумывал embedded применение, но не пошло. В отличие от автора у cubieboard сразу было sata и преобразователь питания на плате, так что с ноутбучным винчестером вполне себе это работало сразу. Но очень быстро у меня вырос аппетит, захотелось не только файлопомойку, а ещё и на много дисков, свое облако и тп. В итоге пришлось идти по пути x86 железа. Что-то покупал новое, что-то б/у, за годы было несколько итераций смены платформы. Сейчас в итоге конфигурация такая:
Xeon 1240l-v3 (25 watt tdp)
Asus h97m-e (microatx lga1150)
32 gb ram (хватало для всего и 16, но оказалось ollama память любит)
4 hdd
2 sata ssd
1 nvme ssd
5060 ti 16 gb
Gh
На всем этом крутится свое облако nextcloud, home assistant, git, svn, transmission, samba, локальный ИИ в виде lm studio и ollama. Ну и всякая мелочевка.
Я ни разу автора не критикую. Как поиграться и что-то освоить почему бы и нет. Но очень быстро приходит осознание того, что решение крайне ограничено и надо что-то менять. К примеру свое облако на таком железе будет просто шевелиться, не бегать, а о возможности использовать nextcloud office/Collabora придется только мечтать.
Чуть по подробнее про железо не напишите?
Чисто по личному опыту (неделю вожусь с локальными llm, на личном сервере xeon 1240lv3, 16g ram, 5060 ti 16 gb):
- lm studio на linux сервере значительно быстрее чем ollama (начинал с нее), а главное не жрет так память
- перепробовал много моделей, пока для общего применения оптимальна openai/gpt-oss-20b - влезла в 12.2 gb VRAM с контекстом 65536
- отлично интегрировалась с open webui (через openai)
- при желании ставится вообще без gui
- при некоторых танцах с бубном заработала с home assistant