Patakbuhin ang mga Dify app sa isang OpenAI-API-compatible endpoint.

Mabilisang sagot: i-install ang provider, magdagdag ng models sa pamamagitan ng id.

Sa Dify, buksan ang Settings at pumunta sa Model Provider. Simula Dify 1.0, plugins na ang mga provider: hanapin ang OpenAI-API-compatible (nai-publish ng langgenius) sa listahan o i-install ito mula sa Marketplace, pagkatapos ay i-click ang Add Model sa card nito. Per-model ang dialog: piliin ang Model Type (LLM para sa chat models), i-type ang eksaktong id ng katalogo sa Model Name, i-paste ang key mo sa API Key, at itakda ang API Base URL sa https://api.apisrouter.com/v1. Iwanan ang Completion mode sa Chat, pagkatapos ay itakda ang Model context size at Upper bound for max tokens sa naka-document na limitasyon ng id na idinadagdag mo. I-save, at lalabas ang model sa listahan ng provider, mapipili mula sa dropdown ng model ng bawat app. Ulitin ang dialog para sa bawat id na gusto mo; dalawang minuto kada model, isang beses lamang.

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

Paano nakikipag-usap ang Dify sa isang compatible provider.

Ang Dify (langgenius sa GitHub, humigit-kumulang 149K stars) ang pangunahing open-source na LLM app platform: visual workflows, agent nodes, RAG pipelines sa ibabaw ng knowledge bases, at mga nai-publish na app na may sariling API endpoints. Bawat LLM node sa stack na iyon ay nire-resolve sa isang model na naka-register sa ilalim ng isang provider. Sinasadyang generic ang OpenAI-API-compatible provider. Ang bawat model na idinagdag mo ay isang self-contained na record, id, endpoint, key, limits, at ipinapadala ng Dify ang standard chat-completions request sa na-configure na base URL gamit ang Model Name mo bilang model string. Walang pakialam ang kahit ano sa request kung sinong vendor ang nag-train ng model, kaya kasing-valid dito ang claude-sonnet-4-6 at deepseek-v4-pro sa anumang GPT id, at maaaring maituro pa ng iba't ibang model sa iba't ibang endpoint kung kailangan mo iyon balang araw. Ang per-model na pagpaparehistro na parang abala ay isa ring control surface: ang mga value ng context size at max-tokens na inilalagay mo ang ginagamit ng orchestrator ng Dify para mag-budget ng prompts, mag-trim ng chat history, at mag-validate ng node settings. Maglagay ng tapat na numero mula sa dokumentasyon ng model. Ang pagsobra sa context ay gumagawa ng mga request na tinatanggihan ng endpoint; ang pagkulang dito ay tahimik na nagti-trim ng context na pinaghirapang makuha ng mga RAG node mo.

Ang mga field na may tunay na trabaho.

Ang Model Name ang wire value: dapat itong tumugma sa listahan ng /v1/models ng gateway nang letra-por-letra, dahil naglalakbay ito sa bawat request. Ang opsyonal na model display name ay nagre-relabel lamang ng UI. Dapat manatili sa Chat ang Completion mode para sa bawat model sa kasalukuyang katalogo; umiiral ang opsyong Completion para sa legacy text-completion endpoints at gumagawa ng malformed na mga request laban sa mga chat model. Ang Model context size at Upper bound for max tokens ang pares na dinadaliang tao. Ang context size ang buong window ng model; ang upper bound ang naglilimita kung ilang output tokens ang maaaring hilingin ng isang node. Idinedefault ng Dify ang dalawa sa 4096, na malayong mas mababa sa sinusuportahan ng mga kasalukuyang model, at ang pag-iwan sa mga default ay tahimik na nagpapahina sa long-document RAG at long-form generation. Itakda ang mga ito mula sa dokumentasyon ng model, hindi sa kinagawian. Mahalaga ang mga capability selector kapag ginagamit ng mga app mo ang mga ito: Vision Support lamang para sa mga id na tumatanggap ng image input, at ang function-call setting para tumugma sa suporta ng tool-use ng model, dahil umaasa dito ang mga agent node. Ang isang maling capability claim ay nabibigo sa run time sa loob ng workflow, na mas mahirap i-debug kaysa sa dialog na ito. Kung gumagamit din ang workspace mo ng embedding o rerank models, ire-register din ng parehong provider ang mga ito sa ilalim ng sarili nilang Model Type entries laban sa parehong base url; kumpirmahin munang si-serve ng endpoint ang mga partikular na id bago ikabit ang knowledge-base settings sa kanila.

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

Pagpili ng mga model para sa workflows at agents.

Ipinapakita ng sariling overview pages ng Dify ang tokens per app, pero idinadagdag ng per-key usage view sa APIsRouter console ang per-model na split sa lahat ng app sa parehong page, na siyang numerong nagdedesisyon kung aling id ang nananatili sa slot.

• Volume ang mga LLM node ng workflow: classification, extraction, routing, at mga summarization step na nagpapaputok sa bawat run. Pinapanatili ng claude-haiku-4-5-20251001, gpt-5.4-mini, at gemini-3.5-flash na patag ang per-run na gastos.
• Karapat-dapat sa claude-sonnet-4-6 ang mga agent node at kumplikadong reasoning steps, at mas mahalaga rito ang maaasahang tool use nito kaysa sa hilaw na benchmark scores.
• Nagdadala ng retrieved context sa bawat tawag ang mga RAG answer node, kaya naghahari ang input pricing; sulit subukan ang deepseek-v4-pro kung saan mabigat ang retrieval at mahaba ang mga sagot.
• Magparehistro ng mabilis na id at malakas na id para sa parehong role at A/B ang mga ito per node: sa Dify, ang pagpalit ng model ng isang node ay isang dropdown, hindi migration.
• Nagmamana ang mga nai-publish na app ng mga pinili ng model ng mga node nila, kaya ang desisyon sa dropdown na ginagawa mo sa editor ang unit economics ng app na ipinapadala mo.

Pay-as-you-go · mas mababa sa opisyal na presyo

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

Mga failure mode na specific sa Dify.

Kapag nawawala ang provider sa listahan, ibig sabihin ay hindi naka-install ang plugin: simula Dify 1.0, plugin sa Marketplace ang OpenAI-API-compatible provider, at nagsisimula nang wala ito ang mga sariwang self-hosted na instance. I-install ito nang isang beses per workspace. Ang isang model na na-save pero nabibigo sa unang paggamit ay karaniwang isa sa tatlong bagay: isang Model Name na hindi tumutugma sa baybay ng katalogo, isang base url na kulang ang /v1 nito (ini-append ng Dify ang mga route path tulad ng /chat/completions sa inilagay mo), o mga context/max-token value na lampas sa tinatanggap ng model. Lumalabas ang error sa app o workflow log; nasa Add Model dialog ulit ang solusyon. Ang mga agent node na nabibigo habang gumagana ang mga plain chat node ay tumuturo sa function-calling capability setting, o sa isang model na hindi tumutugon ang tool use nito sa inaasahan ng agent strategy. Subukan muna ang mga agent laban sa claude-sonnet-4-6 para ihiwalay ang problema sa configuration mula sa pagpili ng model. At sa mga self-hosted na instance sa likod ng mahigpit na egress rules, tandaan na ang Dify api container ang dapat makaabot sa endpoint, hindi ang browser mo; mabilis na nilulutas ng isang curl mula sa loob ng container na iyon ang mga tanong sa connectivity.

Sino ang nagru-route ng Dify sa pamamagitan ng isang gateway.

• Mga team na gumagawa ng LLM apps na gustong mapili ang Claude, GPT, Gemini, at DeepSeek per node nang walang vendor account per provider.
• Mga self-hoster na nagpapatakbo ng Dify para sa internal tools, kung saan pinapanatili ng isang key sa isang provider ang buong gastos sa cloud ng workspace sa isang usage log.
• Mga builder na naghahambing ng model sa tunay na workflows: ang bawat kandidato ay isang Add Model dialog at isang dropdown switch, hindi bagong integration.
• Mga developer na walang access sa billing ng isang partikular na vendor. Ang top-up based na access na walang kailangang card ay inaalis ang per-provider na sign-up dependency.
• Mga ahensiyang nagpapadala ng client apps sa Dify na kailangan ng per-project na key para ang gastos sa model ng bawat client ay nag-uulat sa sarili.

I-verify ang endpoint at i-debug ang unang run.

I-curl muna ang models listing at i-register ang mga id mula sa output nito; ang mga hand-typed na Model Names ang pangunahing sanhi ng mga not-found error dahil libreng text ang field. Pagkatapos, patakbuhin ang isang chat completion laban sa id na na-register mo, gamit ang parehong key. Sa loob ng Dify, mag-test sa isang scratch app bago ikabit ang mga production workflow: magdagdag ng LLM node, piliin ang bagong model, patakbuhin nang isang beses. Ang mga authentication error ay tumuturo sa API Key field; ang not-found sa Model Name; ang mga connection error sa base url o container egress; ang mga length error sa context at max-token values. Kapag dumadaloy na ang mga run, ipinapakita ng APIsRouter console ang per-request na model, token counts, at gastos. Pinaparami ng mga workflow ang mga LLM call sa paraang mahirap tantiyahin mula sa editor, at ang usage log ang lugar kung saan nagiging kita ang tunay na token profile ng isang five-node na pipeline, per model, per araw.

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"}]}'

Mga madalas itanong