Комментарии 13
Интересно, а такое старое ядро Linux не тормозит ли всё шоу?
Замерил на 7.0.0-28. Генерация: Qwen на 8 клиентах 149 → 155, на 32 клиентах 160 → 159; Gemma на 32 клиентах 236 → 243. Embed 192 → 199 rps, rerank 7,0 → 7,3. Итого дельта ядра в пределах пары процентов, в рамках межпрогонного разброса, а провал на переходе через 8 одновременных запросов на новом ядре воспроизводится один в один. Сырые прогоны добавил в репо.
Гипотеза красивая, но wavefront на RDNA – это 32 или 64 потока, восьмёрка сюда не бьётся. Куда вероятнее, что дело не в диспетчере RADV, а на уровень выше – в непрерывном батчинге самого сервера: движок собирает decode-шаги в микробатчи и переразбивает KV-слоты, и как раз на 9–10 клиентах один слот остаётся недозаполненным. Проверяется быстро: если долина двигается при смене числа параллельных слотов в сервере, а не при смене драйвера – это точно не Vulkan.
Согласен, к wavefront восьмёрка не мапится, я и не привязывал долину к железу. Моя рабочая гипотеза программная: где-то в цепочке llama-server и Vulkan-бэкенда есть порог на размер decode-батча, за которым меняется путь исполнения (класс ядер или разбиение батча), и 8 одновременных генераций сидят по одну его сторону, а 10 по другую. В пользу софтового порога говорит и то, что обрыв идентичен у двух разных архитектур и трёх квантов, и то, что он не сдвинулся ни от смены ядра Linux, ни от типа KV, ни от батч-флагов. Ваша версия про KV-слоты тоже живая. Профилированием я это не добивал, в репо есть всё для воспроизведения, если захотите копнуть: обрыв ловится за один 75-секундный прогон.
Спасибо. История с реранкером ещё и самая дешёвая из всех: один запрос к /props вместо ребут-эксперимента, который я уже собирался делать. С тех пор сверяю эффективный конфиг, а не командную строку, везде.
«Потолки по-прежнему различаются на треть, 236 у Gemma против 178 у лучшего кванта Qwen».
Я тоже тестировал именно эти модели и столкнулся с тем, что tok/s здесь желательно сравнивать вместе с символами/с: у моделей разные токенизаторы и разный средний объём текста в одном токене. В моих тестах TTFT у Qwen часто был сопоставимым или даже ниже, хотя по tok/s он стабильно проигрывал. Поэтому разница в реальной скорости выдачи текста и пользовательской задержке может быть заметно меньше, чем следует из сравнения только токенов в секунду.
Справедливо. Внутримодельные сравнения статьи (долина, кванты, топология, MTP) от этого не зависят, там токенайзер один и тот же. А вот кросс-модельное 236 против 178 это токены родных токенайзеров, и в символах на русском разрыв может быть другим. Символы/с я не логировал, добавлю как ограничение в репозиторий. Спасибо.
8192 токенов контекста, очень реалистичный сценарий использования для каждого из 32 запросов
Так статья ровно это и говорит. 32 слота по 8К это режим коротких запросов: чат, агентные вызовы, батч-задачи. Для длинных промптов есть отдельный раздел с честными числами: уже на 3,4К токенов узел упирается в обработку промптов, и комфортная зона заканчивается на четырёх клиентах, а не тридцати двух. Никто не предлагает возить 32 RAG-сессии на одной коробке, замер показывает ровно обратное.
В подобных тестах всегда больше всего интересовал вопрос, для чего брать устройство на 128Гб памяти, и запускать там модели 27В в Q4? Если они отлично помещаются в 3090, будут работать быстрее намного, а сама система выйдет намного дешевле? На таких устройствах по уму надо запускать модели 120В+, где в кванте 4 вес модели будет около 70гб. Вот только даже для одного пользователя, скорость там выходит 10-15 ток/с.
это какие модели? сейчас qwen3.6 27b + её форки (прим. qwopus) самая лучшая среди всех что влезут в 128гб
Для одной 27B в Q4 хватило бы и 64. 128 работают на другое: в контеншен-тесте статьи одновременно жили генерация, эмбеддинги и реранкер, и GPU-маппинги занимали за 50 ГиБ вместе с KV-кэшами на 32 слота. Плюс два инстанса по 20 ГБ для топологических экспериментов, плюс запас под модели 70B+ класса, которые сюда влезают, но упрутся уже в полосу памяти, а не в объём. То есть 128 это не «одна модель побольше», а «стек целиком на одной коробке».

Мини‑ПК на Strix Halo под параллельной нагрузкой: 236 tok/s на 32 одновременных запросах и три ошибки