DeepSeek Search API: Preise und Limits (Leitfaden 2026)

Mit $0.75 pro 1.000 erfolgreichen Requests ist die DeepSeek Search API günstig – entscheidend ist aber nicht allein der Preis. Sowohl Search als auch Fetch sind pro Account auf jeweils 5 Requests pro Sekunde begrenzt. Für kostensensible Agenten ist das attraktiv, sofern doppelte Fetches, Retries, Quellenabdeckung und der Tokenverbrauch des Modells sauber gesteuert werden.

Die passende Wahl auf einen Blick

Diese Funktionen bietet die direkte API

DeepSeek dokumentiert zwei schreibgeschützte JSON-Endpunkte. Die Authentifizierung ist identisch: Sende Authorization: Bearer <DeepSeek API Key> und Content-Type: application/json an api.deepseek.com.

Die direkte API ist vom gehosteten Chat-Produkt getrennt. Ein DeepSeek API Key sorgt nicht dafür, dass eine gewöhnliche Chat-Completions-Anfrage automatisch im Web sucht. Deine Anwendung muss Search oder Fetch selbst aufrufen – oder eine von DeepSeek dokumentierte Client-Integration verwenden, die die Tool-Schicht bereitstellt.

Search und Fetch im Vergleich

Search erwartet eine verpflichtende query mit 1 bis 128 Unicode-Zeichen. Optional sind unter anderem count von 1 bis 50, ori_question, ein IP-basierter localization-Wert sowie need_content. Standardmäßig gilt count 10 und need_content ist false.

Mit need_content: true kann Search den Seitentext im Feld content jedes Ergebnisses liefern. Ist der Inhalt vorhanden, kann das einen separaten Fetch-Aufruf sparen. Verlass ist darauf jedoch nicht: Nicht verfügbare oder blockierte Seiten können weiterhin ein leeres Content-Feld zurückgeben.

Fetch ist für eine URL gedacht, die bereits ausgewählt wurde. Der Endpunkt liefert Markdown, allerdings wird pro Request nur eine URL übergeben. Laut DeepSeek hängt der Abruf von Verfügbarkeit und Zugriffsrichtlinien der Zielseite ab. Ein erfolgreiches Search-Ergebnis garantiert daher keinen erfolgreichen Fetch.

Search-Ergebnisse enthalten einen rerank_score von 0 bis 3 und eine authority-Stufe von -1 bis 4. Die Dokumentation bezeichnet Scores ab 1.5 und Authority-Werte ab 3 als Signale für hohe Qualität. Es handelt sich dabei um Servicemetadaten, nicht um unabhängige Benchmarks für die Suchqualität.

Die Abfragesyntax unterstützt praktische Filter wie site:, -site:, exakte Phrasen in Anführungszeichen, lang:, after: und before:. Zum Beispiel:

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

Preise mit Einfluss auf die Architektur

DeepSeek berechnet für Search und Fetch jeweils $0.75 pro 1.000 erfolgreiche Requests, also $0.00075 pro abrechenbarem Request. Die Abrechnung erfolgt pro Request, nicht nach Tokens und nicht anhand der Anzahl zurückgegebener Ergebnisse. Details stehen auf der offiziellen Preisseite.

Die Endpoint-Gebühr deckt nicht die gesamten Kosten einer KI-Rechercheaufgabe ab: Eingabe- und Ausgabetokens des Modells sowie zusätzliche Agent-Schritte rund um die Recherche werden separat berechnet.

Eine realistische Kostenformel

Für einen einfachen Workflow ergibt sich der Rechercheanteil aus:

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

Ein Batch mit 10.000 Suchanfragen kostet $7.50, wenn jede Search-Anfrage Ergebnisse liefert. Ruft die Anwendung für jedes Ergebnis eine Seite ab, kommen bei weiteren 10.000 erfolgreichen Fetch-Aufrufen $7.50 hinzu – noch vor den Modell-Tokens. Die Abfrage von 50 Ergebnissen vervielfacht den Request-Preis nicht, kann aber die Textmenge erhöhen, die das Modell verarbeiten muss.

Deshalb sollte es für need_content eine klare Strategie geben. Für kleine Seitenmengen ist die Option sinnvoll; wenn zunächst nach Score, Domain, Datum oder Authority gefiltert werden soll, empfiehlt sich metadata-only Search mit anschließendem selektiven Fetch.

@haolv511482 berichtete: „Check the content field before adding a fetch loop. Search can return page text with need_content=true ... Otherwise your agent may pay to read the same page twice.” Quelle

Limits und Fehlerfälle für die Architektur

Der offizielle Leitfaden nennt maximal 50 Ergebnisse pro Search-Request sowie getrennte Quoten von 5 Requests pro Sekunde und Account für Search und Fetch. Auch ein Deployment mit mehreren Workern benötigt daher Endpoint-spezifische Limiter.

Besonders bei Fetch hängt viel vom Verhalten der Zielseite ab. Die offizielle Dokumentation garantiert lediglich die Verfügbarkeit der Zielseite und die geltenden Zugriffsrichtlinien. Sie verspricht weder JavaScript-Ausführung noch Browser-Sitzungen, eine User-Agent-Auswahl, Screenshots oder die Erhaltung von Roh-HTML. In einem frühen Test berichtete @jiangkoumo_, dass stark JavaScript-gerenderte Seiten 404 liefern konnten, während eine gewöhnliche öffentliche Seite zu Markdown konvertiert wurde. Quelle

Die frühen Tests zeigten zudem einen wichtigen Zielkonflikt bei der Abdeckung. @bei351009016 meldete über 29 Anfragen und 12 Plattformen hinweg nur 2.1% Überschneidung mit Exa. DeepSeek sei schnell und aktuell bei chinesischen Quellen, bei WeChat und YouTube jedoch schwach. Quelle

Diese frühen Tests sind als Tendenz zu verstehen. Prüfe die Quellenarten, die deine Anwendung tatsächlich benötigt, selbst.

Minimales Implementierungsmuster

Dieses Beispiel trennt Recherche und Antwortgenerierung, vermeidet einen Fetch-Aufruf, wenn Search bereits Inhalte geliefert hat, und taktet die Aufrufe für diesen Prozess auf 5 pro Sekunde. Bei mehreren Workern ist weiterhin ein gemeinsamer Limiter erforderlich.

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))

Wann DeepSeek allein nicht die richtige Wahl ist

Für günstige Recherche ist DeepSeek eine starke Option, besonders wenn dein Korpus chinesische Quellen umfasst und deine Anwendung mit dem Account-Limit von 5 QPS auskommt. Als alleiniger Anbieter ist der Dienst weniger geeignet, wenn der Workload auf YouTube, WeChat, stark clientseitig gerenderte Seiten oder das Ranking einer bestimmten Suchmaschine angewiesen ist.

Eine hybride Architektur ist besser zu begründen:

1. Breite, günstige Discovery-Anfragen an DeepSeek senden.
2. Nach Domain, Datum, Authority und Rerank-Score filtern.
3. Für Quellenklassen, die DeepSeek verfehlt, einen zweiten Anbieter einsetzen.
4. Nur ausgewählte URLs abrufen.
5. Die Beleglage der Antwort mit dem gespeicherten Quelltext abgleichen.

Auch die Datenverarbeitung ist eine relevante Deployment-Entscheidung. Prüfe die aktuellen Bedingungen von DeepSeek und deine Compliance-Anforderungen, bevor sensible Anfragen übermittelt werden; Bedenken aus der Community belegen keine konkrete Aufbewahrungsrichtlinie. Quelle

Checkliste vor dem Produktivstart

1. Search- und Fetch-Aufrufe getrennt protokollieren, damit die Rechnung nachvollziehbar bleibt.
2. Vor dem Abruf einer von Search gelieferten URL das Feld content prüfen.
3. Einen gemeinsamen 5-QPS-Limiter über alle Worker und Subagenten hinweg erzwingen.
4. Nur 408-, 429- und temporäre 5xx-Antworten erneut versuchen.
5. URL, Titel, Datum, Authority, Rerank-Score und Abrufzeit speichern.
6. Nicht unterstützte Schemes und Private-Network-URLs in jedem nutzergesteuerten Fetch-Pfad ablehnen.
7. Seitentext als nicht vertrauenswürdige Daten behandeln, nicht als Tool-Anweisung.
8. Ein Testset mit offiziellen englischen Seiten, chinesischen Quellen, Foren, Videoseiten und JavaScript-lastigen Websites ausführen.
9. Die Gesamtkosten pro Aufgabe inklusive Modell-Tokens und Retries messen, statt nur den Search-Preis auszuweisen.

FAQ zur DeepSeek Search API

Ist die API automatisch über OpenAI-kompatible Aufrufe verfügbar?

Der direkte Search-Endpoint ist eine separate Route: POST /v1/tools/search. Eine gewöhnliche Modellanfrage durchsucht das Web nicht allein deshalb, weil der Client eine OpenAI-kompatible Base URL verwendet. Binde die Search-/Fetch-Aufrufe selbst ein oder nutze eine von DeepSeek dokumentierte Client-Integration.

Ist DeepSeek Search der beste Ersatz für jeden Suchanbieter?

Nein. Die API ist eine überzeugende, kostengünstige Retrieval-Option, doch frühe Nutzertests zeigten eine andere Abdeckung als Exa sowie Lücken bei YouTube und WeChat. Bevor DeepSeek zum alleinigen Anbieter wird, sollte ein kleiner, workloadspezifischer Test erfolgen.