Спасибо, полезно. От себя добавлю плюс n8n, который часто недооценивают: он одинаково хорош и как главный оркестратор, и как одна нода внутри другого. У нас, например, RAG крутится на Dify, а n8n там дёргается HTTP-нодой на cron, вебхуки и склейку API. От задачи зависит — в обе стороны нормально.
Ну и WEBHOOK_URL=localhost:5678 — классика, все через неё проходили :)
Про «9 месяцев назад»: тема — токенизация, а не рейтинг моделей за текущий месяц. Чекпойнты меняются ежемесячно, BPE-вокабы — почти никогда. Цифры по o200k_base / cl100k / Llama 3 / Qwen 3 актуальны независимо от того, вышла ли новая версия модели. Gemma 3 — да, в таблицу просилась; повторюсь, статья не про рейтинг моделей, а про то, как токенайзеры режут кириллицу, и выводы от этого не меняются.
Так оно квантовано — пять из шести конфигов. Gemma BF16 одна осталась стоковой как baseline, и даже у неё KV cache в FP8 (без этого 252K не поднялся бы в 128 GB).
Остальные: Qwen3.6-FP8, NVFP4 на 4 битах, AEON-7 тоже NVFP4. KV cache везде FP8. Дальше квантовать в Q3 — уже бьёт по качеству, на 35B-MoE особенно.
Про GGUF — vLLM формат читает, но сами разработчики в доке пишут "highly experimental and under-optimized, may not be compatible with other features". Для одиночного юзера локально llama.cpp с GGUF — вполне рабочий путь (форумные замеры на Qwen3-30B-A3B Q4_K_M порядка 80-90 tok/s single-stream). У нас серверная нагрузка с Dify и concurrency, там vLLM с paged attention и continuous batching в разы выгоднее.
llama.cpp хорош для одиночного инференса, а мне здесь нужен именно продакшн‑сервер под несколько клиентов. Для этого vLLM с его шедулером, KV‑кэшем и API даёт больше профита, чем голая скорость одного потока. Спасибо за идею с llama.cpp — в одной из следующих статей как раз попробую сравнить оба подхода на таком железе.
Имея живой опыт работы на GB10, я бы всё‑таки рекомендовал смотреть на решения на базе Strix Halo. По скорости в типичных LLM/ML‑нагрузках разница не драматическая, зато классический x86 даёт предсказуемое поведение, нормальную совместимость с экосистемой и сильно меньше возни с портированием
ASCII-кавычки тут функциональные: ими в IT-текстах выделяют термины как объекты рассмотрения (mention), ёлочки — для цитат и прямой речи. П.5 чек-листа — про выходной текст модели в продакшене для конечного пользователя, а не про авторский разбор. У этих регистров разные правила пунктуации — собственно, статья ровно об этом столкновении и есть.
В статье как раз разобран o200k_base — это семейство GPT-4o / GPT-4o-mini / GPT-4 Turbo (4660 кириллических токенов в словаре против 435 у cl100k_base).
GPT-5 использует ровно тот же o200k_base — явно прописано в openai/tiktoken (model.py: “gpt-5”: “o200k_base”). Всё что в статье сказано про эффективность o200k_base на кириллице относится и к нему: отдельно выделять смысла не было, по контентному вокабу разницы нет.
По GPT-5.5 OpenAI отдельно спеки токенайзера не публиковали, в tiktoken на май 2026 явной записи нет. Если есть замер на 5.5 на сопоставимом корпусе — поделитесь, добавлю.
Про «двухлетней давности»: в статье разобрана Llama 4, рекомендованы Qwen 3 и YandexGPT — это всё 2025–2026.
Они закрывают разные задачи и стоят в разных пайплайнах, не дублируют друг друга.
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 в этом сценарии не обязателен, но удобен если документы прилетают по расписанию из внешних источников.
Спасибо, полезно. От себя добавлю плюс n8n, который часто недооценивают: он одинаково хорош и как главный оркестратор, и как одна нода внутри другого. У нас, например, RAG крутится на Dify, а n8n там дёргается HTTP-нодой на cron, вебхуки и склейку API. От задачи зависит — в обе стороны нормально.
Ну и
WEBHOOK_URL=localhost:5678— классика, все через неё проходили :)На английском вышло бы в полтора раза дешевле, да. Но аудитория тут другая — пришлось переплатить токенами.
Про «9 месяцев назад»: тема — токенизация, а не рейтинг моделей за текущий месяц. Чекпойнты меняются ежемесячно, BPE-вокабы — почти никогда. Цифры по o200k_base / cl100k / Llama 3 / Qwen 3 актуальны независимо от того, вышла ли новая версия модели. Gemma 3 — да, в таблицу просилась; повторюсь, статья не про рейтинг моделей, а про то, как токенайзеры режут кириллицу, и выводы от этого не меняются.
Так оно квантовано — пять из шести конфигов. Gemma BF16 одна осталась стоковой как baseline, и даже у неё KV cache в FP8 (без этого 252K не поднялся бы в 128 GB).
Остальные: Qwen3.6-FP8, NVFP4 на 4 битах, AEON-7 тоже NVFP4. KV cache везде FP8. Дальше квантовать в Q3 — уже бьёт по качеству, на 35B-MoE особенно.
Про GGUF — vLLM формат читает, но сами разработчики в доке пишут "highly experimental and under-optimized, may not be compatible with other features". Для одиночного юзера локально llama.cpp с GGUF — вполне рабочий путь (форумные замеры на Qwen3-30B-A3B Q4_K_M порядка 80-90 tok/s single-stream). У нас серверная нагрузка с Dify и concurrency, там vLLM с paged attention и continuous batching в разы выгоднее.
я жду Beelink GTR9 Pro AI Max+ 395 , спарк отлично подходит под дообучение - под инференс это танцы с бубном)
llama.cpp хорош для одиночного инференса, а мне здесь нужен именно продакшн‑сервер под несколько клиентов. Для этого vLLM с его шедулером, KV‑кэшем и API даёт больше профита, чем голая скорость одного потока. Спасибо за идею с llama.cpp — в одной из следующих статей как раз попробую сравнить оба подхода на таком железе.
Имея живой опыт работы на GB10, я бы всё‑таки рекомендовал смотреть на решения на базе Strix Halo. По скорости в типичных LLM/ML‑нагрузках разница не драматическая, зато классический x86 даёт предсказуемое поведение, нормальную совместимость с экосистемой и сильно меньше возни с портированием
ASCII-кавычки тут функциональные: ими в IT-текстах выделяют термины как объекты рассмотрения (mention), ёлочки — для цитат и прямой речи. П.5 чек-листа — про выходной текст модели в продакшене для конечного пользователя, а не про авторский разбор. У этих регистров разные правила пунктуации — собственно, статья ровно об этом столкновении и есть.
В статье как раз разобран o200k_base — это семейство GPT-4o / GPT-4o-mini / GPT-4 Turbo (4660 кириллических токенов в словаре против 435 у cl100k_base).
GPT-5 использует ровно тот же o200k_base — явно прописано в openai/tiktoken (model.py: “gpt-5”: “o200k_base”). Всё что в статье сказано про эффективность o200k_base на кириллице относится и к нему: отдельно выделять смысла не было, по контентному вокабу разницы нет.
По GPT-5.5 OpenAI отдельно спеки токенайзера не публиковали, в tiktoken на май 2026 явной записи нет. Если есть замер на 5.5 на сопоставимом корпусе — поделитесь, добавлю.
Про «двухлетней давности»: в статье разобрана Llama 4, рекомендованы Qwen 3 и YandexGPT — это всё 2025–2026.
Они закрывают разные задачи и стоят в разных пайплайнах, не дублируют друг друга.
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 напрямую.
Да, проверяли несколько вариантов:
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 — заточен под 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 +
lawschunker) → выгрузка структурированных полей в Postgres → Dify-workflow для запросов / валидации / HITL-аппрува. n8n в этом сценарии не обязателен, но удобен если документы прилетают по расписанию из внешних источников.gemma-4-26B-A4B-it на 3090 не потянет контекст 128к)
хорошо что вообще есть звонки )))