Comments 28
Статья классная, хотя лично я не понял и половину из написанного.
По чистой GPU-производительности это что-то между RTX 5070 и 5070 Ti. Сенсация не в FLOPs, а именно в 128 ГБ unified memory: на одной коробке за $4 тысячи я могу инферить 70B-модель в FP4 без всякого шардирования, чего на потребительском железе обычно не сделать.
Только это 128 ГБ обычной оперативной памяти LPDDR5x, не HBM (High Bandwidth Memory), поэтому то, что она unified memory, вряд ли сделает подсистему памяти быстрее, чем можно получить в потребительском сегменте.
Иными словами, возможно было бы проще взять потребительское железо, набить его ОЗУ нужного объёма и поставить туда RTX 5080 или RTX 3090\4090\5090 и получить больше производительности за меньшие деньги.
Учитывая количество найденных вами в Spark проблем, вариант собрать что-то своё уже не кажется таким уж плохим. Как минимум, в самостоятельной сборке больше свободы и нет вендор лока, а также можно легко поменять стек технологий на другой. Здесь же в Spark будет работать только то, что совместимо с этим Spark и его arm ядрами.
проще взять потребительское железо, набить его ОЗУ нужного объёма и поставить туда RTX 5080 или RTX 3090\4090\5090 и получить больше производительности за меньшие деньги
И это будет всё ещё "небольшая золотистая коробочка размером чуть больше Mac mini"? Потому что автор акцент на форм-факторе ставит буквально в первом же предложении.
На обычном компе у вас будет между памятью и GPU pcie5x16 - 64 GB /s .
Инференс LLM'ок в части генерации токенов упирается в пропускную способность памяти. PCIe 5.0 x16 отстает в ~4 раза, обычный потребительский CPU с iGPU + DDR5 ~2.5 раза. Серверные решения с более чем 2 каналами для RAM и нормальной встройкой, либо пачка видеокарт, либо одна мощная серверная карта - это либо дорого по стоимости, либо шумно (на уровне пылесоса на полной мощности), либо ест как обогреватель, либо все вместе.
Короче, по крайней мере для домашнего запуска больших MoE LLM подобные миники оправданы
Совсем другой вопрос - зачем вообще брать Spark от Nvidia, когда есть практически такой же Strix Halo от AMD , который стоит в 2-3 раза меньше, да ещё и сделан на x86, а не ARM, т.е. обычный ПК на котором без танцев запустится любой десктопный софт. А на разницу можно купить остальное рабочее место со всей мебелью, периферией и топовый GPU от той же Nvidia для не LLMных задач, подключив его через OCuLink или USB4.
P.s. Судя по текущим ценам в наших магазинах, маркетплейсах и на AliExpress, сейчас худшее время для покупки и того, и другого
Дополнительно отмечу, что на PRO Hi-Tech относительно недавно было тестирование Nvidia DGX Spark и какого-то феноменального преимущества его перед другим железом в работе с ИИ я не увидел. https://www.youtube.com/watch?v=lLG-xN25v20
Но сама железка DGX Spark хороша, как и концепция иметь полноценный локальный ИИ в маленькой коробочке. Жаль только что DGX Spark - это очень нишевое решение, поэтому цена на его неадекватно высокая.
google/gemma-4-26B-A4B-it - для этого с избытком хватит rtx 3090 с 24 Gb VRAM. С вашими 128 Gb вы могли позволить себе гораздо больше. Сложно сказать, но имхо, всё, что вы развернули, работало бы на значительно более сромном компе. Выглядит как недоиспользование возможностей. А ещё не расширяемое решение.
но спасибо за то, что поделились опытом
Он делает тебя быстрее в том, в чём ты уже хоть как-то разбираешься
не совсем так. Я как не разбирался в асинхронном программировании, так и не разбираюсь и уже не буду. Но ИИ пишет мне асинхронный код, и всё прекрасно работает. Достаточно просто сказать "а теперь перепиши все вызовы АПИ на асинхронное выполнение"
накатать тысячу строк bash с идемпотентным wizard’ом
Может, я чего-то не понимаю, но например… ansible.
Не самое адекватное решение для инференса.
За эти деньги надо покупать мак студию м3 ультра с 800+Гб/сек скоростью памяти, и получить в 3-4 раза большую скорость инференса.
Спарк вообще странное нишевое устройство из за медленной памяти.
Это хороший "ардуино" для богатых поиграться в обучение маленьких моделек, но как девайс для инференса ну такое.
Мак м3 ультра дает существенный прирост и потолок до 512 Гб? но дороже, а м4 макс с 128 Гб рам на 500 Гб/сек (а у спарка 200) обойдется в 3500$ в штатах и уже в 2+ раза уделывает спарк. Дешевле и быстрее, минус - без куды, но оно вам и не надо если вам только ллм гонять.
В целом согласен, только с некоторыми плясками с бубном потолок на м3 ультра расширяется до 4 х 512Гб в rdma через thunderbolt 5. Такой сетап позволяет гонять все актуальные sota llm модели в mxfp8 квантизации на текущий день. Префилл слегка тормознутый, генерация в районе 20-40 токенов в секунду, параллельный батчинг тоже возможен со своими ограничениями.
Из минусов - 512гб модель снята с производства, софт чтобы это запустить в кластере имеет свои приколы, но в целом решение рабочее.
Даже м5 макс 128 gb даст на qwen3.6-27b всего около 20 токенов, что на грани юзабельности
чёта маловато вроде. rtx 3090 при 24Гб выдаёт около 40 токенов в секунду на этом квене. Это при том, что там обмен данными процессора с памятью жутко тормозной по сравнению с маком. Почему на маке так медленно?
Этот квен расколол мир локальных ллмок ) До него все целились в жирные MoE модели и нужно было много памяти и пофигу что компьют слабоват, а теперь появились реально хорошие Dense модели которым много памяти не нужно, зато нужен мощный компьют
Наоборот
qwen3.6-27b
3090 - 35.58 TFLOPS - 40 t/s
5070Ti - 43.94 TFLOPS - 5 t/s
Да, ошибся в формулировках. Имел ввиду что много памяти не нужно, но нужна быстрая память что бы был хороший tg.
У 5070 и 3090 вроде ПCП примерно на одном уровне? Почему tg всего 5?
Потому что 16 гб против 24. Для этой модели с адекватным квантованием это как раз критично. Q4-K-M займет 18-19 гигов + контекст.
Спасибо за статью! Вы проделали огромную работу.
DGX Spark не заточены на инференс, там приемлемо работают модели с квантизацией Q4, т. к. NPU модули хорошо обрабатывают float4. В паре два спарка работают хорошо, когда на одном веса, на другом Kv-cashe. На реддите есть обзоры где запускают на паре спарков модели по 130Млрд.параметров Q4.
Спарки заточены на обучение моделей до 8 млрд. параметров. Вот тут они очень хороши! Когда быстро надо проверить гипотезу при обучении, собрать мини модель, обкатать А/В тестами, и потом можно транспонировать на большую модель код.
Или же фантюнинг открытых моделей, когда прикручиваем свой уникальный слой в веса, например QLora.
У меня аналог Asus Ascent GX10. Я использую под обучение своих моделей. К примеру модель на 4млрд. параметров с 10-тью MoE экспертами обучается за 20 часов. Все дело в размере VRAM, на обычной Rtx 5090 с 32 Gb формально возможно обучение, но это заняло бы месяц, а то и два.
Делюсь своим экспериментом на спарке, эта же модель но в nvfp4, общая генерация от количества потоков
1 - 45 t/s
3 -100
5 -135
10 -165
24 -280
50 -420
Префилл - 6k t/s независимо от количества потоков
А почему именно Gemma-4-26b? Так-то на Спарке можно запустить MiniMax m2.7, 4-бита с контекстом 196k, и похожей скоростью генерации токенов, а это уже совсем другая весовая категория. https://forums.developer.nvidia.com/t/minimax-m2-7-nfvp4-recipe-benchmarks/366324
А на двух в кластере уже должен запуститься DeepSeek-4 flash, тк он из коробки 160Гб.
Можно подключить более двух dgx spark через switch Connect Multiple DGX Spark through a Switch | DGX Spark https://build.nvidia.com/spark/multi-sparks-through-switch, и получить больше памяти, тогда станет возможным запускать модели типа Kimi на триллион параметров
Похожая задача: законы -> SQL базу.
HITL, OCR, SQL.
Базовая ветка v0.24.0 + патчи Hendrik: cascade-OCR на Latin / Cyrillic / Chinese (важно — в upstream был только английский), file metadata в ES-чанках, поддержка AVIF, фиксы IMAP и WebDAV mtime ...
...
Docling — парсер документов с GPU OCR
Docling-serve (docling-serve-cu130:v1.16.1) — это GPU-ускоренный конвертер документов от IBM. Принимает PDF / DOCX / PPTX / XLSX, отдаёт Markdown с сохранённой структурой таблиц, заголовками и описаниями картинок.
Зачем два OCR-движка (cascade-OCR, Docling)?
Я только знакомлюсь с темой, могу недопонимать базовые вещи.
Делали ли анализ существующих OCR-движков и есть ли результаты анализа?
Аналогичный вопрос по Dify: сравнивали с n8n и другими похожими продуктами?
Зачем два OCR-движка (cascade-OCR, Docling)?
Они закрывают разные задачи и стоят в разных пайплайнах, не дублируют друг друга.
Docling — это парсер документов в первую очередь, OCR у него вторичен. Его сильная сторона — PDF/DOCX/PPTX/XLSX → Markdown с сохранением структуры таблиц, заголовков, списков. Для нативно-текстовых документов он почти не использует OCR — вытаскивает текстовый слой напрямую. OCR (через EasyOCR с cyrillic_g2) включается только когда страница оказывается отсканированной. Стоит в Dify-пайплайне, потому что в Dify нативно нет хорошего парсера документов.
RAGFlow cascade-OCR — это не один движок, а каскад из ONNX-моделей под Latin / Cyrillic / Chinese. Используется внутри RAGFlow для специализированных режимов чанкинга (naive / book / laws / paper), где важна именно скан-обработка с распознаванием layout. В апстриме RAGFlow до Hendrik-патча был только английский; ради кириллицы приходится держать его форк.
То есть Docling — для «чистых» документов с текстовым слоем (договоры, выгрузки), RAGFlow с cascade-OCR — для скан-PDF с layout-распознаванием. Решение, какой пайплайн использовать, остаётся за оператором: можно загружать в Dify (Docling) либо в RAGFlow напрямую.
Делали ли анализ существующих OCR-движков?
Да, проверяли несколько вариантов:
Tesseract — отбросили: медленный на скан-PDF и плохо держит таблицы.
EasyOCR — оставили, но только как backend внутри Docling для кириллицы (
cyrillic_g2.pth).MinerU 2.5-Pro — делали полноценный сравнительный замер с Docling. На реальном parallel-батче из 4 PDF Docling отработал за ~5 минут, MinerU — больше 12. Плюс AGPL-лицензия и отсутствие готового arm64-билда под GB10 — для нашей платформы это блокеры. Отказались.
Marker — оставили как теоретический fallback на случай, если попадётся клиент с критичными таблицами в скане. Пока не понадобился.
RAGFlow cascade-OCR (Hendrik fork) — взят целиком вместе с RAGFlow для скан-сценариев, потому что внутри уже есть мультиязычные ONNX-модели и интеграция с layout-detection.
Универсального «лучшего» движка нет — на текстовых PDF быстрее всего читать текстовый слой напрямую (что делает Docling), на сканах с таблицами выигрывает связка layout-detection + OCR (что делает RAGFlow).
Аналогичный вопрос по Dify: сравнивали с n8n и другими похожими продуктами?
Сравнивали. Они закрывают разные ниши, и формально это не конкуренты:
Dify — заточен под LLM-workflows: RAG, knowledge base, prompt-цепочки, агенты с инструментами, multi-step reasoning. Сильная сторона — abstraction над LLM-провайдерами, нативный chunker, knowledge-index ноды. Слабая — cron, webhooks, retry / error paths, интеграции с внешними системами через коннекторы.
n8n — заточен под интеграции: 400+ коннекторов, cron-триггеры, webhook-эндпоинты, retry-политики, error-routing. Слабая сторона — собственно LLM-логика (всё, что сложнее «вызови OpenAI», приходится писать руками в Code-нодах).
Langflow / Flowise — пробовали, по сути упрощённые Dify. Уступают в production-зрелости (плагины, sandbox, multi-tenant).
В AGmind сейчас стоит Dify, но n8n в бэклоге как опциональный compose-profile — для cron-задач и нестандартных интеграций, где Dify слабоват. Это не «или Dify или n8n», скорее «Dify для LLM-логики + n8n для оркестрации поверх».
Если задача из стартовой реплики — «законы → SQL» с HITL и OCR, то типичный layout получается такой: RAGFlow (cascade-OCR + laws chunker) → выгрузка структурированных полей в Postgres → Dify-workflow для запросов / валидации / HITL-аппрува. n8n в этом сценарии не обязателен, но удобен если документы прилетают по расписанию из внешних источников.
Как я собрал на DGX Spark приватный AI-сервер, и теперь рассказываю, что туда вошло