Dify 앱을 OpenAI-API-compatible 엔드포인트에서 실행하기.

빠른 답: 프로바이더를 설치하고 모델을 id로 추가하기.

Dify에서 Settings를 열고 Model Provider로 이동하세요. Dify 1.0부터 프로바이더는 플러그인입니다: 목록에서 OpenAI-API-compatible(langgenius가 발행)을 찾거나 Marketplace에서 설치한 다음, 해당 카드에서 Add Model을 클릭하세요. 이 다이얼로그는 모델별입니다: Model Type을 선택하고(채팅 모델은 LLM), Model Name에 카탈로그의 정확한 id를 입력하고, API Key에 키를 붙여넣고, API Base URL을 https://api.apisrouter.com/v1로 설정하세요. Completion mode는 Chat으로 두고, 추가하는 id의 문서화된 한도로 Model context size와 Upper bound for max tokens를 설정하세요. 저장하면 모델이 프로바이더 목록에 나타나고 모든 앱의 모델 드롭다운에서 선택할 수 있습니다. 원하는 각 id마다 이 다이얼로그를 반복하세요; 모델당 2분, 한 번만 하면 됩니다.

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(GitHub의 langgenius, 약 14.9만 스타)는 선두적인 오픈소스 LLM 앱 플랫폼입니다: 시각적 워크플로우, 에이전트 노드, 지식베이스 위의 RAG 파이프라인, 그리고 자체 API 엔드포인트를 가진 배포된 앱까지. 이 스택의 모든 LLM 노드는 어떤 프로바이더 아래 등록된 모델로 해석됩니다. OpenAI-API-compatible 프로바이더는 의도적으로 범용적입니다. 추가하는 각 모델은 독립된 레코드(id, 엔드포인트, 키, 한도)이며, Dify는 설정된 base URL로 Model Name을 model 문자열로 삼아 표준 chat-completions 요청을 보냅니다. 요청의 어떤 부분도 어느 벤더가 모델을 훈련했는지 신경 쓰지 않으므로, claude-sonnet-4-6과 deepseek-v4-pro도 여느 GPT id만큼 유효하며, 필요하다면 서로 다른 모델이 서로 다른 엔드포인트를 가리키게 할 수도 있습니다. 마찰처럼 느껴지는 모델별 등록은 사실 제어 표면이기도 합니다: 입력하는 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와 장문 생성을 저해합니다. 습관이 아니라 모델 문서로부터 설정하세요. 앱이 이를 사용한다면 능력 선택자도 중요합니다: 이미지 입력을 받는 id에만 Vision Support를, 그리고 에이전트 노드가 의존하는 모델의 툴 사용 지원에 맞춰 function-call 설정을. 잘못된 능력 주장은 이 다이얼로그보다 디버깅하기 느린 워크플로우 안에서 런타임에 실패합니다. 워크스페이스가 임베딩이나 리랭크 모델도 사용한다면, 같은 프로바이더가 같은 base URL을 대상으로 자체 Model Type 항목 아래에 그것들을 등록합니다; 지식베이스 설정을 연결하기 전에 엔드포인트가 해당 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

워크플로우와 에이전트를 위한 모델 선택.

Dify 자체의 개요 페이지는 앱별 토큰을 보여주지만, APIsRouter 콘솔의 키별 사용량 뷰는 같은 페이지에서 모든 앱에 걸친 모델별 분할을 더해주며, 이것이 어떤 id가 자리를 유지할지 결정하는 숫자입니다.

• 워크플로우의 LLM 노드는 볼륨입니다: 모든 실행마다 발동하는 분류, 추출, 라우팅, 요약 스텝. 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에서는 노드의 모델을 바꾸는 것이 드롭다운 하나일 뿐, 마이그레이션이 아닙니다.
• 배포된 앱은 노드의 모델 선택을 그대로 물려받으므로, 에디터에서 내리는 드롭다운 결정이 곧 배포하는 앱의 유닛 이코노믹스입니다.

사용한 만큼 지불 · 공식 요금보다 저렴

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 플러그인으로 제공되며, 갓 셀프 호스팅된 인스턴스는 그것 없이 시작합니다. 워크스페이스당 한 번 설치하세요. 저장은 되는데 첫 사용에서 오류가 나는 모델은 보통 세 가지 중 하나입니다: 카탈로그 표기와 일치하지 않는 Model Name, /v1이 빠진 base URL(Dify는 여러분이 입력한 것에 /chat/completions 같은 라우트 경로를 덧붙입니다), 또는 모델이 받아들이는 범위를 넘는 context/max-token 값. 오류는 앱이나 워크플로우 로그에 드러나며, 수정은 다시 Add Model 다이얼로그로 돌아가는 것입니다. 일반 채팅 노드는 작동하는데 에이전트 노드가 실패한다면 function-calling 능력 설정, 또는 에이전트 전략이 기대하는 것을 만족하지 못하는 모델의 툴 사용을 가리킵니다. 설정 문제와 모델 선택 문제를 분리하려면 먼저 claude-sonnet-4-6으로 에이전트를 테스트하세요. 그리고 엄격한 이그레스 규칙 뒤의 셀프 호스팅 인스턴스에서는 엔드포인트에 도달해야 하는 것이 브라우저가 아니라 Dify api 컨테이너라는 점을 기억하세요; 그 컨테이너 내부에서의 curl이 연결성 문제를 빠르게 해결해 줍니다.

어떤 사람들이 게이트웨이를 통해 Dify를 쓰는가.

• 프로바이더마다 벤더 계정을 유지하지 않고 노드별로 Claude, GPT, Gemini, DeepSeek를 선택하고 싶은 LLM 앱 구축 팀.
• 내부 도구를 위해 Dify를 운영하며 하나의 프로바이더에 담긴 키 하나로 워크스페이스 전체의 클라우드 지출을 하나의 사용량 로그에 담고 싶은 셀프 호스터.
• 실제 워크플로우로 모델을 비교하는 빌더 — 각 후보는 새로운 통합이 아니라 Add Model 다이얼로그와 드롭다운 전환일 뿐입니다.
• 특정 벤더의 결제 수단에 접근할 수 없는 개발자. 카드 없이 충전만으로 사용할 수 있어 프로바이더별 가입 의존성이 사라집니다.
• Dify에서 클라이언트 앱을 배포하며 각 클라이언트의 모델 지출이 스스로 리포트되도록 프로젝트별 키가 필요한 에이전시.

엔드포인트 검증 및 첫 실행 디버깅.

모델 목록을 먼저 curl로 확인하고 그 출력에서 id를 등록하세요; 직접 입력한 Model Name은 필드가 자유 텍스트이기 때문에 not-found 오류의 주된 원인입니다. 그런 다음 같은 키로 등록한 id를 대상으로 채팅 완성을 한 번 실행하세요. Dify 내부에서는 프로덕션 워크플로우를 연결하기 전에 스크래치 앱에서 테스트하세요: LLM 노드를 추가하고, 새 모델을 선택하고, 한 번 실행하세요. 인증 오류는 API Key 필드를 가리킵니다; not-found는 Model Name을; 연결 오류는 base URL이나 컨테이너 이그레스를; 길이 오류는 context와 max-token 값을 가리킵니다. 실행이 흐르기 시작하면 APIsRouter 콘솔에서 요청별 모델, 토큰 수, 지출을 볼 수 있습니다. 워크플로우는 에디터에서 눈대중하기 어려운 방식으로 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"}]}'

자주 묻는 질문