Comments 15
Что такое «толстый клиент»?
Если нужно десктоп приложение, то фаворита два: LM Studio и Msty Studio.
Оба с закрытым кодом, а открытый Jan.ai им не конкурент. Есть другая популярная опенсорсная полнофункциональная альтернатива Cherry Studio:
https://github.com/CherryHQ/cherry-studio
Если лезть в дебри ollama, то есть в консоль, то можно заглянуть и в оригинал. В llama.cpp уже встроен простой и удобный веб-клиент, на котором можно развернуться запуская модели на GPU + CPU через параметры -cmoe или -ncmoe N, которые до сих пор не поддерживаются в ollama.
-cmoe позволяет запустить на слабом железе не только GPT-OSS-120b или GLM-4.5-Air 110b, но и более крупные модели, если хватает обычной RAM памяти.
В ежедневных готовых сборках llama.cpp есть llama-server.exe, на huggingface есть команда для скачивания и запуска:
Модель GPT-OSS-120b весит 61гб, в домашние GPU она не лезет, но так как это MoE модель, то с помощью параметра -cmoe её можно разместить равномерно по GPU+CPU, всё что нужно на каждом шагу в GPU, всё остальное на CPU. На 64к контекста нужно всего 8гб VRAM:
llama-server -hf ggml-org/gpt-oss-120b-GGUF -c 65536 -fa -cmoe --jinja
Если модель уже скачана, то
llama-server -m "D:\mdels\gpt-oss-120b-MXFP4.gguf" -c 65536 -fa -cmoe --jinja
Даже на медленной 4060 можно получить скорость чуть выше 11 t/s на 47к контекста:
К чему это всё? GPT-OSS-120b уже давным давно спокойно работает на Ollama.
Речь, не про то, что работает, а про то как работает. Спокойной работает даже с диска - это не секрет, вопрос в том с какой скоростью.
Через выгрузку на GPU можно получить ускорение на Dense моделях уже давно, но на MoE моделях это почти не работает, тут нужен другой подход, когда выгружаются на GPU не отдельные слои, а тензоры внимания и часть ffn всех слоев сразу.
Кому интересно подробнее, как это работает: https://habr.com/ru/articles/921540/
Через -cmoe или --cpu-moe можно переключиться на такой режим и получить ускорение по сравнению со стандартным режимом. Это дает ускорение в 1.5-2 раза с меньшим расходом памяти.
Через -ncmoe N можно ещё эффективнее загрузить всю доступную VRAM, например, все 16гб VRAM и получить не 11 t/s, а 16 t/s, прирост ещё в 45%.
Сейчас это можно сделать на llama.cpp, на котором построены все остальные клиенты, включая LM Studio и Ollama, что тоже не секрет, но они предоставляют не полную поддержку всех фич, которая есть в движке. В LM Studio недавно добавили галочку для cmoe, но не ncmoe.
В Ollama реализация поддержки cmoe предложена, но она до сих пор не смержена в основную ветку: https://github.com/ollama/ollama/pull/12333
Также с августа висит запрос на поддержку ncmoe: https://github.com/ollama/ollama/issues/11772
Здравствуйте. Решил попробовать ваш метод запуска модели GPT-OSS-120b получилось так: через Ollama 15 t/s , через llama-server 26 t/s. Благодарю, это очень круто, можно таким образом "разогнать" модель! Позвольте задать вам пару вопросов:
Скажите пожалуйста, я могу на llama-server запустить уже скачанную для Ollama модель или так же придётся загружать с hf формат gguf модельки?
И вот ещё мне непонятно, я запускаю по вашему шаблону вот так:
llama-server -m "E:\gguf\gpt-oss-120b-mxfp4-00001-of-00003.gguf" -c 65536 -fa auto -cmoe --jinja
работает хорошо и быстро (26 t/s) vram кушает всего 6гб, ram ~70гб!
Но как только начинаю играться с параметрами, шаг влево - шаг вправо забивает полностью vram (5080 16гб) и под завязку оперативу (96гб). И так к примеру пробовал --threads 12 --gpu-layers 20 --n-cpu-moe 8 и сяк -c 65536 -fa auto -ncmoe 12 --jinja ... в общем пробежался по вашим постам и комментариям, пробовал многое и хоть ты тресни! как только отхожу от вашего шаблона с предыдущего поста, тупо сжирает всю память и на этом всё заканчивается.
Может подскажете как мне задействовать, ну скажем 14гб vram для большей производительности? А то вот везде в гайдах к llama пишут экспериментируйте с параметрами под свою систему, но вот у меня что то не срастается заняться экспериментами.
Скажите пожалуйста, я могу на llama-server запустить уже скачанную для Ollama модель или так же придётся загружать с hf формат gguf модельки?
У Ollama свой несовместимый формат-обертка, можно попробовать переименовать самый большой файл с хешированным именем, но не факт, что сработает. Проще скачать заново.
Плюс можно сразу взять кванты поинтереснее, например, от Unsloth с их динамическим квантованием UD, или от Ubergarm который выкладывает кванты для ik_llama, которые себя лучше показывают, чем стандартные кванты llama.cpp (создатель ik_llama и есть создатель квантов в llama.cpp, он сделал форк чтобы делать новые кванты). Или взять кванты MXFP4 не только для GPT-OSS, так как они должны быть быстрее на 5080, где есть нативная поддержка fp4.
И можно качать модели которые состоят из множества файлов, вроде 5 файлов GLM-4.5-Air-MXFP4_MOE-00001-of-00005.gguf, при запуске просто указать путь к 1 файлу.
Но как только начинаю играться с параметрами, шаг влево - шаг вправо забивает полностью vram (5080 16гб) и под завязку оперативу (96гб).
В деталях на счёт памяти может ошибаюсь, но смысл примерно такой. В Windows по умолчанию shared memory для GPU, а сам mmap, в отличии от Linux, занимает всю память под модель, и не высвобождает, что ушло на GPU.
-ncmoe 8 - это значит, что только 8 слоев пойдут на CPU (не на GPU). Если всего слоев 37, значит 29 пойдут на GPU, то есть потребуется ~50Гб для этого. Windows будет пытаться использовать такое количество памяти для GPU в shared, и сам mmap резервирует всю модель. В итоге двойной перерасход памяти.
как мне задействовать, ну скажем 14гб vram для большей производительности?
Удобного способа нет, поэтому просто какой есть:
Сначала узнать сколько слоев у модели, это показывается в консоли при загрузке. Например, у GLM-4.6 94 слоя, а у GPT-OSS-120B слоев 37.
Выставить в ncmoe число равное количеству слоев и по шагам уменьшат его в сторону 0. Тут работает инвертированный принцип, а не привычный как у ngl.
Смотреть на количество MiB загружаемого на CUDA0 и добиваться нужного количества занятой VRAM.
Надо учитывать размер контекста, там тоже это пишется. Чтобы снизить расход VRAM на контекст, можно использовать -ctk q8_0 -ctv q8_0, это квантование KV-кэша в Q8_0, немного снизит качество, но в 2 раза снизит расход памяти на контекст.
--jinja - это флаг для встроенного в gguf шаблона чата, чтобы текст правильно выводился. На производительность не влияет, но влияет на качество ответа. Нужно указывать не везде, только у квантов где это указано. В рамках одной модели могут варианты с этим флагом и без него.
Чтобы не вбивать каждый раз параметры вручную для каждой модели, есть: https://github.com/mostlygeek/llama-swap
Главное следить, чтобы память GPU не выходила за пределы своего максимума. Если залезет хоть немного в shared (именно модель, а не работа ОС), то это сильно снизит скорость генерации. Отключение "CUDA: политика резервной системной памяти" больше не помогает, поэтому приходится вручную следить за этим либо через диспетчер задач, либо через nvidia-smi -l 2.
Это просто чудо! Благодаря вам удалось выжать ~30 t/s по сравнению с Ollama (15 t/s) двухкратный прорость скорости! Спасибо вам огромное!
Запускаю вот так:
llama-server -m "E:\gguf\gpt-oss-120b-mxfp4-00001-of-00003.gguf" -c 32768 -fa auto -ncmoe 29 --jinja
(-ncmoe 29 подбирал опытным путём, смотрел через диспетчер задач при каждом запуске сколько кушает vram)
И да, вы точно указали, как только выходит за рамки vram скорость снижается до ~10 t/s
Вот думаю теперь скинуть свою оперативу и взять два комплекта по 96гб т.к. меня в принципе устраивает модель (gpt-oss-120b) по точности и адекватности ответа, но ещё ж и приложениям требуется память. Мне было комфортно и с 15 t/s (главное можно читать текст в процессе генерации, пока он не убежал за скролл) но теперь вдохновился скоростью работы и буду подключать к IDE. Хочу вот ещё одну хорошую moe модельку llama4:16x17b попробовать.
Можно ещё вопросик? Помимо 5080 16гб есть у меня и 6900XT 16гб, как думаете, если я подключу их обе в Debian (в винде 5080 начинает себя неадекватно вести если обе работают) в режиме по х8 линий на каждую, можно ли ожидать существенного профита от такого решения? Ну вроде vram получается суммируется в 32гб + распараллеливание задач аж на целых два достаточно производительных чипа. Стоит ли игра свеч?
А вы на русском общаетесь с моделькой? Просто и llama и gpt-oss не очень хороши в этом.
Хочу вот ещё одну хорошую moe модельку llama4:16x17b попробовать.
llama4:16x17b - это Llama-4-Scout, очень слабая модель.
Попробуйте GLM-4.5-Air-MXFP4, и скоро должна выйти GLM-4.6-Air, эта модель куда интереснее и часто бывает лучше чем GPT-OSS.
Ну вроде vram получается суммируется в 32гб + распараллеливание задач аж на целых два достаточно производительных чипа. Стоит ли игра свеч?
Есть 2 основных способа объединить GPU:
тензорный параллелизм (Tensor Parallelism), тензоры одной операции разбиваются на блоки, и каждая карта параллельно считает свой блок, потом объединяет результат.
конвейерный параллелизм (Pipeline Parallelism), на разные карты уходят разные слои, сначала работает первая карта, потом вторая.
В первом случае вы получаете и распараллеливание вычислений и удвоение объема VRAM, а во втором случае в основном только удвоение VRAM, но в батчинге можно получить ускорение. Для тензорного параллелизма нужно использовать vLLM или ExLlama, но там не получится использовать связку GPU+CPU.
В llama.cpp реализовано что-то похожее через --split-mode row, но работает не очень хорошо, хотя некоторые пишут, что получают ускорение на двух GPU.
Ещё 5080 поддерживает вычисления в fp4, gpt-oss как раз в fp4 (в MXFP4, ещё есть улучшенный NVFP4, который в llama.cpp пока не поддерживается), если добавить карту которая не поддерживает fp4, то скорее всего скорость упадет.
И надо будет использовать Vulkan, чтобы объединить Nvidia + AMD, это ещё потери скорости.
За Cherry спасибо. Много рыскал по интернету, но его не встретил. Попробую его и если что допишу статью :)
Сюда бы ещё добавить про RAG и доступные из коробки агенты, такие как веб-поиск или глубокое исследование. А так сейчас openwebui стандарт де факто в индустрии, там есть все, и даже на телефон можно поставить как PWA.
Чуть дополню: Chatbox есть и под андроидом =)
Msty пробовал, какое-то тормозное оно всё. Главное будучи запущенным на таком же компе (но другом) который производит инференс, оно тупит раз в пять сильнее, чем моделька выдает ответ. По факту моделька уже написала и отдала ответ, а эта штука еще тупит порой на ровном месте. Те же mermaid диаграммы может "обдумывать" минут по 10, прежде чем нарисовать. Хотя код диаграммы давно получен. С html то же самое. Или только у меня лыжи не едут?
Краткий обзор 10 локальных UI для LLM