Fai girare le app Dify su un endpoint OpenAI-API-compatible.

Risposta rapida: installa il provider, aggiungi i modelli per id.

In Dify, apri Settings e vai su Model Provider. Da Dify 1.0, i provider sono plugin: trova OpenAI-API-compatible (pubblicato da langgenius) nell'elenco o installalo dal Marketplace, poi clicca Add Model sulla sua card. Il dialogo è per modello: scegli il Model Type (LLM per i modelli chat), inserisci l'id esatto del catalogo in Model Name, incolla la tua chiave in API Key, e imposta API Base URL su https://api.apisrouter.com/v1. Lascia Completion mode su Chat, poi imposta Model context size e Upper bound for max tokens ai limiti documentati dell'id che stai aggiungendo. Salva, e il modello appare nell'elenco del provider, selezionabile dal menu a tendina dei modelli di ogni app. Ripeti il dialogo per ogni id che vuoi; due minuti per modello, una volta sola.

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

Come Dify comunica con un provider compatibile.

Dify (langgenius su GitHub, circa 149K stelle) è la piattaforma leader open source per app LLM: workflow visuali, nodi agente, pipeline RAG su knowledge base, e app pubblicate con propri endpoint API. Ogni nodo LLM in quello stack si risolve in un modello registrato sotto qualche provider. Il provider OpenAI-API-compatible è deliberatamente generico. Ogni modello che aggiungi è un record autonomo, id, endpoint, chiave, limiti, e Dify invia richieste chat-completions standard alla base URL configurata con il tuo Model Name come stringa model. Nulla nella richiesta si preoccupa di quale vendor ha addestrato il modello, quindi claude-sonnet-4-6 e deepseek-v4-pro sono validi qui quanto qualsiasi id GPT, e modelli diversi possono persino puntare a endpoint diversi se mai ne avessi bisogno. La registrazione per modello che sembra un attrito è anche la superficie di controllo: i valori di context size e max-tokens che inserisci sono ciò che l'orchestratore di Dify usa per gestire il budget dei prompt, tagliare la cronologia della conversazione e validare le impostazioni dei nodi. Inserisci numeri onesti dalla documentazione del modello. Sovrastimare il contesto produce richieste che l'endpoint rifiuta; sottostimarlo tronca silenziosamente il contesto che i tuoi nodi RAG hanno lavorato per recuperare.

I campi che fanno il lavoro reale.

Model Name è il valore sul filo: deve corrispondere carattere per carattere all'elenco /v1/models del gateway, poiché viaggia in ogni richiesta. Il display name opzionale del modello rietichetta solo la UI. Completion mode dovrebbe restare su Chat per ogni modello del catalogo attuale; l'opzione Completion esiste per endpoint legacy di text-completion e produce richieste malformate verso i modelli chat. Model context size e Upper bound for max tokens sono la coppia che la gente affretta. Context size è la finestra totale del modello; l'upper bound limita quanti token di output un nodo può richiedere. Dify imposta entrambi di default a 4096, ben al di sotto di ciò che i modelli attuali supportano, e lasciare i default paralizza silenziosamente il RAG su documenti lunghi e la generazione di forma lunga. Impostali dalla documentazione del modello, non per abitudine. I selettori di capacità contano quando le tue app li usano: Vision Support solo per gli id che accettano input immagine, e l'impostazione function-call da far corrispondere al supporto tool-use del modello, poiché i nodi agente ne dipendono. Una dichiarazione di capacità sbagliata fallisce a runtime dentro il workflow, un posto più lento in cui fare debug rispetto a questo dialogo. Se il tuo workspace usa anche modelli di embedding o rerank, lo stesso provider li registra sotto le proprie voci Model Type contro la stessa base URL; conferma che gli id specifici siano serviti dall'endpoint prima di collegarci le impostazioni della knowledge base.

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

Scegliere i modelli per workflow e agenti.

Le pagine di panoramica di Dify mostrano i token per app, ma la vista di utilizzo per chiave nella console di APIsRouter aggiunge la ripartizione per modello su tutte le app nella stessa pagina, il numero che decide quale id mantiene lo slot.

• I nodi LLM dei workflow sono volume: step di classificazione, estrazione, routing, riassunto che si attivano a ogni esecuzione. claude-haiku-4-5-20251001, gpt-5.4-mini e gemini-3.5-flash mantengono piatto il costo per esecuzione.
• I nodi agente e gli step di ragionamento complesso meritano claude-sonnet-4-6, e il suo uso affidabile dei tool conta di più negli agenti rispetto ai punteggi grezzi dei benchmark.
• I nodi di risposta RAG portano contesto recuperato a ogni chiamata, quindi il prezzo dell'input domina; deepseek-v4-pro vale la pena testarlo dove il retrieval è pesante e le risposte sono lunghe.
• Registra un id veloce e uno forte per lo stesso ruolo e mettili in A/B per nodo: in Dify, cambiare il modello di un nodo è un menu a tendina, non una migrazione.
• Le app pubblicate ereditano le scelte di modello dei loro nodi, quindi la decisione nel menu a tendina che prendi nell'editor è l'unit economics dell'app che rilasci.

Pagamento a consumo · sotto i prezzi ufficiali

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

Modalità di errore specifiche di Dify.

Provider mancante dall'elenco significa che il plugin non è installato: da Dify 1.0 il provider OpenAI-API-compatible viene distribuito come plugin del Marketplace, e le istanze self-hosted appena create partono senza di esso. Installalo una volta per workspace. Un modello che si salva ma dà errore al primo utilizzo è di solito una di tre cose: un Model Name che non corrisponde alla grafia del catalogo, una base URL a cui manca il /v1 (Dify aggiunge percorsi come /chat/completions a ciò che inserisci), o valori di context/max-token oltre ciò che il modello accetta. L'errore emerge nel log dell'app o del workflow; la correzione è di nuovo nel dialogo Add Model. Nodi agente che falliscono mentre i normali nodi chat funzionano indica l'impostazione di capacità function-calling, o un modello il cui uso dei tool non soddisfa ciò che la strategia dell'agente si aspetta. Testa prima gli agenti contro claude-sonnet-4-6 per separare i problemi di configurazione dalla scelta del modello. E sulle istanze self-hosted dietro regole di egress rigide, ricorda che è il container api di Dify che deve raggiungere l'endpoint, non il tuo browser; una curl dall'interno di quel container risolve rapidamente le questioni di connettività.

Chi instrada Dify tramite un gateway.

• Team che costruiscono app LLM e vogliono Claude, GPT, Gemini e DeepSeek selezionabili per nodo senza mantenere un account fornitore per provider.
• Self-hoster che fanno girare Dify per strumenti interni, dove una chiave in un provider mantiene tutta la spesa cloud del workspace su un unico log di utilizzo.
• Builder che confrontano modelli su workflow reali: ogni candidato è un dialogo Add Model e un cambio nel menu a tendina, non una nuova integrazione.
• Sviluppatori senza accesso alla fatturazione di un dato fornitore. L'accesso basato su ricarica senza obbligo di carta rimuove la dipendenza dalla registrazione per provider.
• Agenzie che rilasciano app per clienti su Dify e hanno bisogno di chiavi per progetto in modo che la spesa modello di ogni cliente si riporti da sola.

Verifica l'endpoint e fai debug della prima esecuzione.

Esegui prima una curl sull'elenco modelli e registra gli id dal suo output; i Model Name digitati a mano sono la causa principale degli errori not-found perché il campo è testo libero. Poi esegui una chat completion contro l'id che hai registrato, con la stessa chiave. Dentro Dify, testa in un'app di prova prima di collegare i workflow di produzione: aggiungi un nodo LLM, seleziona il nuovo modello, esegui una volta. Gli errori di autenticazione indicano il campo API Key; not-found indica il Model Name; gli errori di connessione indicano la base URL o l'egress del container; gli errori di lunghezza indicano i valori di context e max-token. Una volta che le esecuzioni scorrono, la console di APIsRouter mostra il modello per richiesta, i conteggi dei token e la spesa. I workflow moltiplicano le chiamate LLM in modi difficili da stimare a occhio dall'editor, e il log di utilizzo è dove il profilo reale dei token di una pipeline a cinque nodi diventa visibile, per modello, per giorno.

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

Domande frequenti