Визуально простая схема на канве Dify может запускать несколько обращений к модели за один пользовательский ввод. Ты видишь один блок с подписью LLM, а под ним скрывается цепочка: извлечение из базы знаний, память диалога, ещё один вызов на переформулировку. Каждое такое обращение стоит денег и может отказать. Схема без кода не перестаёт быть программой с состоянием, расходом и точками отказа.
Это статья-дневник сборки. Я не показываю готовую полную систему. Я показываю метод: как собрать одну ограниченную «канарейку» (минимальный workflow с урезанными ветками и памятью), как прочитать её журнал и как по этому журналу оценить расход до того, как ты развернёшь настоящую базу знаний. Цель узкая: понять цену и границы платформы раньше, чем на них наткнётся прод.
Одна деталь, которая экономит нервы с самого начала: модель за LLM-узлом не обязана быть встроенной в платформу. Провайдер отделён от канвы, и путаница между этими двумя слоями — частая причина, почему счёт за модель по ошибке приписывают самой Dify. Ниже я показываю, где именно проходит эта граница и как в неё вписывается совместимый провайдер вроде provod.ai.
Подключите AI-агентов с оплатой в рублях на provod.ai
Почему no-code workflow остаётся программой?
Спорное общее место звучит так: раз схема визуальная, инженерный контроль состояния и стоимости ей не нужен. На практике это неверно, и вот почему.
LLM-узел в Dify вызывает настроенную языковую модель на тексте, изображении или документе и умеет подтягивать контекст из извлечения по базе знаний и из многоходовой памяти. Это одноцелевой узел. Но chatflow или workflow спокойно связывает несколько LLM-узлов подряд, и тогда простая на вид канва прячет несколько последовательных обращений к модели (документация Dify по узлам, доступ 2026-07-18).
Отсюда рабочая гипотеза всего дневника: журнал одного запуска покажет, сколько именно вызовов и состояний порождает один пользовательский ввод в конкретной канарейке. Пока это не измерено на твоей схеме, это предположение, а не факт платформы. Задача канарейки как раз в том, чтобы превратить предположение в число, которое можно перепроверить.
Моя нормативная позиция здесь простая, и я подаю её как позицию, а не как рекомендацию Dify: сначала ограничь ветки и память, зафиксируй расход, и только потом расширяй сценарий. Обратный порядок, «сразу собрать всё», делает журнал нечитаемым: ты не понимаешь, какой из десяти узлов породил счёт.
Как ограничить канарейку по веткам и памяти?
Первое решение при сборке канарейки касается типа приложения: он определяет, есть ли вообще сквозная память. В Dify есть Conversation Variables: механизм состояния, которое живёт между ходами внутри одной сессии чата. Это не то же самое, что Workflow Variables, которые сбрасываются после каждого запуска. Переменные диалога пишутся и обновляются узлом Variable Assigner и поддерживают типы string, number, boolean, object и array с операциями под тип: например, append и extend для массивов, арифметика для чисел (документация Dify, доступ 2026-07-18).
Важная оговорка: Conversation Variables и Variable Assigner документированы в контексте Chatflow. Обычные Workflow-приложения не несут память уровня диалога так же. Значит, выбор между «Workflow» и «Chatflow» становится проектным решением, а не свойством платформы, и от него зависит, сохраняется ли состояние между ходами вообще. В канарейке я держу это состояние минимальным намеренно: один-два простых Conversation Variable, никаких вложенных объектов, никаких длинных массивов истории. Чем меньше памяти, тем короче журнал и яснее источник расхода.
Ограничение веток работает так же. Каждый узел условия и каждая параллельная ветка добавляют ещё один путь, по которому может уйти вызов модели. Богатый сценарий полезнее для пользователя, но дороже в контроле по расходу. Я принимаю этот компромисс осознанно: канарейка беднее настоящего приложения, зато её журнал читается за минуту.
Что показывает журнал одного запуска?
Run History в Dify пишет выполнение на трёх уровнях: Result — финальный вывод или сообщение об ошибке; Detail — исходный ввод, финальный вывод и системные метаданные; Tracing — какие узлы отработали, в каком порядке и сколько времени занял каждый. Плюс каждый узел хранит свой последний прогон: вход, выход и тайминг видны через «Last run» в панели узла (документация Dify, доступ 2026-07-18).
Здесь нужна честная граница. Документация по журналу не утверждает явно, что в интерфейсе по умолчанию показаны токены по каждому узлу. Поэтому я описываю журнал так, как он задокументирован: порядок узлов, тайминги, входы-выходы, ошибки. А разбивку по токенам и стоимости на узел отношу к тому, что нужно проверить эмпирически в скриншоте журнала своей канарейки. Не выдавай это за гарантированное поведение платформы; это то, что ты подтверждаешь на своём запуске.
Что я делаю с журналом на практике: беру Tracing одного пользовательского ввода и считаю обращения к модели по факту. Если на канве один LLM-узел, а в Tracing видно два прохода через модель, это и есть скрытые вызовы, ради которых всё затевалось. Каждый лишний проход добавляет строку расхода, которую визуальный блок не показывал.
Экспорт DSL не заменяет аудит
Соблазн большой: экспортировал схему в YAML, и вот тебе аудит. Не совсем. Приложения Dify (Chatflow/Workflow) выгружаются как DSL-файл YAML из меню Studio или контролом «Export DSL» на странице оркестрации. Файл захватывает метаданные приложения, параметры модели и полный граф узлов и рёбер. Но он явно исключает данные авторизации узлов-инструментов (например, ключи сторонних API) и запрашивает подтверждение перед включением переменных окружения типа Secret (документация Dify, доступ 2026-07-18).
Практический вывод: экспорт не даёт полного аудита с учётными данными. По одному YAML нельзя доказать, какой именно провайдер с ключом обработал вызов. Поэтому экспорт и журнал нужны в паре. Граф из DSL говорит, какие узлы существуют; журнал говорит, какие из них реально отработали и сколько раз. Одно из типичных условий провала этого дневника: экспорт и журнал не сходятся, в графе узел есть, а в Tracing он ни разу не запускался, или наоборот. Такое расхождение само по себе результат: оно указывает на ветку, которую ты не понимаешь.
Второе условие провала: спутать провайдера модели с самой платформой. Dify отвечает за канву и оркестрацию, а модель за узлом может принадлежать другому провайдеру. Разделять их обязательно, иначе счёт от провайдера ты запишешь на платформу и наоборот.
Провайдер модели и платформа Dify: разные слои
Чтобы использовать модель не из встроенного списка Dify (например, эндпоинт, совместимый с OpenAI API), ставишь плагин «OpenAI-API-compatible» из маркетплейса в разделе Settings/Integrations → Model Provider, задаёшь base URL (обычно заканчивается на /v1) и API-ключ. Dify валидирует ключ, и только после этого модели провайдера становятся выбираемыми внутри LLM-узлов (документация Dify и страница маркетплейса, доступ 2026-07-18). Это и есть задокументированная точка разделения между платформой Dify и любым внешним совместимым API.
Плагин публикует аккаунт langgenius по пути langgenius/openai_api_compatible в маркетплейсе. Это не случайное соседство: langgenius — та же организация, которая разрабатывает и поддерживает саму платформу Dify, значит один и тот же владелец стоит и за langgenius Dify API, и за самим плагином. Настоящая граница проходит дальше: внешний провайдер модели, на который плагин указывает через base_url и api_key, не относится ни к langgenius, ни к платформе Dify — именно эта граница, а не имя издателя в каталоге, разделяет платформу и модель. Полезнее развести два разных API. Есть собственный Dify API, которым платформа отдаёт доступ к приложению снаружи; на бесплатном Sandbox он ограничен 5000 вызовами в месяц (страница цен Dify, доступ 2026-07-18). И есть API внешней модели, который ты подключаешь этим плагином: модель за LLM-узлом приходит от отдельного, внешнего провайдера, и документация описывает только этот путь через маркетплейс, нигде не отождествляя провайдера с самой платформой Dify.
Здесь же уместно про биллинг. На Dify Cloud, если рабочее пространство использует выданные платформой AI Credits, каждый ответ модели тратит кредиты по ставке, которая зависит от модели. Если же ты подключаешь собственный аккаунт провайдера, включая OpenAI-совместимый, оплата идёт напрямую через него, и AI Credits не применяются. Пространство может смешивать оба источника и задавать «Usage Priority»: какой из них списывается первым (документация Dify, доступ 2026-07-18).
Вот куда естественно встаёт совместимый провайдер для этой задачи. provod.ai (российский аналог OpenRouter) даёт один API доступ к каталогу моделей, поддерживаемых платформой, совместимый с SDK OpenAI и Anthropic: меняешь base_url и ключ, и модель становится доступна в том же LLM-узле. Цены на модели идут без наценки платформы, а многоканальная маршрутизация держит работу, когда один верхний канал временно недоступен. Для LLM-узла это ровно тот «собственный провайдер», который выносит биллинг из AI Credits наружу.
В плагине совместимого провайдера base URL выглядит буквально так:
model\_provider: openai\_api\_compatible base\_url: https://api.provod.ai/v1 api\_key: sk-... # свой ключ, не ключ Dify # после валидации ключа модели становятся выбираемыми в LLM-узле
Реальная стоимость базы знаний зависит от индексации
База знаний Dify предлагает два метода индексации, выбираемые при создании. «High Quality» прогоняет эмбеддинг-модель по чанкам (это тратит токены и несёт стоимость) и поддерживает векторный, полнотекстовый или гибридный поиск с опциональным реранкингом. «Economical» использует инвертированный индекс из 10 ключевых слов на чанк, не тратит токены на эмбеддинги, но даёт ниже точность поиска. И необратимость, о которой легко забыть: если база создана как High Quality, переключить её на Economical нельзя, возможен только обратный переход, Economical → High Quality (документация Dify, доступ 2026-07-18).
Отсюда прямое проектное следствие для канарейки. Стоимость эмбеддингов появляется в момент создания High Quality-базы, а не когда-то потом. Пока ты измеряешь голый workflow без большой базы знаний, этой статьи в журнале нет. Как только развернёшь полную базу в режиме High Quality, расход на эмбеддинги придёт вместе с ней. Именно этот скачок канарейка предсказать не может: одна маленькая схема не даёт стоимость будущей полной базы знаний. Это честный предел метода, а не недоработка.
Где проходит граница между канарейкой и полной системой?
Лимиты Dify Cloud превращают скачок «канарейка → полная база знаний» в задокументированную ступень, а не в плавную кривую. Бесплатный план Sandbox ставит канарейке жёсткий счётный потолок и по хранению логов, и по объёму сообщений, точные цифры приведены в таблице ниже. Этот потолок прямо ограничивает, сколько раз ты успеешь прогнать и перечитать эксперимент, прежде чем логи устареют или кончатся кредиты (страница цен Dify, доступ 2026-07-18).
Платные тарифы Professional и Team снимают эти границы ступенькой, а не плавно: у обоих нет лимита на историю логов и месячного лимита API-вызовов, а конкретные цифры по credits, документам и хранилищу приведены в таблице ниже (страница цен Dify, доступ 2026-07-18). Держи в голове две оговорки: это облачные тарифы на дату доступа, Dify меняла облачные цены раньше; и они относятся к Dify Cloud, а не к self-hosted, где таких кредитных и документных потолков нет.
Ниже приведена таблица, которую я держу перед глазами, когда выбираю, где гонять канарейку и когда пора платить. Цифры взяты со страницы цен Dify на 2026-07-18 и относятся к облаку.
| Что проверяю | Sandbox (беспл.) | Professional | Team |
|---|---|---|---|
| Message credits | 200 всего | 5000 / мес | 10 000 / мес |
| Документы знаний | 50 | 500 | 1000 |
| Хранилище знаний | 50 МБ | 5 ГБ | 20 ГБ |
| История логов | 30 дней | безлимит | безлимит |
| API-вызовы | 5000 / мес | без лимита | без лимита |
Практический смысл таблицы для дневника: канарейку логично держать в Sandbox, пока хватает 200 кредитов и 30 дней логов на перечитывание журнала. Как только тебе нужно повторно инспектировать запуски дольше месяца или крутить объёмнее, ты уже на платной ступени, и это осознанное решение, а не сюрприз в счёте.
Чего этот подход не решает
Одна канарейка не даёт стоимость будущей полной базы знаний. Она измеряет ровно себя: сколько вызовов и состояний порождает один ввод в этой конкретной схеме. Нагрузка и стоимость после развёртывания полной High Quality-базы остаются неизвестными: их нужно мерить отдельно, когда база уже создана.
Журнал в задокументированном виде надёжно даёт порядок узлов, тайминги, входы-выходы и ошибки. Разбивку по токенам на узел я не обещаю как гарантию платформы: это то, что ты подтверждаешь на своём скриншоте. Если в твоём журнале её нет, число вызовов ты всё равно посчитаешь по Tracing, а стоимость на вызов возьмёшь у провайдера.
И граница ответственности: совместимый провайдер под LLM-узлом даёт модель, а не оркестрацию. Он не заменяет автоматизационные платформы, не даёт GigaChat, не подменяет частную или on-prem инфраструктуру и не делает за тебя работу по внедрению. У Dify остаётся логика сценария, у провайдера остаётся сама модель. Смешивать их в одном счёте означает повторить тот самый провал, ради предотвращения которого мы разделяли экспорт и журнал.
Отдельно про соседнюю задачу: это про расход Dify-workflow, а не про агента n8n. Если тебе нужен именно оркестратор внешних действий, а не приложение с базой знаний и памятью диалога, метод канарейки тот же, но узлы и журнал будут другими.
FAQ
Workflow или Chatflow для канарейки?
Если нужна память между ходами, выбирай Chatflow: там документированы Conversation Variables и Variable Assigner. Если сквозная память не нужна, подойдёт Workflow, где переменные сбрасываются после запуска. Это твоё проектное решение, оно определяет, сохранится ли состояние вообще.
Почему один LLM-узел на канве даёт несколько вызовов?
Потому что chatflow/workflow связывает узлы в цепочку, а узел подтягивает контекст из базы знаний и памяти. Точное число обращений на один ввод видно в Tracing твоего запуска: это то, что канарейка и измеряет.
Хватит ли экспорта DSL для аудита?
Нет. YAML захватывает граф узлов и параметры, но исключает данные авторизации инструментов. Какой провайдер реально обработал вызов, по одному экспорту не доказать; нужен журнал в паре с экспортом.
Можно ли исправить дорогую индексацию базы?
Только в одну сторону: Economical → High Quality. High Quality обратно на Economical не переключается, а эмбеддинги High Quality тратят токены с момента создания.
Сколько прогонов канарейки даёт бесплатный план?
На Dify Cloud Sandbox: 200 message credits всего и 30 дней истории логов (страница цен Dify, 2026-07-18). Этого хватает на аккуратную канарейку, но не на длительную повторную инспекцию.
provod.ai — отдельное пространство для задач компании
Рабочие запросы, доступы и расходы не должны жить в личных аккаунтах сотрудников: корпоративное пространство объединяет команду и помогает сохранять управляемый контур использования AI.
В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.
Компания получает единый тарифный принцип: цены 1:1 с официальными поставщиками и нулевая собственная наценка provod.ai.
Создайте рабочее пространство команды: форма регистрации · цены на модели · защита данных по 152-ФЗ · политика обработки данных
Источники
- Dify Docs, LLM-узел, доступ 2026-07-18: https://docs.dify.ai/en/use-dify/nodes/llm
- Dify Docs, история и логи, доступ 2026-07-18: https://docs.dify.ai/en/use-dify/debug/history-and-logs
- Dify Docs, Variable Assigner и Conversation Variables, доступ 2026-07-18: https://docs.dify.ai/en/use-dify/nodes/variable-assigner
- Dify Docs, управление приложениями и экспорт DSL, доступ 2026-07-18: https://docs.dify.ai/en/use-dify/workspace/app-management
- Dify Docs, методы индексации базы знаний, доступ 2026-07-18: https://docs.dify.ai/en/use-dify/knowledge/create-knowledge/setting-indexing-methods
- Dify Docs, провайдеры моделей и биллинг, доступ 2026-07-18: https://docs.dify.ai/en/cloud/use-dify/workspace/model-providers
- Dify, страница цен, доступ 2026-07-18: https://dify.ai/pricing
- Dify Marketplace, плагин OpenAI-API-compatible, доступ 2026-07-18: https://marketplace.dify.ai/plugin/langgenius/openai_api_compatible