TL;DR

Железо: 2× NVIDIA DGX Spark (GB10, SM121), 128 GB unified номинально и около 122 GiB видимых системе на ноду, QSFP 200G / RoCEv2, TP=2, драйвер 580.159.03.

Основную часть расхождения объяснила смена runtime‑образа. Переход со сборки на базе vLLM 0.21.1 на образ с 0.25.2 дал около +22% на том же чекпоинте. Конкретный коммит или компонент я не изолировал: поменялся весь пакет.

Механика неочевидная: новый образ снизил расчётную частоту verification‑шагов примерно на 17%, но поднял число выходных токенов за шаг с 3.27 до 4.80.

Главная находка в конфиге: --moe-backend flashinfer_b12x не выбирается режимом auto. Явное включение дало +13.3% по среднему пяти прогонов на card‑like профиле (59.7 против 67.6) и +16.6% по медиане.

B12X работает иначе: поднимает SSE‑derived частоту verification‑шагов на 16–18%, при этом выходные токены за шаг снижаются примерно на 2.5% в обоих профилях. Итоговый прирост клиентской decode‑метрики составил 13.3–14.6% по средним и 15.6–16.6% по медианам.

Итог: 67.6 tok/s на одиночном запросе, 260 tok/s суммарно на 12 параллельных запросов.

Отрицательные результаты, погрешности и границы применимости вынесены в отдельные разделы.

TL;DR. У меня локальный RAG на AMD Strix Halo. Памяти там достаточно, но вычислительно всё упирается в один iGPU: его делят эмбеддер, реранкер и периодическая переиндексация, а в одноузловой конфигурации туда же встаёт генеративная LLM. Поэтому мне понадобился не самый точный retriever вообще, а максимально лёгкий русский retriever, который быстрее завершает первую стадию поиска на том же GPU. Насколько это больно, я в итоге померил на живом узле.

На синтетической индексирующей нагрузке полной тяги bge‑m3 снизил generation throughput Qwen3.6-35B-A3B на 92%, STRIZH на 28% при примерно 12,6-кратном темпе индексации (окна замера там неравные, 20,6 против 173,6 секунды, потому что задаются временем пяти генераций; равнооконный прогон RAG‑конвейера ниже даёт по батчам в секунду 9,4-кратный отрыв). В полном RAG‑конвейере с четырьмя пользовательскими потоками и фоновой индексацией STRIZH удержал 14,0 транзакции в минуту против 6,0 у bge‑m3 и индексировал 46 батчей в секунду против 4,9. При фиксированных 200 онлайн‑запросах в секунду генерация проседала на 2% со STRIZH и на 7% с bge‑m3. Оговорка сразу: без фоновой индексации STRIZH преимущества не показал: в этом профиле bge‑m3 оказался немного быстрее, а пропускную способность определяли реранк (0,6–0,7 с на транзакцию), prefill и генерация.

Я взял 12-слойный RuModernBERT-small, сначала неудачно попытался повторить пространство большого учителя через MSE, затем обучил retrieval‑донор на контрастивной задаче, выбрал из него четыре слоя [0, 5, 9, 11] и доучил student на русских, английских и смешанных парах с hard negatives от BGE‑M3.

Один Beelink GTR9 Pro на Ryzen AI Max+ 395 выдал 236 tok/s суммарной генерации на 32 одновременных запросах в коротких прогонах и удержал в среднем 226 tok/s за 30 минут непрерывной нагрузки без тротлинга. По дороге к этим числам я нашёл воспроизводимый провал пропускной способности, который сначала выглядел свойством одной модели, увидел, как спекулятивный декодинг на моём стеке превращается из ускорителя в налог, и трижды чуть не опубликовал неверные выводы. Каждый раз спасали контрольные замеры, все три истории здесь, в статье.

Харнессы, конфиги, полные таблицы, значения по каждому ключевому и финальному прогону, поминутные ряды выносливости и телеметрия лежат в открытом репозитории. Логи отдельных запросов харнесс не вёл, поэтому пересчитать можно всё до уровня прогона, но не глубже. Числа сняты на одном конкретном стенде; что из этого переносится на другие стеки, а что нет, оговорено по ходу текста.

На узле моей AI‑платформы крутятся 34 контейнера: Dify, RAGFlow, векторные базы, мониторинг и SSO. Большой языковой модели среди них нет: основную генерацию стек получает по LAN с DGX Spark. На втором таком же мини‑ПК я отдельно поднял локальную Qwen3.6–35B‑A3B и прогнал серию замеров от 1K до 64K при контекстном окне 256K.

Обе машины — Beelink GTR9 Pro на Ryzen AI Max+ 395 (Strix Halo). Ниже — что эти коробки реально умеют: 117,4 ГиБ GTT после настройки ttm.pages_limit, p50/p95 локальных эмбеддингов и реранка, около 70 tok/s генерации через Vulkan/RADV и три грабли gfx1151.

DeepSeek выпустил DSpark — спекулятивный декодер для V4. В окне 27–30 июня 2026 рабочего публичного пути для GB10 не было — мы портировали его сами, нашли унаследованный баг, убивавший качество драфта, и сняли профиль своего стенда. Потом комьюнити выложило рецепт вдвое быстрее нашего. Мы его воспроизвели — и вместо гонки за цифрой сняли данные, которых в паблике не нашли: кривую деградации до реального 1M, механизм выигрыша NVFP4 и петли когерентности на глубине. Плюс три негативных результата.

TL;DR. Из интереса обучил собственный русский RAG‑сплиттер — захотелось проверить, можно ли сделать context‑aware‑нарезку русских документов лучше готовых чанкеров.

Я взял идею датской context-aware-splitter, пересобрал её под русский на базе T-lite-it-2.1 и изменил главное: модель возвращает индексы границ, а не переписанный текст. Хост потом режет оригинал по этим индексам.

У index‑output оказалось три практических плюса:

Подняли DeepSeek‑V4‑Flash на двух GB10, упёрлись в потолок consumer Blackwell, прошли три тупика со спекулятивным декодингом — и в итоге получили параллельную работу ресёрч-агента и длинной генерации без очереди. Цифры из Grafana.

NVIDIA продаёт спарку с лозунгом «один петафлоп на FP4». Я купил коробку, поставил vLLM, запустил инференс и получил 40 токенов в секунду на 35B MoE‑модели. После маркетинговых слайдов цифра выглядит грустно.

Объяснение простое. NVFP4 в основной ветке vLLM и FlashInfer физически сломан на SM_121 — варианте Blackwell, который установлен в GB10. Ядра собраны под compute_120f, а нативные NVFP4-инструкции есть только в compute_120a и compute_121a. На SM_121 распаковка квантованных весов идёт через программные битовые манипуляции в шейдере, без участия тензорных ядер.

Сообщество вытащило стек руками: нашло обходные пути, собрало рабочие конфигурации. Я прогнал на своём Spark шесть разных конфигураций vLLM — от стокового BF16 до форка с DFlash speculative decoding — и замерил каждую одинаковым тестом. В этой статье разбираю, что в итоге работает и что выбирать под разные задачи.

Когда вы пишете запрос в ChatGPT или другую нейросеть, она не работает с буквами или словами — она режет ваш текст на маленькие кусочки. Эти кусочки называются токенами, и от того, как именно нейросеть режет текст, зависит цена ответа, скорость, и сколько информации в неё помещается за раз. С английским это работает хорошо: одно слово — обычно один‑два кусочка. С русским всё хуже: то же самое слово часто превращается в три‑четыре обрывка. Английское «contract» — один токен. Русское «разработка» — два‑три. «Программирование» — три‑четыре.

Из‑за этого русский текст в облачных сервисах вроде OpenAI обходится примерно в 2 раза дороже английского, медленнее обрабатывается, и в одно «контекстное окно» нейросети помещается заметно меньше реального содержания. Эта статья — про то, откуда берётся разница, как её измерить на ваших данных и какие модели лучше работают с русским языком.

Свежепоставленный мониторинг на DGX Spark. Открываю NVIDIA‑дашборд в Grafana — половина memory‑панелей пустые, прямые линии по нулю. Сначала кажется, что что‑то не настроил. Через полчаса доходит: это не у меня сломалось, это NVML на GB10 так работает.

Это та область, где на GB10 половина стандартного observability‑стека просто не работает: NVML отдаёт [N/A] на memory.used и memory.total, dcgm‑exporter не ставится, nvtop в memory‑колонке показывает пустоту. В Grafana NVIDIA‑дашборды по умолчанию выглядят так, будто GPU вообще нет — и это не очевидно, потому что Grafana при отсутствии данных не кричит, а молча рисует ровную линию по нулю.

Статья — про то, как я это место обошёл и что в итоге увидел в Grafana. Трёхуровневая схема: textfile collector для базовых метрик, per‑container attribution через docker top + nvidia-smi, и CLI‑фоллбэк на /proc/meminfo, который оказался полезен не только на Spark, но и на других Linux‑системах с единой памятью (unified memory) — AMD Strix Halo и подобные.

У меня на столе стоит небольшая золотистая коробочка размером чуть больше Mac mini. Внутри — приватный AI-сервер: чат с локальной 26B-моделью, поисковая индексация моих документов с GPU-парсингом, конструктор агентов в Dify, RAGFlow для тяжёлого парсинга PDF, мониторинг, бэкапы, опциональный кластер из двух машин по QSFP 200G. Тридцать контейнеров, пять минут на установку через sudo bash install.sh, ноль обращений к внешним API.

Я делал это не как pet-project, а под себя — мне нужна была машина для работы с корпоративными документами, договорами и регламентами, которые ни при каких условиях нельзя отдавать в облачные ассистенты. Сборка получилась самостоятельным дистрибутивом — назвал его AGmind, выложил на GitHub под Apache 2.0.

В статье разберу:

— из чего собран стек и зачем там каждый компонент; — почему RAGFlow пришлось пересобрать с нуля и что я туда добавил; — как устроен кластер из двух Spark'ов; — пять конкретных грабель GB10, которые я ловил вечерами; — почему Claude Code за месяц превратил один из этих компонентов в работающий продукт, но при этом не заменил собственно программиста.