이 문서는 머신러닝 섹션의 일부입니다.
개념
💡 Foundation Model API 는 Databricks가 호스팅하는 대규모 언어 모델(LLM) 을 즉시 사용할 수 있는 서비스입니다. 별도의 모델 배포 없이, API 호출만으로 텍스트 생성, 임베딩, 코드 생성 등을 수행할 수 있습니다.클라우드 환경에서 LLM을 직접 배포하고 운영하려면 GPU 인스턴스 선택, 모델 로딩, 스케일링, 모니터링 등 상당한 인프라 전문 지식이 필요합니다. Foundation Model API는 이 모든 복잡성을 Databricks가 관리해 주므로, 개발자는 API 호출만으로 최신 LLM을 즉시 활용할 수 있습니다. OpenAI API와 호환되는 인터페이스를 제공하므로, 기존 코드의 마이그레이션도 간편합니다.
지원 모델
Databricks 호스팅 모델
Databricks가 직접 호스팅하고 관리하는 모델입니다. 별도의 배포 과정 없이 즉시 API를 호출할 수 있으며, Databricks 인프라 내에서 처리되므로 데이터가 외부로 전송되지 않습니다.💡 모델 선택 가이드: 일반적인 대화와 분석에는 Llama 3.3 70B 가 가장 좋은 균형(성능/비용)을 제공합니다. 매우 복잡한 추론이 필요하면 405B, 단순 분류나 요약은 8B 로 비용을 절약할 수 있습니다.
외부 모델 (External Model / 프록시)
External Model 엔드포인트를 통해 외부 LLM도 동일한 Databricks API 로 사용할 수 있습니다. 외부 API 키를 Databricks Secret에 안전하게 저장하고, Databricks의 거버넌스(로깅, 모니터링, 접근 제어)를 적용할 수 있다는 것이 핵심 장점입니다.External Model 엔드포인트 생성
API 유형 상세
Foundation Model API는 세 가지 주요 API 유형을 제공합니다. 각 API는 OpenAI API와 호환되는 형식을 사용하므로 기존 코드를 쉽게 마이그레이션할 수 있습니다.Chat Completions (대화형)
가장 많이 사용되는 API로, 대화 형식의 메시지를 주고받습니다. 시스템 프롬프트로 LLM의 역할을 정의하고, 사용자 메시지에 대한 응답을 생성합니다.주요 파라미터
Completions (텍스트 완성)
프롬프트 뒤에 이어지는 텍스트를 생성합니다. Chat 형식이 아닌 단순 텍스트 완성 작업에 적합합니다.Embeddings (임베딩)
텍스트를 고정 차원의 벡터로 변환합니다. 텍스트의 의미를 수치화하여 유사도 검색, 분류, 클러스터링 등에 활용합니다. RAG 파이프라인에서 문서 인덱싱과 쿼리 임베딩에 필수적입니다.SQL에서 사용 (ai_query)
Databricks SQL에서ai_query() 함수를 사용하면, SQL 쿼리 안에서 직접 LLM을 호출할 수 있습니다. 대량의 데이터에 대해 일괄적으로 LLM 처리를 적용할 때 매우 유용합니다.
과금 모델
Foundation Model API는 두 가지 과금 방식을 제공합니다. 사용 패턴에 따라 적절한 방식을 선택하면 비용을 최적화할 수 있습니다.Pay-per-token 상세
Pay-per-token은 사용한 만큼만 비용을 지불하는 방식입니다. 초기 설정이 필요 없어 바로 시작할 수 있지만, 트래픽이 많을 때 비용이 예측하기 어려울 수 있습니다.Provisioned Throughput 상세
Provisioned Throughput은 일정한 처리 성능을 보장받는 방식입니다. 프로덕션 환경에서 응답 지연시간의 SLA를 보장해야 할 때, 또는 대량 배치 처리가 필요할 때 적합합니다.과금 방식 선택 가이드
Rate Limiting (요청 제한)
Foundation Model API에는 안정적인 서비스를 위해 Rate Limiting이 적용됩니다. 제한에 걸리면 HTTP 429 오류가 반환되므로, 애플리케이션에서 적절한 재시도 로직을 구현해야 합니다.Rate Limiting 대응 방법
Foundation Model API vs 외부 직접 호출 비교
💡 핵심 이점: Foundation Model API를 통해 외부 모델을 프록시하면, 모든 LLM 호출에 대해 비용 추적, 접근 제어, 감사 로그 가 자동으로 적용됩니다. 직접 외부 API를 호출하면 이러한 거버넌스를 별도로 구현해야 합니다.
현업 가이드: Pay-per-token vs Provisioned Throughput 비용 역전점
현업에서 “어느 시점에 Provisioned Throughput으로 전환해야 하는가?”는 가장 많이 받는 질문 중 하나입니다. 구체적인 숫자로 설명합니다.비용 역전점 분석
Llama 3.3 70B 기준 예시 단가: 입력 0.002/1K 토큰, 평균 요청당 입력 500 + 출력 200 토큰
💡 현업에서는 이렇게 합니다: 월 50만 건 이상 의 요청이 예상되면 Provisioned Throughput을 검토합니다. 단, 단순 비용 외에 응답 지연시간(Latency) 도 고려하세요. Pay-per-token은 공유 인프라이므로 피크 시간에 지연이 길어질 수 있습니다. 실시간 챗봇처럼 P95 응답 시간이 중요한 경우, 비용이 더 들더라도 Provisioned Throughput을 선택합니다.
과금 방식 전환 판단 체크리스트
모델 선택 가이드: 어떤 상황에 어떤 모델을 쓸 것인가
현업에서 “어떤 모델을 써야 하나요?”는 기술 리더가 가장 어려워하는 질문입니다. 모델 선택은 성능, 비용, 데이터 보안, 라이선스 4가지 축으로 판단합니다.호스팅 모델 vs 외부 모델 선택 기준
용도별 모델 추천
⚠️ 현업에서는 이렇게 합니다: “하나의 모델로 모든 것을 해결하자”는 접근은 비용 낭비입니다. 현업에서는 용도별로 모델을 다르게 사용합니다. 단순 분류는 8B 모델, 복잡한 추론은 70B, 고객 대면은 외부 모델. External Model 엔드포인트를 활용하면 코드 변경 없이 모델만 교체할 수 있으므로, A/B 테스트로 최적 모델을 찾는 것이 좋습니다.
Rate Limiting 대응 실전 전략
Pay-per-token에서 Rate Limiting은 “겪어보면 아는” 고통입니다. 실전 대응 전략을 공유합니다.Rate Limiting이 문제가 되는 전형적인 시나리오
대량 처리를 위한 실전 패턴
💡 현업 팁: 대량 배치 처리(100만 건+)에서는 ai_query()를 직접 사용하는 것보다, Spark UDF로 래핑 하고 파티션별로 병렬 처리하는 것이 효율적입니다. 각 파티션에서 적절한 Rate Limiting을 적용하면, Spark의 분산 처리 능력을 활용하면서도 429 에러를 최소화할 수 있습니다.