Запустіть застосунки Dify на OpenAI-API-сумісному ендпоінті.

Коротка відповідь: встановіть провайдера, додайте моделі за id.

У Dify відкрийте Settings і перейдіть у Model Provider. Починаючи з Dify 1.0, провайдери — це плагіни: знайдіть OpenAI-API-compatible (від langgenius) у списку або встановіть його з Marketplace, потім натисніть Add Model на його картці. Діалог — на кожну модель окремо: оберіть Model Type (LLM для чат-моделей), введіть точний id з каталогу в Model Name, вставте свій ключ в API Key і встановіть API Base URL на https://api.apisrouter.com/v1. Залиште Completion mode на Chat, потім встановіть Model context size і Upper bound for max tokens відповідно до задокументованих лімітів того id, який додаєте. Збережіть — і модель з'явиться у списку провайдера, доступна для вибору з випадного списку моделей будь-якого застосунку. Повторіть діалог для кожного id, який хочете; дві хвилини на модель, одноразово.

Model Type:                LLM
Model Name:                claude-sonnet-4-6
API Key:                   sk-YOUR-APISROUTER-KEY
API Base URL:              https://api.apisrouter.com/v1
Completion mode:           Chat
Model context size:        200000
Upper bound for max tokens: 64000

Як Dify спілкується з сумісним провайдером.

Dify (langgenius на GitHub, приблизно 149 тис. зірок) — провідна open-source платформа для LLM-застосунків: візуальні workflow, вузли агентів, RAG-конвеєри над базами знань і опубліковані застосунки з власними API-ендпоінтами. Кожен вузол LLM у цьому стеку резолвиться до моделі, зареєстрованої в якогось провайдера. Провайдер OpenAI-API-compatible навмисно загальний. Кожна додана вами модель — це самодостатній запис: id, ендпоінт, ключ, ліміти, і Dify надсилає стандартні запити chat-completions до налаштованого base URL з вашим Model Name як рядком моделі. Нічого в запиті не дбає про те, який вендор тренував модель, тож claude-sonnet-4-6 і deepseek-v4-pro тут настільки ж валідні, як і будь-який id GPT, і різні моделі можуть навіть вказувати на різні ендпоінти, якщо колись вам це знадобиться. Реєстрація на кожну модель, яка здається тертям, водночас є поверхнею контролю: значення context size і max-tokens, які ви вводите, — це те, що оркестратор Dify використовує для бюджетування промптів, обрізання історії розмови і валідації налаштувань вузла. Вводьте чесні числа з документації моделі. Завищення контексту дає запити, які ендпоінт відхиляє; заниження тихо обрізає контекст, який ваші RAG-вузли доклали зусиль здобути.

Поля, що виконують реальну роботу.

Model Name — це значення дроту: воно має збігатися зі списком /v1/models шлюзу символ у символ, оскільки подорожує в кожному запиті. Опційна відображувана назва моделі лише перейменовує UI. Completion mode має залишатися на Chat для кожної моделі в поточному каталозі; опція Completion існує для застарілих ендпоінтів текстового завершення і породжує неправильно сформовані запити проти чат-моделей. Model context size і Upper bound for max tokens — пара полів, яку люди поспішають заповнити. Context size — це загальне вікно моделі; upper bound обмежує, скільки вихідних токенів може запросити вузол. Dify за замовчуванням встановлює обидва на 4096, що набагато нижче за те, що підтримують сучасні моделі, і залишення замовчувань тихо калічить довгодокументний RAG і довгу генерацію. Встановлюйте їх з документації моделі, а не за звичкою. Селектори можливостей мають значення, коли ваші застосунки їх використовують: Vision Support лише для id, що приймають зображення на вхід, і налаштування виклику функцій — відповідно до підтримки використання інструментів моделлю, оскільки вузли агентів на це покладаються. Неправильна заявка про можливість падає під час виконання всередині workflow, а це повільніше місце для дебагу, ніж цей діалог. Якщо ваш робочий простір також використовує моделі ембедінга чи rerank, той самий провайдер реєструє їх під власними записами Model Type до того самого base URL; підтвердіть, що конкретні id обслуговуються ендпоінтом, перш ніж прив'язувати до них налаштування бази знань.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50
# register these ids verbatim as Model Name entries

Вибір моделей для workflow і агентів.

Власні оглядові сторінки Dify показують токени на застосунок, але вигляд використання за ключем у консолі APIsRouter додає розбивку по моделях по всіх застосунках на одній сторінці, а це число вирішує, який id залишає за собою слот.

• LLM-вузли workflow — це об'ємна робота: кроки класифікації, витягування, маршрутизації, підсумовування, що спрацьовують на кожному прогоні. claude-haiku-4-5-20251001, gpt-5.4-mini і gemini-3.5-flash тримають вартість прогону плоскою.
• Вузли агентів і складні кроки міркування заслуговують на claude-sonnet-4-6, і його надійне використання інструментів важливіше в агентах, ніж сирі бенчмарк-показники.
• Вузли відповідей RAG несуть отриманий контекст у кожному виклику, тож ціна вхідних токенів домінує; deepseek-v4-pro варто протестувати там, де пошук важкий, а відповіді довгі.
• Зареєструйте швидкий id і сильний id для однієї й тієї самої ролі та проведіть A/B-тест по вузлах: у Dify перемикання моделі вузла — це випадний список, а не міграція.
• Опубліковані застосунки успадковують вибір моделі своїх вузлів, тож рішення з випадного списку, яке ви ухвалюєте в редакторі, — це unit-економіка застосунку, який ви випускаєте.

Оплата за фактом · нижче офіційних цін

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Збої, специфічні саме для Dify.

Відсутність провайдера в списку означає, що плагін не встановлений: починаючи з Dify 1.0 провайдер OpenAI-API-compatible постачається як плагін Marketplace, і свіжі self-hosted інстанси стартують без нього. Встановіть його один раз на робочий простір. Модель, яка зберігається, але падає при першому використанні, зазвичай одна з трьох речей: Model Name, що не збігається з написанням у каталозі, base URL без /v1 (Dify додає шляхи маршруту на кшталт /chat/completions до того, що ви вводите), або значення контексту/max-token за межами того, що модель приймає. Помилка проявляється в логу застосунку чи workflow; виправлення — назад у діалозі Add Model. Вузли агентів, що падають, поки звичайні чат-вузли працюють, вказують на налаштування можливості виклику функцій або на модель, чиє використання інструментів не відповідає тому, що очікує стратегія агента. Спочатку тестуйте агентів на claude-sonnet-4-6, щоб відділити проблеми конфігурації від вибору моделі. І на self-hosted інстансах за суворими правилами egress пам'ятайте, що саме контейнер api Dify має дістатися ендпоінта, а не ваш браузер; curl зсередини цього контейнера швидко вирішує питання з'єднання.

Хто спрямовує Dify через шлюз.

• Команди, що будують LLM-застосунки і хочуть, щоб Claude, GPT, Gemini і DeepSeek обиралися по вузлах без облікового запису постачальника на кожен провайдер.
• Self-hosters, що запускають Dify для внутрішніх інструментів, де один ключ в одному провайдері тримає весь хмарний бюджет робочого простору в одному лозі використання.
• Розробники, що порівнюють моделі на реальних workflow: кожен кандидат — це діалог Add Model і перемикання випадного списку, а не нова інтеграція.
• Розробники без доступу до білінгу певного постачальника. Доступ на основі поповнення без вимоги картки прибирає залежність від реєстрації в кожного провайдера.
• Агентства, що випускають клієнтські застосунки на Dify і потребують ключів по проєктах, щоб витрати на модель кожного клієнта звітували самі за себе.

Перевірте ендпоінт і налагодьте перший прогін.

Спочатку зробіть curl до списку моделей і реєструйте id з його виводу; вписані вручну Model Name — головна причина помилок not-found, оскільки поле вільнотекстове. Потім запустіть один chat completion проти зареєстрованого id з тим самим ключем. Усередині Dify тестуйте у чорновому застосунку, перш ніж вбудовувати production workflow: додайте LLM-вузол, оберіть нову модель, запустіть один раз. Помилки автентифікації вказують на поле API Key; not-found — на Model Name; помилки з'єднання — на base URL чи egress контейнера; помилки довжини — на значення контексту й max-token. Щойно прогони потечуть, консоль APIsRouter показує модель на запит, кількість токенів і витрати. Workflow множать виклики LLM способами, які важко оцінити на око з редактора, і лог використання — те місце, де реальний токен-профіль п'ятивузлового конвеєра стає видимим, по моделі, по дню.

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-haiku-4-5-20251001",
       "messages":[{"role":"user","content":"ping"}]}'

Поширені запитання