2026 Dify 1.18.0 KnowledgeFS можно ли разместить самостоятельно? Сначала решите, включать ли его

Уже работающий процесс Dify использует Classic Knowledge, а после обновления появилась новая база знаний для Agent.

Краткий вывод: существующую схему не нужно переводить на KnowledgeFS только из-за выхода Dify 1.18.0. Это необязательная Beta-интеграция с отдельной службой и базой данных. Если используется Community Edition, перед пробным запуском проверьте официальные условия включения и доступность подходящего образа; для производственной базы знаний пока не следует считать KnowledgeFS вариантом миграции по умолчанию.

Материал предназначен разработчикам, которые размещают Dify Community Edition самостоятельно и рассматривают обновление до 1.18.0.
Технические руководители найдут здесь способ оценить влияние Agent Knowledge Base на границы сервисов и данных.
Команды, планирующие сервер, смогут отделить ресурсы платформы Dify и базы знаний от ресурсов модельного вывода.

Последняя проверка — 26 октября 2026 года; сведения сверены с официальной публикацией Dify 1.18.0, конфигурацией Docker Compose и сообщением пользователя в GitHub Issue. Статус Community Edition и доступность образов могут измениться: при публикации или обновлении статьи их необходимо проверить повторно.

Сначала определите, какую задачу должна решить новая база знаний

Выпуск Dify 1.18.0 датирован 23 октября 2026 года. В примечаниях к нему Agent Knowledge Base обозначена как Beta и описана как необязательная интеграция с отдельной службой и базой данных. Это не означает, что существующие базы Knowledge автоматически становятся устаревшими или должны быть перенесены. Подтверждение статуса и состава нового решения — в официальных примечаниях к выпуску.

Решение стоит принимать от задачи, а не от номера версии. Если Classic Knowledge уже поддерживает нужные документы и RAG-процессы, запуск дополнительного сервиса добавит компоненты для обслуживания, но сам по себе не гарантирует полезного изменения для пользователей. Если же требуется использовать пространство знаний в сценариях Agent, следует проверить, закрывает ли Beta именно этот пробел и какие функции уже доступны в конкретной установке.

Чем Agent Knowledge Base отличается от прежней базы знаний? Это новый вариант организации знаний для сценариев Agent, а не обязательная замена Classic Knowledge. Перед включением сопоставьте нужную функцию с тем, как сейчас устроены загрузка документов, поиск и вызов знаний в ваших рабочих процессах. Точные границы возможностей следует сверять с выпуском и документацией установленной версии, а не выводить из названия функции.

Для принятия решения удобно присвоить каждому сценарию простую оценку:

• Нет новой потребности — 0. Текущие процессы работают, нужный способ поиска уже есть. Оставайтесь на Classic Knowledge.
• Есть проверяемая потребность — 1. Например, требуется испытать пространство знаний в конкретном сценарии Agent. Планируйте изолированную проверку, не заменяя рабочую базу.
• Есть подтверждённая потребность и поддержка — 2. Требуемое поведение проверено на используемой редакции, доступен официальный путь установки, а восстановление протестировано. Тогда можно оценивать дальнейшее применение.

Это не рейтинг качества продукта. Он помогает отделить интерес к новой функции от причины менять работающую систему.

Условия Community Edition нужно проверить отдельно

Можно ли самостоятельно разместить KnowledgeFS в Community Edition? Вопрос нельзя свести к простому «да» или «нет»: важно проверить условия именно для локальной Community Edition и версии 1.18.0. В официальной конфигурации Docker Compose KnowledgeFS по умолчанию выключен; для локального запуска Community Edition требуется явное включение через предусмотренную настройку разработки. Проверьте это по официальному Compose-файлу и примеру переменных KnowledgeFS для версии 1.18.0.

Слово «выключен» здесь важно. Наличие кода или примера конфигурации ещё не говорит, что новая служба включается обычным обновлением стека, готова к эксплуатации в конкретной редакции или имеет тот же путь поддержки, что остальные компоненты Dify. Не переносите параметры из примера в рабочее окружение наугад: сначала проверьте, к какой версии они относятся, какие сервисы и переменные связаны между собой и какой образ требуется.

В обсуждении релиза 1.18.0 также можно сверить контекст выхода функции. Однако для производственного решения приоритет имеют актуальные официальные инструкции и сведения о версии, а не предположения из обсуждений.

Нужны ли отдельная служба и база данных? Да: в описании выпуска KnowledgeFS указан как необязательная отдельная служба с базой данных. Поэтому оценивать нужно не только переключатель в Compose, но и весь набор компонентов, постоянное хранение данных, сетевые связи, резервное копирование и восстановление. Если заранее неясно, где находятся данные новой службы и как вернуть её после сбоя, сначала уточните эти пункты, а не подключайте её к рабочему процессу.

Для проверки конфигурации используйте официальное руководство по Docker-развёртыванию Dify. Оно полезно для сопоставления структуры установки, но не заменяет проверку конкретного образа, редакции и инструкций для KnowledgeFS.

Редакция и способ размещения меняют условия решения

Community Edition, Enterprise и Cloud нельзя считать взаимозаменяемыми способами запуска. Для Community Edition важно подтвердить локальную настройку, необходимый образ и доступный путь поддержки. Для Enterprise нужно отдельно проверить, входит ли функция в используемую редакцию, какие условия поддержки действуют и какие ограничения установлены для производственной эксплуатации. Порядок для Community Edition не следует автоматически применять к Enterprise.

В Cloud ситуация тоже зависит от официального предложения и текущего статуса функции. Не следует считать, что облачный запуск доступен одновременно с самостоятельным размещением или что его сроки совпадают с датой релиза. Перед планированием проверьте актуальное объявление и документацию именно для нужной формы размещения.

Риски возникают, если смешать эти сценарии:

• Настройка для локальной Community Edition может не описывать путь Enterprise.
• Доступность сервиса в исходном коде не гарантирует, что готовый образ опубликован для нужной архитектуры и версии.
• Beta-статус не равен обещанию поддержки в производственной среде.
• Успешный старт контейнера ещё не доказывает, что восстановление данных и возврат к прежнему процессу проверены.

Dify в Docker можно использовать как отправную точку для изучения официальной структуры запуска. Перед внедрением всё равно зафиксируйте версии образов, источник каждого образа и применяемые параметры. Если вопрос касается поддержки или редакции, используйте актуальную официальную документацию и канал поддержки, подходящий вашей установке; пользовательское обсуждение не заменяет подтверждение.

Платформа, хранилище знаний и модель — разные нагрузки

Планируя сервер, разделяйте как минимум три части: саму платформу Dify, дополнительную службу KnowledgeFS с её базой данных и модель, которая выполняет генерацию. Их можно запускать рядом или разнести по разным системам, но в расчёте они остаются разными составляющими.

Если Dify обращается к внешнему API модели, вычисления самой модели не следует автоматически включать в требования к серверу Dify. При этом данные, передаваемые во внешний API, требуют отдельного решения по приватности. Для внутренней оценки полезно описать, какие документы остаются в вашем контуре, какие фрагменты отправляются модели и какие журналы или метаданные сохраняются. Подход к границе данных можно сопоставить с принципами, изложенными на странице о конфиденциальности.

Если модель запускается на собственной машине, её память и вычислительные требования рассчитываются отдельно. Для грубой оценки веса параметров используйте формулу:

память для весов ≈ число параметров × разрядность квантования ÷ 8.

Это лишь нижняя оценка объёма весов. К ней добавляются память контекста, кеш, служебные данные и запас операционной системы. Итог зависит от модели, формата квантования, длины контекста, движка и характера нагрузки. Без теста на конкретной комбинации нельзя обещать скорость генерации или приемлемое число одновременных запросов.

CPU-сервер может быть уместен для платформенной части, индексации или отдельных задач обработки, но он не превращается в GPU-систему. Если планируется локальное выполнение модели, сначала отдельно проверяйте модель, квантование, контекст и доступную память. Обучение и высоконагруженный вывод больших моделей не следует закладывать в этот план без соответствующего оборудования и измерений.

Таблица не задаёт требований к конкретной конфигурации сервера: официальные сведения о выпуске не дают универсального объёма ресурсов для всех наборов документов и рабочих процессов. Ресурсный план следует делать после инвентаризации фактических сервисов и тестов на ожидаемой нагрузке.

Проверка перед пилотом и вводом в работу

До включения новой службы полезно пройти последовательность, которая ограничивает риск для действующей базы.

• [ ] Зафиксируйте задачу. Запишите, какой процесс Agent должен использовать знания и чего не хватает в текущем Classic Knowledge. Если потребность нельзя сформулировать в проверяемом виде, обновление не является достаточной причиной для пилота.
• [ ] Подтвердите редакцию и поддержку. Проверьте, относится ли найденная инструкция к Community Edition, Enterprise или Cloud и к используемой версии Dify. Не считайте локальную настройку доказательством производственной поддержки.
• [ ] Проверьте образ и архитектуру. Найдите официальный источник требуемого образа, подтвердите его версию и совместимость с окружением. Не подменяйте отсутствующую официальную информацию выводом из сообщения пользователя в Issue.
• [ ] Разберите зависимости. По Compose и примеру конфигурации установите, какие контейнеры, переменные, сетевые соединения и база данных нужны. Отдельно отметьте, где хранятся постоянные данные.
• [ ] Спланируйте перенос без замены оригинала. Для пилота используйте изолированный набор данных или копию, если это допустимо вашей политикой. Не переводите производственный процесс на новый путь до проверки результата.
• [ ] Опишите резервирование и восстановление. Уточните, какие данные необходимо сохранить, как проверить целостность резервной копии и как вернуть прежний рабочий процесс при неудачном тесте. Одного наличия файла резервной копии недостаточно — восстановление нужно проверить.
• [ ] Проверьте результат по критериям. Запустите поиск по контрольным запросам, проверьте доступ к нужным данным, ожидаемые ограничения прав и поведение при недоступности дополнительной службы.
• [ ] Назначьте условие остановки. Если образ, поддержка редакции или восстановление не подтверждены, прекратите пилот и оставьте текущий Classic Knowledge без изменений.

К проверке прав доступа следует относиться как к самостоятельному критерию, а не как к побочному эффекту поиска. До подключения корпоративных документов определите, кто может загружать их, кто может выполнять запросы и какие границы доступа должны сохраняться в процессе Agent. Если ответ не подтверждён документацией и тестом на используемой редакции, не помещайте чувствительные данные в пилот.

Когда оставаться на Classic Knowledge, а когда пробовать новое

Оставайтесь на Classic Knowledge, если текущий RAG-процесс стабилен, пользователям хватает доступных операций, а для KnowledgeFS нет подтверждённой деловой задачи. Это снижает число компонентов, за которыми нужно следить, и не создаёт миграционную работу без конкретной выгоды.

Планируйте изолированное испытание, если новый сценарий Agent требует отдельного пространства знаний и команда может подтвердить редакцию, официальный путь установки, источник образа и порядок восстановления. Пилот должен отвечать на ограниченный вопрос: закрывает ли новая функция нужное поведение при приемлемых для команды границах данных и поддержки?

Для оценки ресурсов составьте список компонентов, а не ищите одну универсальную цифру «для Dify». Укажите платформу, базу знаний, KnowledgeFS — если он нужен, — модельный API или локальный движок, хранилище документов, журналы и резервные копии. Затем измерьте фактическое потребление в тестовой среде. Если внешняя модель используется через API, её вычислительная нагрузка находится вне сервера Dify, но сетевые расходы и требования к передаваемым данным остаются предметом отдельной оценки.

При планировании аренды также сравните временный тест и постоянную службу. Если требуется только краткий эксперимент с лёгкой нагрузкой, отдельный физический сервер может оказаться избыточным. Если же несколько сервисов должны постоянно работать независимо от соседних арендаторов, общая виртуальная среда может иметь ограничения по гарантии ресурсов, выбору дисковой схемы или прозрачности тарификации — конкретные условия нужно проверять у выбранного поставщика.

Для длительной эксплуатации собственной платформы и дополнительных служб аренда выделенного AMD-сервера NodeKVM может быть уместнее общего VPS: машина предоставляется одному арендатору, а конфигурацию и цену следует сверять по актуальной продуктовой таблице. Это не подтверждает совместимость или предварительную установку KnowledgeFS. Перед заказом сопоставьте фактическую схему Dify с доступными ресурсами и условиями на странице тарифов NodeKVM; если же нынешняя установка уже закрывает задачу, сохраните Classic Knowledge и отложите пилот до подтверждения всех условий.