Обновить

Комментарии 29

ЗакрепленныеЗакреплённые комментарии

Если взять хороший PCIe 4.0 NVMe с реальным последовательным чтением около 7 ГБ/с, абсолютный I/O-предел получается:

250 ГБ / 7 ГБ/с ≈ 36 секунд на токен, то есть максимум около 0,028 tok/s.

И это идеальный случай: без filesystem overhead, загрузки tensors, CPU→GPU transfers и вычислений. Реальность будет медленнее.

Есть хорошая контрольная точка из самого проекта: в свежем issue для Qwen2.5-32B без compression измерили 13,3 с/токен. Для 32B bf16 это примерно 64 ГБ весов. Теоретически при 7 ГБ/с было бы около 9 секунд, то есть реальные накладные расходы дают примерно ×1,45 к идеальному I/O floor.

Если тот же коэффициент грубо перенести на Flash-Next:

36 × 1,45 ≈ 52 секунды на токен → ~0,019 tok/s.

Поэтому я бы закладывал для RTX 4090 + быстрого Gen4 NVMe порядок 0,015–0,03 tok/s, то есть примерно 30–70 секунд на один output token.

Статья как всегда не говорит самого главного: а скорость инференса-то какая?

Если взять хороший PCIe 4.0 NVMe с реальным последовательным чтением около 7 ГБ/с, абсолютный I/O-предел получается:

250 ГБ / 7 ГБ/с ≈ 36 секунд на токен, то есть максимум около 0,028 tok/s.

И это идеальный случай: без filesystem overhead, загрузки tensors, CPU→GPU transfers и вычислений. Реальность будет медленнее.

Есть хорошая контрольная точка из самого проекта: в свежем issue для Qwen2.5-32B без compression измерили 13,3 с/токен. Для 32B bf16 это примерно 64 ГБ весов. Теоретически при 7 ГБ/с было бы около 9 секунд, то есть реальные накладные расходы дают примерно ×1,45 к идеальному I/O floor.

Если тот же коэффициент грубо перенести на Flash-Next:

36 × 1,45 ≈ 52 секунды на токен → ~0,019 tok/s.

Поэтому я бы закладывал для RTX 4090 + быстрого Gen4 NVMe порядок 0,015–0,03 tok/s, то есть примерно 30–70 секунд на один output token.

У MoE моделей для генерации токена используются не все параметры. Количество активных параметров 6B. Для BF16 и скорости SSD 7 Gb/s получится примерно 0.5 t/s. В реальности можно получить больше, если поместить часть или все веса в RAM.

Раньше было "зачем вы общаетесь с копипастой", теперь "зачем вы общаетесь с нейросетью".

Человек не подумав:

1) сгенерировал статью и обосрался тем что не записал ни методологию, только "Вау 6 гигов видеопамяти" и ни одного ответа на оставшиеся вопросы в том числе "зачем", зато реклама тг канала есть

2) дописал комментарий и опять обосрался непониманием архитектуры, "Бог-из-машины ведь лучше знает"

Бездумно копировать ответы из чата жыпити много ума не надо. Я постоянно работаю с топовыми нейросетями над ускорением инференса в локальной среде нашей компании и даже Fable-level сетки постоянно совершают подобные детские ошибки. Человек который вообще не разбирается в том как это работает с инженерной точки зрения и не сможет отличить их попугайничество в духе "ну там жи весов на 360 гигов, 7 Гб в секунду будет долга грузитб" от нормального ответа. ОП не может, очевидно.

Ну че-то сомнительный результат. Оно конечно ожидаемо, раз веса в bf16, но хотелось бы бенчмарков в квантах.

На моей рабочей станции, 64 ГБ DDR4, 2xV100 16GB и SSD pci-e 4.0 x4, Q3_M даёт 15-20 т/с. Боль в том что префилл порядка 500-200 т/с, но в общем даже юзабельно. Контекст влезает 64к.

если хотя бы 10-20 токенов/с нет это уже неюзабельно

Очень интересно сколько токенов оно будет выдавать. Если я правильно понимаю "стиримить декодер", то нужно будет постоянно веса гонять в VRAM и обратно?

И какой размер контекста

Из комментариев к оригиналу.
15 минут на короткий ответ.

Я полагаю, настроив Reasoning, это время можно существенно сократить. Хотя конечно он любит по поводу и без пускаться в долгие рассуждения.

Очень странный результат, проверю этот промпт, отпишусь позже. Со своей стороны, я заметил, что reasoning в этой модели стал более адаптивным к задаче, в отличие от версий 3.5/3.6. Если спросить модель "привет, как дела?", thinking проходит намного быстрее, чем в предыдущих поколениях. И наоборот, просьба сгенерировать максимально реалистичный ThreeJS Boeing 747, погружает модель в долгие раздумья на десятки тысяч токенов. One-shot Боинг геометрически получается много лучше и стабильнее, чем в веб версиях DeepSeek или GLM 5.3/5.3 Flash (успел сравнить только эти). Правда файл потребовал коррекции - изначально вообще не запустился, что неудивительно для трёхбитной квантизации (Unsloth).По скорости инференса ситуация следующая: на 3-4 битных квантизациях стартует с приемлемых 17-21 т/с, спустя 100-150 тысяч токенов скатываясь к унылым 9-12 т/с. Конфиг: LM Studio, 13900k, RTX 4080S, 128Gb DDR4 3600. Оффлоад всех весов на GPU и почти всех экспертов в RAM.

Смущает арифметика вокруг n-gram таблицы. В статье это 51B параметров, то есть около 102 ГБ в bfloat16, а рекомендованный объём ОЗУ — 64 ГБ. Таблица физически не помещается в память целиком, значит mmap работает не как «развернули и держим», а как постоянные промахи page cache с обращением к SSD.

Отсюда главный вопрос, на который в тексте нет ни одной цифры: сколько токенов в секунду? Layer-wise inference со стримингом весов с диска — это по определению обмен скорости на объём, и обычно обмен очень невыгодный. Без tok/s непонятно, речь про «медленно, но можно работать» или про «один ответ за вечер».

И отдельно про «конкурирует с Opus по бенчмаркам». Хотелось бы ссылку на конкретный прогон, а не тезис в пересказе. У модели ~6B активных параметров на токен, заявка сильная, проверить её по тексту нечем.

102 ГБ таблицы, конечно, не превращаются в 64 ГБ RAM: mmap здесь позволяет не материализовывать всю таблицу в оперативной памяти, а нужные страницы обслуживаются через page cache, поэтому накопитель и паттерн обращений действительно становятся частью производительности.

По tok/s согласен, этой цифры в исходных данных не хватает. Для режима с 5,95 ГБ VRAM я не нашёл опубликованного замера, поэтому придумывать конкретное значение не буду..

Насчет «конкурирует с Opus по бенчмаркам» - это результаты, опубликованные самой Qwen, а не мой независимый прогон. Например, SWE-bench Pro — 62,5 против 53,4 у Opus 4.6 Max, SWE-bench Multilingual — 81,0 против 77,5 и так далее.

Про mmap согласен, сформулировал неточно: материализовывать всю таблицу никто не собирается. Я имел в виду ровно то, к чему вы и пришли в конце фразы, что накопитель и паттерн обращений становятся частью производительности. При 64 ГБ page cache на 102 ГБ таблицы попадания будут не всегда, а промах это случайное чтение, где NVMe даёт уже не гигабайты в секунду, а десятки микросекунд на запрос.

Раз замера нет, попробую прикинуть нижнюю границу по числам из статьи, поправьте, если ошибаюсь в реализации.

На токен активно ~6B параметров, в bfloat16 это примерно 12 ГБ, которые надо поднять с диска, если нужные эксперты не осели в кэше. Даже на хорошем Gen4 NVMe с семью гигабайтами в секунду последовательного чтения выходит около полутора секунд на токен, и это оптимистично: чтение не строго последовательное, а page cache тем временем делят между собой веса и n-gram таблица, они конкурируют за одни и те же 64 гигабайта.

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

За цифры по бенчмаркам спасибо, стало понятнее. То, что они от самой Qwen, вы честно оговорили, и это ровно та причина, по которой я бы подождал независимых прогонов: у вендорских таблиц отбор задач и настройка прогона обычно свои.

Не ну через mmap любой дурак хоть на ноуте запустить может хоть терабайтную модель. И с инференсом 0.1 ток в час. Оно такое для отложенных задач не нужно в принципе, совсем.

скорость инференса в студию!

А код то нерабочий. Там некоторые аргументы для чего-то переведены с английского.

Изменил код в статье, попробуйте с новым

В статье 4 раза сказано что "Пиковое потребление VRAM составило 5,95 ГБ", многие другие моменты тоже по нескольку раз повторены. Физически тяжело такое читать. При этом главного вывода о скорости работы и стоит ли оно вообще того - нет. Из статьи я даже не понял зачем бралась модель bf16, а не q8 или q4 например. Не понял, можно ли было вместо 5,95 ГБ VRAM утилизировать больше видеопамяти так как видеокарта 4090 это позволяла - какой бы это дало эффект? Вообщем, очередная мусорная статья ни о чем....

Я на своём карте с 12 VRAM сколько раз пытался запустить локальную модель (любую), но всегда либо какие-то зависания происходят + эффективность работы с локальной моделью, как по мне, намного ниже с любой бесплатной облачной

https://youtube.com/watch?v=IH8XmxiwliQ&lc=Ugx1GnATTfr_FS-ecKx4AaABAg&si=xjuCKq2-ohDudWfC

Вот тут автор видео показывает с какими параметрами запускает и получает около 20 токенов в секунду

Я использовал Q3 для большей надежности, но после проведения теста оперативной памяти думаю, что Q4 тоже подойдет практически без потери скорости. Но Q3 тоже отлично работает с этой моделью... Кроме того, не было никаких зацикливаний или странного поведения. Команды и флаги llama.cpp Официальные флаги llama.cpp [Возможно, вам потребуется подкорректировать эти числа для достижения наилучшей производительности и более высокого контекста, но в большинстве случаев это сработает] llama-server -m Qwen3.8-Flash-Next-UD-IQ3_XXS-00001-of-00003.gguf \ -ngl 99 --n-cpu-moe 99 --load-mode mmap -fa on \ -ctk q8_0 -ctv q8_0 -c 16384 -b 2048 -ub 512 --jinja для форка Codacus: Я действительно рекомендую вам Укажите путь к репозиторию для Клода или Гота, инструкции см. в файле README. ./build/bin/llama-server \ -m Qwen3.8-Flash-Next-GGUF/UD-IQ3_XXS/Qwen3.8-Flash-Next-UD-IQ3_XXS-00001-of-00003.gguf \ --moe-cache-profile qwen38-merged.csv --moe-cache-slots 48 \ -md Qwen3.8-Flash-Next-GGUF/MTP/mtp-Qwen3.8-Flash-Next-shared-Q8_0.gguf \ -ngld 0 --spec-type draft-mtp --spec-draft-n-max 1 \ -ngl 99 --n-cpu-moe 99 --no-sched-async-cpu -t 6 \ --load-mode mmap -fit off -fa on -ctk q8_0 -ctv q8_0 \ -c 65536 -np 1 --cache-reuse 256 \ -b 2048 -ub 512 --jinja --host 0.0.0.0 --port 8080

Статья вообще ничем. Это же квен4 со своими плюшками. У меня на 3090 и 64 гб озу выдаёт под 50 т/с. Обращение к ссд редко превышает нескольких мегабайт в секунду, иногда 200-300. В этом кайф нграм таблицы. Автор вообще не понял, что это и как с этим жить. Статья, мягко говоря, нуждается в полной переработке.

Сколько токенов получается в режиме заполнения контекста?

Я больше 20-30к не использовал. Просто запускал из любопытства. Посадки почти не было. Посадка на уровне квен3.8 27б.

Что за мода пошла на теоретические проекты с нейрослопными статьями?

То Colibri "изобрали" файл подкачки, теперь эта статья, которая "изобрала" динамическую подгрузку данных в GPU, ура, мы запустили модель и она по тестам круче, чем Opus 4.6 Max и пиковое потребление GPU 6 ГБ, ну т.е. по сути, это практически CPU offload получается, который и так был до этого.

Ну т.е. смысл видеокарт с HBM памятью как раз таки в том, что модель помещается в GPU и там видюха "шуршит" на полной скорости, а когда для обращению к нужному эксперту или даже kv блоку надо обращаться к диску мы получаем не 50 т/с а 0.005 т/с и тут возникает вопрос: условно, я запускаю 27B модель для решения типовой задачи, она перемалывает простенькие задачи на нормальной скорости, теперь мне надо проверить архитектуру или найти какие-то нестыковки или исправить сложный баг или "доказать теорему" т.е. не просто напиши функцию суммирования 2х чисел, а произведи огромное количество высислений на скорости 0.0000001, скорее всего, там еще и контекст будет от 200к в процессе, т.е. на такой сложной задаче такая крутая модель будет работать неделю и не факт, что сможет выдать результат, сожрет электроэнергии больше, чем дорогущее яндекс ИИ взяло бы за свою топовую модель.

Вы хоть сами провели хотя бы один тест лоб в лоб с opus 4.6 max vs airLLM на действительно сложной задаче?

Простите, накипело, прочитал всю статью, увидел раздел с тестами, в тестах потребление VRAM и не слова про скорость, а это первое, что интересует читателя т.к. он примерно понимает качество модели, у него есть железо или он планирует купить железо из заголовка статьи и он хочет понять как эта модель работать на этом железе, а ему отвечают: эта модель очень крутая и мы ее запустили на этом железе, все, даже змейку не закодили.

Это мусорные статьи, авторы даже не пытаются проявить уважение и минимально привести в читаемый вид, я уж не говорю про содержательную часть. Главное раскрутить канальчик.

  • n-gram table размером около 102 ГБ остаётся на диске, отображается в память и обрабатывается на CPU;

А если оперативки много? Если обойтись без диска, будет быстрее?

Быстрее, это называется CPU offload, время ответа на сложную задачу сократится с нескольких недель до нескольких дней, вместо минут или десятков минут при полном хранении в GPU,
Ну т.е. пока что это все находится за пределами юзаельности.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации