DeepSeek Search API 요금과 제한 사항 (2026 가이드)

DeepSeek Search API는 성공한 요청 1,000건당 $0.75로 가격만 보면 상당히 저렴하다. 다만 실제 도입 판단에서는 요금보다 Search와 Fetch에 각각 걸린 계정당 초당 5건 제한이 더 중요하다. 중복 Fetch, 재시도, 소스 커버리지, 모델 토큰 사용량을 잘 제어할 수 있다면 저비용 에이전트용 검색 계층으로 매력적인 선택지다.

한눈에 보는 선택 기준

Raw API에서 제공하는 기능

DeepSeek는 읽기 전용 JSON 엔드포인트 두 개를 문서화하고 있다. 인증 방식은 동일하다. api.deepseek.com에 Authorization: Bearer <DeepSeek API Key>, Content-Type: application/json 헤더를 전송하면 된다.

Raw API는 호스팅되는 채팅 제품과 별개다. DeepSeek API 키가 있다고 해서 일반 Chat Completions 요청이 자동으로 웹을 탐색하는 것은 아니다. 애플리케이션에서 Search 또는 Fetch를 직접 호출하거나, 도구 계층을 제공하는 문서화된 클라이언트 통합 방식을 사용해야 한다.

Search와 Fetch는 어떻게 나뉘나

Search의 필수값인 query는 1~128자의 Unicode 문자로 구성한다. 선택 필드로는 1~50 범위의 count, ori_question, IP 기반 localization 값, need_content가 있다. 기본 count는 10이며 need_content의 기본값은 false다.

need_content: true를 지정하면 Search는 각 결과의 content 필드에 페이지 텍스트를 넣어 반환할 수 있다. 콘텐츠가 제공된 페이지라면 별도의 Fetch 호출을 생략할 수 있다. 다만 보장되는 것은 아니다. 접근할 수 없거나 차단된 페이지는 여전히 빈 content 필드를 반환할 수 있다.

Fetch는 이미 선택한 URL을 읽는 기능이다. Markdown을 반환하지만 요청 하나에는 URL 하나만 전달할 수 있다. DeepSeek는 Fetch가 대상 사이트의 가용성과 접근 정책 영향을 받는다고 명시한다. 따라서 Search 결과가 성공적으로 반환됐다고 해서 Fetch까지 성공하는 것은 아니다.

Search 결과에는 0~3 범위의 rerank_score, -1~4 범위의 authority 등급이 포함된다. 문서에서는 1.5 이상의 점수와 3 이상의 authority 값을 고품질 신호로 설명한다. 이는 서비스가 제공하는 메타데이터일 뿐, 독립적인 검색 품질 벤치마크는 아니다.

쿼리 문법은 site:, -site:, 따옴표 구문, lang:, after:, before: 같은 실용적인 필터를 지원한다. 예를 들면 다음과 같다.

"DeepSeek Search API" site:api-docs.deepseek.com lang:en after:2026-10-01

아키텍처까지 바꾸는 요금 구조

DeepSeek는 Search와 Fetch 모두 성공 요청 1,000건당 $0.75로 책정하고 있다. 청구 대상 요청 1건당 $0.00075에 해당한다. 결과 수나 토큰 수가 아니라 요청 단위로 과금된다. 자세한 내용은 공식 요금 페이지에서 확인할 수 있다.

엔드포인트 요금이 AI 리서치 작업의 전체 비용은 아니다. 검색 전후에 발생하는 모델 입력·출력 토큰과 추가 에이전트 턴은 별도로 과금된다.

현실적인 비용 계산식

단순한 워크플로라면 검색·수집 비용은 다음과 같이 계산할 수 있다.

successful Search calls * $0.00075
+ successful Fetch calls * $0.00075
+ model input and output token charges

모든 Search 요청이 결과를 반환하는 조건에서 Search 10,000건의 비용은 $7.50이다. 애플리케이션이 결과마다 페이지 하나를 Fetch하면 성공 Fetch 10,000건이 추가돼 모델 토큰 비용 전 기준으로 $7.50이 더 든다. Search에서 50개 결과를 요청해도 요청 요금이 배수로 늘지는 않지만, 모델이 처리해야 할 텍스트 양은 커질 수 있다.

그래서 need_content에는 명확한 정책이 필요하다. 대상 페이지가 적다면 이를 사용하고, 점수·도메인·날짜·authority로 먼저 걸러야 한다면 메타데이터만 받는 Search 뒤에 선택적으로 Fetch를 붙이는 편이 좋다.

@haolv511482의 조언도 같다. “Fetch 루프를 추가하기 전에 content 필드를 확인하세요. Search는 need_content=true로 페이지 텍스트를 반환할 수 있습니다. ... 그렇지 않으면 에이전트가 같은 페이지를 두 번 읽는 데 비용을 낼 수 있습니다.” 출처

반드시 설계에 반영할 제한과 실패 유형

공식 가이드상 Search 요청당 최대 결과 수는 50개이며, Search와 Fetch에는 계정별로 각각 초당 5건의 쿼터가 적용된다. 워커를 여러 개 두는 환경에서도 엔드포인트별 제한기를 둬야 한다.

특히 Fetch는 사이트 특성에 민감하다. 공식 문서가 보장하는 범위는 대상 사이트의 가용성과 접근 정책까지다. JavaScript 실행, 브라우저 세션, user-agent 선택, 스크린샷, 원본 HTML 보존은 약속하지 않는다. 초기 테스트에서 @jiangkoumo_는 JavaScript 렌더링 비중이 높은 사이트는 404를 반환할 수 있었지만, 일반 공개 페이지는 Markdown으로 변환됐다고 전했다. 출처

같은 초기 테스트에서는 커버리지 측면의 중요한 상충점도 확인됐다. @bei351009016는 29개 쿼리와 12개 플랫폼에서 Exa와의 중복률이 2.1%에 불과했다고 보고했다. DeepSeek는 중국어 소스에서는 빠르고 최신성이 좋지만 WeChat과 YouTube에는 약하다고 설명했다. 출처

이는 초기 테스트 결과인 만큼 방향성 있는 참고 자료로 보고, 실제 필요한 출처 유형을 기준으로 직접 검증하는 편이 좋다.

최소 구현 패턴

아래 예제는 검색·수집과 답변 생성을 분리하고, Search가 이미 콘텐츠를 반환했다면 Fetch를 건너뛴다. 이 프로세스 안에서는 초당 5건으로 호출 간격도 조정한다. 다만 멀티 워커 배포에서는 공유 제한기가 별도로 필요하다.

import os
import threading
import time
import requests

BASE = "https://api.deepseek.com"
HEADERS = {
    "Authorization": f"Bearer {os.environ['DEEPSEEK_API_KEY']}",
    "Content-Type": "application/json",
}
RATE_LOCK = threading.Lock()
LAST_CALL = 0.0


def post_json(path, payload, attempts=3):
    global LAST_CALL
    for attempt in range(attempts):
        with RATE_LOCK:
            wait = 0.2 - (time.monotonic() - LAST_CALL)
            if wait > 0:
                time.sleep(wait)
            LAST_CALL = time.monotonic()
        response = requests.post(
            BASE + path, headers=HEADERS, json=payload, timeout=30
        )
        if response.status_code in {408, 429, 500, 502, 503, 504}:
            if attempt == attempts - 1:
                response.raise_for_status()
            time.sleep(2 ** attempt)
            continue
        response.raise_for_status()
        return response.json()


search = post_json(
    "/v1/tools/search",
    {
        "query": 'DeepSeek Search API pricing site:api-docs.deepseek.com',
        "count": 10,
        "need_content": True,
    },
)

usable = [
    result for result in search.get("results", [])
    if result.get("rerank_score", 0) >= 1.5
]

for result in usable:
    content = result.get("content") or ""
    if not content:
        fetched = post_json("/v1/tools/fetch", {"url": result["url"]})
        content = fetched.get("content", "")
    # Store title, URL, date, authority, score, and content before summarizing.
    print(result["title"], result["url"], len(content))

DeepSeek 하나만 쓰기 어려운 경우

DeepSeek는 저비용 탐색에 강점이 있으며, 특히 중국어 소스가 포함된 코퍼스와 계정당 5 QPS 제한을 감당할 수 있는 애플리케이션에 잘 맞는다. 반대로 YouTube, WeChat, 클라이언트 렌더링 비중이 높은 페이지 또는 특정 검색 엔진의 순위에 의존하는 워크로드라면 단일 공급자로는 약점이 있다.

다음과 같은 하이브리드 설계가 더 타당하다.

1. 폭넓고 저렴한 탐색 쿼리는 DeepSeek로 보낸다.
2. 도메인, 날짜, authority, rerank score로 결과를 필터링한다.
3. DeepSeek가 놓치는 출처 유형에는 두 번째 공급자를 사용한다.
4. 선택된 URL만 Fetch한다.
5. 저장한 원문을 기준으로 답변의 근거를 대조한다.

데이터 처리 역시 배포 시 결정할 문제다. 민감한 쿼리를 전송하기 전에는 DeepSeek의 최신 약관과 자체 컴플라이언스 요구사항을 검토해야 한다. 커뮤니티의 우려만으로 특정 보존 정책이 입증되는 것은 아니다. 출처

프로덕션 전 운영 체크리스트

1. 청구 내역을 대조할 수 있도록 Search와 Fetch 호출을 분리해 기록한다.
2. Search가 반환한 URL을 Fetch하기 전에 content를 확인한다.
3. 모든 워커와 서브에이전트에 걸쳐 공유되는 5 QPS 제한기를 적용한다.
4. 408, 429, 일시적인 5xx 응답에만 재시도한다.
5. URL, 제목, 날짜, authority, rerank score, 수집 시각을 저장한다.
6. 사용자가 제어할 수 있는 Fetch 경로에서는 지원하지 않는 스킴과 사설 네트워크 URL을 차단한다.
7. 페이지 텍스트는 도구 지시가 아닌 신뢰할 수 없는 데이터로 취급한다.
8. 영어 공식 페이지, 중국어 소스, 포럼, 동영상 페이지, JavaScript 비중이 높은 사이트를 포함한 테스트 세트를 실행한다.
9. Search 가격만 보지 말고 모델 토큰과 재시도를 포함한 전체 작업 비용을 측정한다.

DeepSeek Search API FAQ

OpenAI 호환 호출만으로 API를 자동으로 쓸 수 있나?

아니다. Raw Search 엔드포인트는 별도의 POST /v1/tools/search 경로다. 클라이언트가 OpenAI 호환 base URL을 사용한다는 이유만으로 일반 모델 요청이 웹을 탐색하지는 않는다. Search/Fetch 호출을 직접 추가하거나 DeepSeek가 문서화한 클라이언트 통합 방식을 사용해야 한다.

DeepSeek Search가 모든 검색 공급자를 대체할 최선의 선택인가?

아니다. 비용 효율이 뛰어난 검색·수집 옵션이지만, 초기 사용자 테스트에서는 Exa와 다른 커버리지가 확인됐고 YouTube 및 WeChat 관련 공백도 나타났다. 단일 공급자로 결정하기 전에 실제 워크로드에 맞춘 소규모 테스트를 해보는 것이 좋다.