Comments 57
Если взять хороший 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к.
префилл порядка 500-200 т/с
На самом деле очень даже неплох. Понятно что чем дальше тем префил будет дольше, но это в разы быстрее чем у меня в MTPLX
На моей рабочей станции, 64 ГБ DDR4, 2xV100 16GB и SSD pci-e 4.0 x4, Q3_M даёт 15-20 т/с.
Главный вопрос - работает ли это по факту лучше той же плотной 3.8 27b модели которая при вашем сетапе спокойно влезет в Q4 с контекстом 128к при q16 кеша?
Медленный префилл это боль на любых задачах с подагентами. Вот по тупости пока их между собой не сравнивал.
Если KV кеш от предыдущих запросов сохраняется, то при новом сообщении в тот же чат пересчитываться будет только это сообщение и новые файлы, которые агент читает.
Кеш сбрасывается, когда в VRAM не хватает места для новых KV. Например, если параллельно приходит второй запрос (другой чат или агент с уже раздутым контекстом). Чтобы избежать сброса кеша, на машинах с малым VRAM нужно работать в один поток, без суб-агентов.
У vLLM можно включить выгрузку KV-кеша в ОЗУ при нехватке VRAM. Это позволяет пользоваться несколькими агентами паралельно без пересчитывания кеша, даже если в vram влезает всего один просчитанный KV cache полного контекста (типично для 16-32 гб vram и 27b моделей). Подтянуть кеш из ОЗУ в десятки раз быстрее, чем пересчитывать его заново.
Инструкции для vLLM тут: https://vllm.ai/blog/2026-01-08-kv-offloading-connector https://github.com/vllm-project/vllm/blob/main/docs/features/kv_offloading_usage.md
В LLama и SGLang такой фишки к сожалению нет.
если хотя бы 10-20 токенов/с нет это уже неюзабельно
Т.е. ценность такого эксперимента примерно равна ценности запуска DOOM на электрической зубной щетке. Можно, но зачем? :)
Я только что скомпилировал в docker llama.cpp без avx512 и запустил на DDR3 + 2x Xeon E5-2697 v2 + RTXA4000 (16GB) и загрузил на этом qwen3.8-Flash-Next Q4_K_M. Получилось 14 t/s.
Если у вас нормальный процессор, а не как у меня, то у компилировать ничего не нужно. Запускал я так:
```
docker run --name llama-server -it --rm --gpus '"device=0"' --network host -v /opt/docker/llama-cpp/:/models:ro llama-nvidia:b10853 --model /models/Qwen3.8-Flash-Next-Uncensored-Q4_K_M-00001-of-00003.gguf --mmproj /models/mmproj-Qwen3.8-Flash-Next-Uncensored-F16.gguf -n 65536 --n-gpu-layers 99 --host 0.0.0.0 --port 8080 --cpu-moe -lv 3 -b 1024 -ub 512 -fa auto --load-mode noneСамое важное тут, это ключи к llama-server:
–model /models/Qwen3.8-Flash-Next-Uncensored-Q4_K_M-00001-of-00003.gguf # первый файл модели, осталные находит сама
--mmproj /models/mmproj-Qwen3.8-Flash-Next-Uncensored-F16.gguf # это графическая часть модели, чтобы картинки понимала
-n 65536 # Длинна контекста
--n-gpu-layers 99 # Мы как-бы говорим, грузи всё в GPU, но ниже исключим из этого "всего" экспертов
--host 0.0.0.0 # слушаем на всех интерфейсах
--port 8080 # на порту 8080
--cpu-moe # Экстперты остаются на CPU
-lv 3 # Уровень логирования
-b 1024 -ub 512 # google посоветовал, мол так быстрее должно быть.
-fa auto # flash attention
--load-mode none # не использовать mmap (у меня с ним было 4t/s)
Результаты:
```
root@nn-vm04:~# docker run --name llama-server -it --rm --gpus '"device=0"' --network host -v /opt/docker/llama-cpp/:/models:ro llama-nvidia:b10853 --model /models/Qwen3.8-Flash-Next-Uncensored-Q4_K_M-00001-of-00003.gguf --mmproj /models/mmproj-Qwen3.8-Flash-Next-Uncensored-F16.gguf -n 65536 --n-gpu-layers 99 --host 0.0.0.0 --port 8080 --cpu-moe -lv 3 -b 1024 -ub 512 -fa auto --load-mode none
0.00.127.667 I cmn common_param: common_params_print_info: verbosity = 3 (adjust with the `-lv N` CLI arg)
0.00.128.337 W srv llama_server: -----------------
0.00.128.341 W srv llama_server: CORS is set to allow all origins ('*') and no API key is set
0.00.128.342 W srv llama_server: this can be a security risk (cross-origin attacks)
0.00.128.342 W srv llama_server: more info: https://github.com/ggml-org/llama.cpp/pull/25655
0.00.128.342 W srv llama_server: -----------------
0.00.129.820 I srv load_model: loading model '/models/Qwen3.8-Flash-Next-Uncensored-Q4_K_M-00001-of-00003.gguf'
1.16.469.441 I cmn init: llama threadpool init, n_threads = 24
1.16.744.734 W load_hparams: Qwen-VL models require at minimum 1024 image tokens to function correctly on grounding tasks
1.16.744.742 W load_hparams: if you encounter problems with accuracy, try adding --image-min-tokens 1024
1.16.744.742 W load_hparams: more info: https://github.com/ggml-org/llama.cpp/issues/16842
1.17.488.669 I srv load_model: loaded multimodal model, '/models/mmproj-Qwen3.8-Flash-Next-Uncensored-F16.gguf'
1.17.742.012 I srv load_model: initializing, n_slots = 4, n_ctx_slot = 216832, kv_unified = 'true'
1.17.751.267 W srv init: chat template supports preserving reasoning, it is enabled by default (may use more tokens, disable via --no-reasoning-preserve)
1.17.751.342 I srv llama_server: model loaded
1.17.751.355 I srv llama_server: listening on http://0.0.0.0:8080
1.17.751.356 W srv llama_server: NOTICE: server default port will be changed to :9931 in a future release
1.17.751.356 W srv llama_server: ref: https://github.com/ggml-org/llama.cpp/pull/26508
1.42.654.643 I slot get_availabl: id 3 | task -1 | selected slot by LRU, t_last = -1
1.42.655.118 I slot launch_slot_: id 3 | task 0 | processing task, is_child = 0
1.49.913.408 I slot print_timing: id 3 | task 0 | prompt processing, n_tokens = 360, progress = 0.96, t = 7.26 s / 49.62 tokens per second
1.50.513.335 I slot print_timing: id 3 | task 0 | prompt processing, n_tokens = 371, progress = 0.99, t = 7.86 s / 47.23 tokens per second
1.57.241.901 I slot print_timing: id 3 | task 0 | prompt eval time = 8244.71 ms / 375 tokens ( 21.99 ms per token, 45.48 tokens per second)
1.57.241.909 I slot print_timing: id 3 | task 0 | eval time = 6339.59 ms / 90 tokens ( 71.23 ms per token, 14.04 tokens per second)
1.57.241.910 I slot print_timing: id 3 | task 0 | total time = 14584.30 ms / 465 tokens
1.57.241.918 I slot print_timing: id 3 | task 0 | graphs reused = 89
1.57.242.228 I slot release: id 3 | task 0 | stop processing: n_tokens = 464, truncated = 0
root@nn-vm04:~# free -m
total used free shared buff/cache available
Mem: 257889 84927 84494 77388 168156 172962
Swap: 8191 0 8191
Короче, prefill 45t/s, eval 14 t/s
Модель даже в Q4_K_M и как видите я загрузил со снятой цензурой - очень умная. Не знаю даже, нужно ли пытаться Q8 или так уже достаточно. У кого есть nvidia spark, думаю must have, у меня нет, но даже на паре старинных ксеонов по 5000 руб за штуку и 256ГБ ddr3 1866 MT/s работает с удовлетворительной скоростью. Кстати, оперативной памяти занимает всего 85GB, так что вам хватит 128ГБ, но учтите, что у 2-х ксеонов 8 каналов памяти. Если есть 128ГБ DDR4 REG я бы взял один или два AMD EPYC. Кстати на эпиках ближайшее время протестирую и напишу скорость.
Оптимально запустить на AMD RYZEN типа 7950X или выше и 128GB RAM + видеокарта на 16GB VRAM.
Никакая😂 это бред плюс квантование извращенско низкое она а и б только с трудом говорить будет
Очень интересно сколько токенов оно будет выдавать. Если я правильно понимаю "стиримить декодер", то нужно будет постоянно веса гонять в 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.
Боже, какая чушь. Почему интересно у меня выдает 15-20 t/s?
готовить надо с умом наверное
Странная у этого комментатора 4090.
У меня на 5070Ti+5060Ti (всего 32GB VRAM) и 96GB DDR4 ответ на вопрос “What is the capital of France?” занял всего 3 секунды или 8 секунд при первом запросе после запуска llama-server. Использовались рекомендуемые параметры для режима Thinking. GGUF bartowski/Qwen3.8-Flash-Next-Q4_K_M. llama.cpp от 2026-09-04. При обработке большого контекста скорость в районе 300 t/s (pp), генерация ~20 t/s.
читал где то что 2 видео карты даже в режиме SLI/Crossfire не могут давать общую память для весов LLM. как у вас это реализовано если не секрет? Реально ли как то объединять VRAM с разных видео карт если это не V100 или подобные спец карты?
Каждая карта работает независимо. В llama.cpp есть несколько режимов разделения нагрузки, подробнее тут https://github.com/ggml-org/llama.cpp/blob/master/docs/multi-gpu.md Замечу, что если вся модель не помещается в VRAM, то от использования нескольких GPU может быть моло толку. Конкретно с этой моделью почти нет различия в скорости между 1 или 2 GPU. Только RAM больше остается свободной при использовании 2.
Я бы не доверял комментарию человека, который даже не знает, сколько памяти у него в карте
Смущает арифметика вокруг 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 сколько раз пытался запустить локальную модель (любую), но всегда либо какие-то зависания происходят + эффективность работы с локальной моделью, как по мне, намного ниже с любой бесплатной облачной
С 8gb vram гоняю Qwen 3.6 35B-A3B от unsloth. Скорость хорошая, зависаний нет. Где-то 20-30t/s. Облачные эффективнее конечно, особенно если подписку купить. Но небольшие повседневные задачи способно и такое железо закрыть. У вас ещё не самый худший вариант и на 6gb запускают.
Руками запускал? У меня руками тоже не получалось. А Claude Code легко мне ставил разные модели.
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. В этом кайф нграм таблицы. Автор вообще не понял, что это и как с этим жить. Статья, мягко говоря, нуждается в полной переработке.
Что за мода пошла на теоретические проекты с нейрослопными статьями?
То 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,
Ну т.е. пока что это все находится за пределами юзаельности.
Вроде суть в том, что спекулятивное декодирование с ngram таблицами не требуют инференса, поэтому оно быстрое и нормально работает с nvme, но чаще ошибается. Если ошибок сильно много - скорость проведает потому что валидация спекулятивного декодирования требует инференса большой модели.
С этим квеном есть другая большая проблема. Это ооочень медленный префил. На RTX 3060 при квантовке q4 префил где-то в диапазоне 50-100 токенов. Генерация с MTP - где-то 12-15 токенов.
И как будто эта модель сильно умнее. По крайней мере если я прошу отрисовать анимацию или презентацию оформить - намного лучше прошлых квенов. Но для агентских сценариев всё равно qwen 3.6 лучше. Причём выбирая между q4 и q8 я чаще выбираю первый тупо из-за скорости префила. У q8 - 400 токенов, у q4 - 1000 токенов. А их qwen 4 экспериментальный 50-100... Здесь вообще без комментариев.
конечно быстрее, каждое обращение на чтение случайного блока с ССД это огромные задержки, если модель вся в оперативе, то там некоторые MoE модели даже без gpu,
чисто на процессоре и оперативке, получить токенов больше чем в этом методе, где куча обращений к диску
Смотря какой fabric, сколько details.
Когда-то давно, в прошлом веке, шахматная программа работала только на суперкомпьютере. Но в принципе запускать некоторые из таких программ можно было и на РС. Правда, работали они... небыстро. Можно - но зачем?
А затем (прошу прощения за каламбур) мощность настольных компов подросла, памяти стало побольше, а шахматные программы стали сильно шустрее (на таком же самом компе и на том же уровне игры) и требовали сильно меньше памяти. Теперь они и в телефоне могут работать - без интернета в том числе.
Как сие чудо стало возможным? Ответ - пришло новое знание и появились новые алгоритмы, которые сие знание использовали.
Думаю, и здесь будет нечто похожее. Производительность чуток подрастет, но главное - появится новое знание, как делать плюс-минус то же самое (или лучше) с меньшими затратами токенов - или же вообще без таковых (сие пока что не очень известно). И в какой-то момент иишку можно будет реально запустить на настольном компе - как шахматы.
Kimi K3 показала, что большие MoE-модели можно запускать иначе, если стримить experts. Для Qwen3.8-27B аналогичный подход сделал интереснее локальный запуск более традиционной модели.
И что же Kimi K3 показала? Запуск MoE с офлоадингом был возможен и тестировался задолго до K3, ничего особенного в этой модели нет, вопрос в софте. "Для Qwen3.8-27B аналогичный подход" - какой н.... аналогичный подход? Это не MoE, все веса учавствуют в вычислениях.
полный checkpoint в bf16 около 360 ГБ;
Зачем? Просто зачем? Если это nvidia - NVFP4, если нет - UD-Q4, смысл от минимального повышения качества ценой в 4 раза меньшей генерации?
FP16 используют в датацентрах не потому, что это самый экономный и правильный вариант, а для того, что бы не тратить время на реквант на лету, отбирая немного мощности GPU. При параллельной обработке запросов то, что FP16 требует большей пропускной способности памяти и в итоге медленее компенсируется тем, что за раз можно десятки запросов без потери производительности прогнать. Вряд ли кто-то локально одновременно десяток агентов запускает.
В чем смысл статьи вообще? Нет даже теоретического рассчета того, какая скорость возможна на потребительском железе. Если 125B помещаются в ОЗУ (при UD-Q4_K_XL это ~60 Гб, оставшиеся 4 под систему), ngram офлодятся на SSD, при PCIe4x16 максимум 32 Гб/с теоритический предел 10 токенов/с + можно MTP или dflash2 разогнать до 15-30 в зависимости от задачи. Для PCIe5x16 это в 2 раза больше соответственно. Это чисто теоретические значения при отсутствии задержек вычислений, в реальности будет на 30-40% медленее.
Из того, что у меня получилось - на Q4_K_XL CPU only с памятью 100 Гб/с на 96 Гб ОЗУ скорость генерации без MTP - ~7-8т/с, с MTP до 10т/с, т.к. процессор медленный и накладные расходы на драфтер гробят скорость.
Если так уже хочется локально модели запускать - надо либо с унифицированной памятью MoE запускать (128 Гб 200 Гб/с+), либо dense но полностью в GPU (минимум 16, норм 24, комфортно 32Гб VRAM).
Можно запустить в формате CMF https://huggingface.co/infosave/Qwen3.8-Flash-Next-cmf как раз на небольшой VRAM
Интересно, а риг на кучу старых карт на 8-16ГБ со связанностью через PCI-e даст норм перф, если все слои зайдут в VRAM?
Или на передаче текущего контекста между картами ляжет, и будет простой вычислительных ядер?
Зависит от режима запуска. В llama.cpp если выбрать режим layer, то слои модели разделятся по видеокартам и будут обрабатываться последовательно, при этом по шине PCIE будет передаваться минимум информации. Производительность будет ограничена скоростью одного GPU, но за счёт суммарной VRAM вы сможете запускать большие модели на приемлемой скорости. А при запуске в режиме tensor все GPU работают одновременно и по шине передается большой объем информации и она становится узким местом.
Так а в чем затык? Оно ещё и конвеером заработает, чтобы, пока GPU2 считает первый батч, то GPU1 уже работает над вторым, чтобы утилизация ресурса была высокой? Звучит, как священный грааль, обесценивающий разницу между 5090 и серьёзными системами системами за все деньги мира, обладающими большим количеством памяти на каждом отдельном чипе и высокой скоростью передачи данных между чипами.
Хуанг, не прячься. Мы тебя узнали. Кто ещё будет продвигать свои ущербные 8гб видеокарты?
никто не обращает внимание на тупость тренировки современных moe, хотя ресерчеры получают мильоны. если их тренировать оптимально то один-два мое-куска ДОЛЖНЫ решать конкретную задачу без (пере)загрузки других мое-кусков. А сейчас 'знания' размазаны по всем экспертам . пока ресерчеры не додумаются что знания должны быть жестко и плотно гранулированы, нам будут нужны сотни гигов VRAM вместо десятка.
Как запустить Qwen3.8-Flash-Next 125B на 6 ГБ VRAM