Обновить
3

Пользователь

0,2
Рейтинг
1
Подписчики
Отправить сообщение

Не более трёх мегатюрингов!

Такое было, но не из-за MTP. Лечится опцией --chat-template-kwargs '{"preserve_thinking": "True"}'. В новой версии llama.cpp появилась опция --reasoning-preserve, но я ещё не проверял.

Таких цифр не видел на таком количестве слоёв

Вчера обновил llama.cpp до версии 9837, стало ещё быстрее. Вот параметры запуска модели:

CUDA_VISIBLE_DEVICES=0,1 llama-server --host 0.0.0.0 --port 8081 -m Qwen3.6-35B-A3B-UD-Q6_K_XL.gguf -fitt 1024 -c 262144 -ngl 999 --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.00 --no-mmap --spec-type draft-mtp --spec-draft-n-max 4

Вот лог со скоростью вывода (в основном это генерация кода, она на MTP немного быстрее, чем просто текст):

0.57.525.739 I slot print_timing: id  3 | task 0 | n_decoded =    464, tg = 154.33 t/s, tg_3s = 154.31 t/s
1.00.547.542 I slot print_timing: id  3 | task 0 | n_decoded =    945, tg = 156.76 t/s, tg_3s = 159.18 t/s
1.03.564.859 I slot print_timing: id  3 | task 0 | n_decoded =   1469, tg = 162.40 t/s, tg_3s = 173.66 t/s
1.06.568.765 I slot print_timing: id  3 | task 0 | n_decoded =   2013, tg = 167.06 t/s, tg_3s = 181.10 t/s
1.09.573.904 I slot print_timing: id  3 | task 0 | n_decoded =   2425, tg = 161.08 t/s, tg_3s = 137.10 t/s
1.12.586.396 I slot print_timing: id  3 | task 0 | n_decoded =   2817, tg = 155.92 t/s, tg_3s = 130.12 t/s
1.15.589.639 I slot print_timing: id  3 | task 0 | n_decoded =   3262, tg = 154.81 t/s, tg_3s = 148.17 t/s
1.18.591.986 I slot print_timing: id  3 | task 0 | n_decoded =   3639, tg = 151.17 t/s, tg_3s = 125.57 t/s

Карты - обычные 3090 с максимальной мощностью 350Вт, включены в плату MACHINIST X99 MR9S с процессором Xeon E5-2697 v4 и 64Г оперативы.

Qwen3.6-35B-A3B - это MoE модель (3B активных параметра), а Qwen3.6-27b - плотная (27B активных), потому разница в скорости. Но плотная заметно умнее. Автору рекомендую обновить llama.cpp до самой свежей версии, не исключено что скорость генерации повысится. У меня на 2х3090 плотный Квен (Q6) даёт до 60 ток/с, а MoE - до 140.

Грубо - среда, в которой выполняется программа, имеет REPL. Заходите в него, и на ходу правите код. Или, например, крутится у вас web-сервер. Вдруг один из потоков выбрасывает исключение. Вы можете зайти в REPL, поправить код и продолжить выполнение с того места, где возникла ошибка. В других потоках код тоже исправится. Как-то так (грубо).

но получается не принципиально лучше REPL в других языках.

Таки репл в коммонлиспе - это совсем не репл в питоне (и в других языках). Это совершенно разные реплы. Репл в питоне - это интерактивный интерпретатор. Репл в лиспе - это переписывание работающей программы.

Интерполяция строк, блоки, метки, декораторы - всё это позволяет увеличить ёмкость информации и упрощает оперирование.

Скобки лиспа находятся у другой крайности - слишком мало ёмкости.

Категорически нет! Всё ровно противоположно. Лисповые скобки дают бесконечную ёмкость, поскольку позволяют выразить любую глубину абстракции единым и понятным способом. Как раз те костыли, в виде декораторов, меток и пр. - это попытка поднять уровень абстракции средствами, которые для этого не годятся.

Кроме того, в лиспе свободно и нативно реализуются все эти декораторы и строковые интерполяции. Но большинство этих вещей там не нужно, потому что есть способы лучше, и выражаются они через скобки.

А как насчёт обилия скобок

Скобки - это наверное лучшее, что есть в лиспе. Трудночитаемость - это миф, да и избыточное количество скобок - тоже (достаточно посмотреть на синтаксис современных языков, типа Rust и C++ - там кроме скобок разного вида ещё и куча закорючек). Этот миф распространяют те, кто никогда на лиспе не писал.

У меня самое дешманское открытое шасси с Али, мать Machinist X99 и три видеокарты, одна из которых стоит над другими на напечатанном креплении, и подключается к PCIe удлиннителем 20см. Отлично работает. Я бы мог подключить ещё одну, но смысла в этом не очень много.

Очень круто! Автор просто красавчик, что не бросил затею на пол пути. Теперь можно было бы сделать печатную плату. Но если автор откажется, я его всецело пойму :)

Ну вот я видел результаты тестов разного квантования, например, у Unsloth. По ним можно сделать вывод, что Q4 совсем незначительно уступает Q8. Но автор говорит, что это всё лоботомия, и кодить скрипты на питоне на Q4 категорически нельзя. Вот хотелось бы доказательств.

На словах красиво, а есть цифры? Хочется осязаемых метрик, а не размышлений на тему. И результатов тестов тоже хочется. Какие ваши доказательства? (С)

А исходники будут?

Это старые данные. Модель в таком виде была на HF несколько дней после публикации 3.5. Она действительно была глючной. Потом поправили, и размер её стал на 2Г больше.

Сравните с VexRiscv. По моим тестам у него лучшее отношение производительности к площади.

Для использования 75-омного кабеля можно попробовать поставить терминаторы на 75 Ом (можно просто резистор в разъём воткнуть).

Qwen3.5-397B UD-IQ3_S

На такой квантизации уже сильно падает качество. UD-Q4_K_XL - ещё норм, но если ниже, то очень заметна разница.

И по поводу скорости. 10-20 токенов на генерации терпимо, но низкая скорость на промпте - это прям грустно, особенно когда делается сжатие контекста. А на 80к это часто надо делать.

Всё ж надо пару, а лучше тройку 3090, чтобы cpu разгрузить. И контекст побольше. Но это моё ИМХО, не настаиваю.

Какой сетап?

/plan и только планирование гарантировано

На днях в режиме планирования:

Thinking: Ошибка в task tool. Попробую создать файл напрямую с помощью bash команды echo.

И создал :)

1
23 ...

Информация

В рейтинге
3 288-й
Зарегистрирован
Активность