LLM 제공자와 모델을 관리하고, 외부 레지스트리에서 모델을 동기화하며, 상태 확인을 실행하고, 독립적인 청구를 위해 조직별 API 키를 구성합니다.
Entity Enricher는 다양한 LLM 제공자를 지원합니다. 각 제공자는 개별 가격, 기능, 구성을 갖춘 여러 모델을 가질 수 있습니다.
많은 팀이 LLM 트래픽을 기업용 AI 게이트웨이, 지역 엔드포인트, 또는 기본 제공되지 않는 공급자를 통해 라우팅합니다 — 예를 들어 엔터프라이즈 LiteLLM 프록시, Cloudflare AI Gateway, 또는 Alibaba DashScope(Qwen 모델용) 등입니다. 이러한 공급자는 사용자 지정 기본 URL을 사용하여 별도의 Standard (OpenAI-compatible) 공급자로 추가합니다.
acme-openai-gw). openai 또는 anthropic 같은 내장 이름은 예약되어 있습니다. https://gateway.example.com/v1. 이 필드는 Entity Enricher에 기본 클라이언트가 없는 모든 공급자에 대해 필수입니다. https:// URL이어야 합니다. 루프백 및 사설 범위(localhost, 10.x, 192.168.x)는 SSRF를 방지하기 위해 거부됩니다 — 자체 호스팅 서버는 인터넷을 통해 접근 가능해야 합니다. 로컬 Ollama의 경우 전용 Ollama 터널을 대신 사용하세요./v1 프로토콜(chat completions, /models)을 지원해야 합니다. {endpoint}/models를 탐색합니다.각 provider에는 key당 최대 동시 호출 수 설정(속도 제한 재정의)이 있습니다. 이는 단일 API key가 병렬로 실행하는 LLM 호출 수를 제한하며 — 해당 key를 사용하는 모든 흐름, 즉 다중 expertise enrichment 팬아웃, classification, arbitration, schema/샘플 생성을 포함합니다.
이는 요금제의 최대 동시 작업 한도와는 별개이며, 이 한도는 전체 조직이 모든 공급자에 걸쳐 동시에 실행하는 보강 작업 수를 제한합니다.
각 model은 자신의 기능을 추적하며, 이는 model 선택기에 아이콘으로 표시됩니다:
| 기능 | 설명 |
|---|---|
| 비전 | 이미지 및 시각적 입력을 처리할 수 있습니다 |
| 도구 호출 | 함수 호출 / 도구 사용 지원 |
| 오디오 입력 | 오디오 입력을 처리할 수 있습니다 |
| PDF 입력 | PDF 문서를 처리할 수 있습니다 |
| 프롬프트 캐싱 | 비용 절감을 위한 프롬프트 캐싱 지원 |
| 추론 | 확장 사고 / 사고 연쇄 기능 |
| 임베딩 | 답변하는 대신 텍스트를 벡터로 변환하며, semantic ID를 해석하는 데 사용됩니다. 임베딩 model은 고유한 벡터 크기를 가진 별도의 계열이며, enrichment 선택기에는 표시되지 않습니다 |
모델 지정은 선택 사항입니다. 보강, 스키마 생성, 샘플 생성은 모두 auto를 허용하며 — 모델을 생략하면 auto로 간주합니다 — 이 값은 작업이 시작되는 시점에 작업별로 서버에서 확정됩니다. 실행 결과에는 어떤 모델이 선택되었는지 표시되므로, 자동이 곧 불투명함을 뜻하지는 않습니다.
소유자는 설정 → 조직 → 기본값에서 작업별로 선호 모델을 고정할 수 있습니다. 해당 작업에 설정된 모델이 있으면 그 모델이 우선합니다.
고정된 모델이 없으면 스코어링 소스 벤치마크에서 종합 점수가 가장 높은 모델이 선택됩니다. 이는 사용자의 스키마에서 품질·속도·비용을 직접 측정한 결과입니다. 스코어링 소스가 전혀 없으면 요청은 추측으로 처리되지 않고 거부됩니다.
웹 검색을 켜거나 원본 그대로 전송해야 하는 문서를 첨부하면, 이를 실제로 처리할 수 있는 model로만 후보가 제한됩니다. 조건을 충족하는 model이 없으면 조용히 성능을 낮추는 대신 명시적인 오류가 표시됩니다.
모델을 비활성화하지 않고 특정 작업에서만 제외할 수도 있습니다. 보강은 잘하지만 스키마 생성 품질이 떨어지는 모델은 스키마 및 샘플 생성 선택기에서만 숨길 수 있으며, 조직 단위로 또는 관리자가 전역으로 설정할 수 있습니다. 다른 모든 곳에서는 그대로 사용할 수 있으므로 아래의 비활성화보다 온건한 수단입니다.
외부 레지스트리에서 동기화하여 모델 가격을 최신 상태로 유지하세요. 동기화 과정은 새 모델, 가격 변경, 제거된 모델을 자동으로 감지합니다.
기본 가격 정보 소스입니다. 실제 API 모델 이름, 가격, 컨텍스트 길이, 기능이 포함된 GitHub의 LiteLLM 커뮤니티 관리 레지스트리에서 가져옵니다.
약 30개 provider를 지원합니다. 표시 이름, benchmark, 생성 속도는 포함하지 않습니다.
pricepertoken.com에서 제공하는 대체 소스입니다. 표시 이름, 벤치마크(코딩 및 수학 점수), 생성 속도(초당 토큰)를 포함합니다.
약 20개 provider를 지원합니다. LiteLLM보다 풍부한 메타데이터를 제공합니다.
GLM 모델 식별자에 대한 공식 인증 카탈로그로, 가격은 Z.AI 문서에서 직접 파싱하고 기능 격차는 해당 문서에서 조사했습니다.
이전에 LiteLLM 및 PricePerToken에서 가져온 Z.AI 항목을 대체합니다.
최소 상태 점검 프롬프트를 실행하여 모델에 연결할 수 있는지 사전에 검증합니다. 이를 통해 보강 중 사용자가 오류를 겪기 전에 손상된 모델을 발견할 수 있습니다.
상태 확인은 모든 model, 특정 provider의 model 또는 단일 model에서 실행할 수 있습니다. 결과는 SSE를 통해 실시간으로 스트리밍되며 통과/실패 수를 보여주는 진행률 표시줄이 함께 표시됩니다.
보강 호출이 “model not found” 오류로 실패하면 반복적인 실패를 방지하기 위해 모델이 자동으로 비활성화됩니다. 이는 일반적인 보강 작업 중에 실시간으로 발생합니다.
| 비활성화 사유 | 설정한 사람 | 자동 재활성화됨? |
|---|---|---|
| 모델을 찾을 수 없음 | 보강 오류 또는 상태 점검 | 예 (가격 동기화 또는 검증을 통해) |
| 동기화 제거됨 | 가격 동기화(모델 사라짐) | 예 (모델이 레지스트리에 다시 나타나는 경우) |
| 수동 | UI의 관리자 토글 | 아니요(수동 재활성화만 가능) |
조직은 독립적인 청구 및 사용량 추적을 위해 자체 LLM 제공자 API 키를 구성할 수 있습니다. 시스템은 LRU 선택을 사용하는 2계층 키 확인 방식을 사용합니다:
API Keys 페이지에서 구성되는 조직별 키입니다. 제공자당 여러 키를 LRU 순환과 함께 지원합니다. Fernet으로 암호화됩니다.
관리자가 관리하는 시스템 전역 키입니다. 모든 조직에서 공유됩니다. 또한 LRU 순환 방식으로 제공자당 여러 키를 지원합니다.
보강마다 어떤 키가 사용되었는지 기록되므로 키별 비용을 추적할 수 있습니다. 키는 상태 확인과 사용량 카운터를 지원합니다. 풀 안에서는 활성화된 키 중 마지막 사용 시각이 가장 오래된 키가 다음으로 선택됩니다. 키는 직접 비활성화할 때만 로테이션에서 빠지므로, 제공자 오류로 키가 조용히 중단되는 일은 없습니다. 키 관리 방법은 API Keys 가이드에서 확인하세요.
전체 프로바이더 및 모델 구성을 백업하거나 다른 인스턴스로 이전하기 위해 JSON으로 내보냅니다. 가져오기는 항상 업서트 방식입니다. 기존 프로바이더와 모델은 이름으로 매칭되어 제자리에서 업데이트되고, 새로운 항목은 추가되며 삭제되는 것은 없습니다.
이 내보내기에는 공급자 설정, 모델 구성, 가격, 기능, 표준 모델 사양이 포함되지만, 별도로 저장되는 API 키는 절대 포함되지 않습니다. 가져오기 후에는 API 키를 별도로 구성하세요. 시스템 관리자는 전체 글로벌 카탈로그를 백업하며, 조직 소유자는 자신의 조직 공급자와 모델만 내보내고 가져옵니다 — 공유 글로벌 카탈로그는 가져오기를 통해 생성하거나 편집할 수 없습니다.