Четыре семейства моделей в Dify через один ключ и отдельные настройки
Четыре семейства моделей в Dify через один ключ и отдельные настройки Автору надоедало держать четыре разных API-ключа только ради сравнения моделей в одном рабочем процессе. Он подключил в Dify единый мультимодельный endpoint CometAPI, через который доступны чат-модели OpenAI, Anthropic, Google и DeepSeek. Важная оговорка: общий доступ — не общие настройки. Для каждого направления в Dify всё равно нужен отдельный маппинг модели, а каждый LLM-узел сам выбирает, какую модель вызывать. Схема двухслойная: одно подключение провайдера с ключом и четыре конфигурации текстовых моделей, у каждой свой ID и свои настройки возможностей. Отдельно автор держит небольшой Python-тест: когда запрос падает, он хочет отличить проблему API от проблемы Dify, прежде чем менять настройки рабочего процесса. Проверка начинается вне Dify: тот же ключ, endpoint и четыре ID моделей через OpenAI SDK. Простой текстовый запрос каждому семейству подтверждает, что ключ, адрес и ID работают. Автор подчёркивает: успех такого теста не гарантирует, что инструменты, изображения, структурированный вывод или конкретный workflow заработают. Затем провайдер подключается в Dify через плагин из Marketplace: ключ сохраняется как учётные данные провайдера, базовый URL плагин задаёт сам. Если плагин поставить нельзя, есть запасной путь — официальный провайдер, совместимый с OpenAI API, где на каждую модель создаётся своя запись с общим ключом и точным ID из каталога. Дописывать /chat/completions к адресу нельзя — Dify строит путь запроса сама. Автор проверяет каждую модель как отдельную интеграцию: короткий текстовый запрос, затем по необходимости изображения, вызов инструментов и структурированный вывод. Совместимость на уровне каталога не означает, что конкретная версия плагина Dify поддержит всё; у DeepSeek, например, маршрут только текстовый, и наследовать настройки картинок от другой модели не стоит. В реальном Chatflow или Workflow один ключ обслуживает все четыре записи, а разные LLM-узлы могут использовать разные модели. Дымовый тест доказывает связь, не пригодность: перед назначением модели по умолчанию автор советует прогнать представительные промпты. Отдельно — отладка по слоям: 401 обычно означает пробелы в ключе или лишнее слово Bearer, 404 и HTML-ответы — неверный базовый URL, отсутствие модели — устаревший плагин, а если текст работает, но картинки или инструменты нет — нужно перепроверить режимы и настройки, а не включать всё подряд. Перед продакшеном автор требует отдельные ключи для сред, зафиксированные проверенные ID моделей и логирование каждой маршрутизируемой модели: latency, токены, коды ошибок. Единый endpoint — удобство интеграции, а не гарантия одинаковых лимитов и цен у моделей. Источник: https://dev.to/mayacollins1/four-model-families-in-dify-one-credential-separate-configurations-454m