Guiden till DeepSeek API-integration: Öppnande av OpenAI-kompatibla begäran genom ECAIX

Denna guide visar hur du kan testa en DeepSeek-modell-ID genom ECAIX med hjälp av en OpenAI-kompatibel API-ändpunkt. Den omfattar den minsta fungerande begäran, exempel i Python och curl, modell-ID-verifiering, strömning, strukturerad utmatning, verktyg och en diagnostisk väg för vanliga fel.

Guiden beskriver ECAIX-gateway tillgång till en modell-ID som visas i den nuvarande ECAIX-katalogen. Den gör inte anspråk på att ECAIX är officiell DeepSeek-API-ändpunkt eller att alla DeepSeek-funktioner är tillgängliga genom alla gateway-vägar. Kontrollera den levande modellsidan och leverantörsdokumentationen innan du flyttar en arbetslast till produktionsmiljö.

Snabbstart

Använd följande sekvens om du redan har en OpenAI SDK-application:

1. Öppna DeepSeek v4.1 Flash-modellsidan och bekräfta att ID:n är tillgänglig.
2. Skapa ett ECAIX API-nummer.
3. Sätt den OpenAI-kompatibla basurlen till https://ecaix.com/api/ai/v1.
4. Bevara SDK och applikationskoden så mycket som möjligt oförändrad.
5. Utför den minsta begäran nedan.
6. Lägg till strömning, JSON-utmatning eller verktyg först efter att den grundläggande begäran fungerat.

Endpoint och modell-ID

För OpenAI-kompatibla klienter använda:

Base URL: https://ecaix.com/api/ai/v1
Model:    deepseek-v4.1-flash

Modell-ID:n är inte en permanent löfte i en bloggpost. Bekräfta den på levande modellsidan innan varje ny integration eller deployment. Om du behöver en annan DeepSeek-familjemedlem kopiera den exakta ID:n från modellsidan istället för att gissa en suffix.

Endpunktsformatet är också viktigt. SDK:n ska få basvägen som slutar på /v1; klienten lägger till /chat/completions eller en annan operativ väg. Använd inte /chat/completions till base_url när SDK:n redan lägger till den.

Python med OpenAI SDK

Installera eller uppgradera OpenAI Python SDK i ditt virtuella miljö:

python -m pip install --upgrade openai

Använd sedan ECAIX basurl och API-nummer:

const client = new OpenAI({
  apiKey: process.env.ECAIX_API_KEY,
  baseURL: "https://ecaix.com/api/ai/v1",
});

const response = await client.chat.completions.create({
  model: "deepseek-v4.1-flash",
  messages: [
    { role: "user", content: "Return one short sentence about API testing." },
  ],
  max_tokens: 128,
});

console.log(response.choices[0].message.content);

Använd server-sida kod för API-begäran. En webbläsarapplikation bör ringa till din egen backend istället för att exponera ett ECAIX-nummer i klient-sida JavaScript.

Curl-diagnostisk begäran

Om SDK:n misslyckas, ta bort SDK:n från ekvationen och testa endpunkten direkt. Spara hälften och kroppen separat så att du kan skilja på ett HTTP-fel från ett responsformat-fel.

curl -sS -D /tmp/ecaix-deepseek-headers.txt \
  -o /tmp/ecaix-deepseek-response.json \
  -w '\nHTTP %{http_code}\n' \
  "https://ecaix.com/api/ai/v1/chat/completions" \
  -H "Authorization: Bearer ${ECAIX_API_KEY}" \
  -H "content-type: application/json" \
  -d '{
    "model": "deepseek-v4.1-flash",
    "messages": [
      {"role": "user", "content": "Reply with one short sentence."}
    ],
    "max_tokens": 128
  }'

Försök inte att kopiera och klistra in de sparade hälften eller responsen i en offentlig bugg utan att ta bort API-nummer, begärans-ID, promptar, repositorypat, och kunddata.

Hur man diagnostiserar responsen

Använd följande ordning:

1. HTTP-status: bestäm om begäran nådde en giltig endpoint.
2. Respons kropp: läsa leverantörens eller gatewayns felkod.
3. Modell-ID: kopiera den exakta ID:n från den nuvarande modellsidan.
4. Autentisering: kontrollera autentiseringshuvud, konto och tillåtelser.
5. Begärans form: minska kroppen till model, messages och en liten begränsning för utmatning.
6. Funktionella fält: lägg till strömning, JSON eller verktyg en efter en.
7. SDK-beteende: jämför SDK-begäran med den direkta curl-begäran.

Det här förhindrar att en klientbibliotek-issue förväxlas med modellruttering eller konto tillåtelser.

Strömmande responser

Om applikationen behöver incrementell utmatning, lägg till strömning först efter att en normal begäran lyckats:

stream = client.chat.completions.create(
    model="deepseek-v4.1-flash",
    messages=[{"role": "user", "content": "Summarize API retries in three points."}],
    stream=True,
    max_tokens=256,
)

for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

Det exakta beteendet för händelser beror på endpunkten och SDK:n. Kontrollera hur din ramverkshantering hanterar en tom delta, en slutlig användningshändelse, förbindelseavbrott och [DONE]-liknande avslutning. Använd inte en strömningsimplementering som är produktionsklar förrän du har testat avbrott och retryer.

Strukturerad utmatning och JSON

Om du behöver maskinläst utmatning, börja med en vanlig begäran och lägg sedan till den minsta stödda strukturerade-utmatningsalternativet som stöds av endpunkten och modellen. Validera den återvändande innehållet med en riktig JSON-parsare. En prompt som säger "returera JSON" är inte detsamma som en schema-styrd respons.

import json

response = client.chat.completions.create(
    model="deepseek-v4.1-flash",
    messages=[
        {
            "role": "user",
            "content": "Return a JSON object with keys title and priority."
        }
    ],
    response_format={"type": "json_object"},
    max_tokens=128,
)

payload = json.loads(response.choices[0].message.content)
print(payload["title"])

Om response_format accepteras kan det bero på modellen och vägen. Om endpunkten återför en felaktig-parametrar-felmeddelande, ta bort fältet och kontrollera väg-dokumentationen innan du försöker ett annat format.

Funktion kallning och verktyg

Verktygsanvändning kräver en separat test jämfört med textgenerering. Börja med en harmlös funktion och inspektera den återvändande namnet och argumenten innan du utför något.

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_demo_status",
            "description": "Return a fixed status for a local compatibility test.",
            "parameters": {
                "type": "object",
                "properties": {},
                "additionalProperties": False,
            },
        },
    }
]

response = client.chat.completions.create(
    model="deepseek-v4.1-flash",
    messages=[{"role": "user", "content": "Check the demo status."}],
    tools=tools,
    tool_choice="auto",
    max_tokens=128,
)

print(response.choices[0].message.tool_calls)

En modell kan returnera en giltig textrespons medan verktygsanvändning misslyckas på grund av schemaomvandling, icke-stödda parametrar eller klientspecifikt beteende. Utför aldrig återvändade verktygsargument mot en produktionsmiljö utan att validera schemat och lägga till auktorisationskontroller.

OpenAI-kompatibla och Anthropic-kompatibla vägar

ECAIX exponerar olika kompatibilitetsytor för olika klienter:

Läs Chat Completions-dokumentationen, Responses-dokumentationen och Anthropic Messages-dokumentationen innan du väljer en väg. Den samma modell-ID kan inte exponera identiska fält eller beteenden på varje kompatibilitetsyta.

Nuvarande modellspecifikationer

Använd levande detaljsidor för kapacitets- och tillgänglighetskontroll:

• DeepSeek v4.1 Flash
• DeepSeek v4 Pro 202606
• Qwen 3.8 Flash
• GLM 5.3

Dessa sidor är mer pålitliga än en statisk artikel för aktuella modell-ID:n, kontextinformation och prisinformation.

Vanliga fel

Säkerhet och produktionschecklista

För att gå vidare från en testprojekt, bekräfta:

• API-nummer lagras server-sida och kan roteras.
• Promptar och respons inte innehåller godkända hemligheter eller kunddata.
• Du förstår om gateway-loggar begär och hur lång tid loggar behålls.
• Modelltillgänglighet och

Validering innan produktion och hantering av API-nycklar och tillstånd

När du integrerar med DeepSeek API är det viktigt att genomföra en grundlig pre-produktionsvalidering för att säkerställa att systemet fungerar på förväntat sätt i en säker och kontrollerad miljö. Detta inkluderar att verifiera API-anrop, hantera känsliga uppgifter och hantera eventuella felhanteringsfall som kan uppstå under drift.

API-nyckelhantering och säkerhet

DeepSeek API-användare hanterar sina API-nycklar via en säker autentiseringsmekanism. Det är viktigt att:

• Lagra API-nycklar säkert i en miljö som stöder säker lagring, till exempel en secrets manager eller en kryptografisk säkerhetsbox (HSM). Undvik att lagra nycklar i versionkontrollsystem eller i klientkoden.
• Använd en ny API-nyckel per miljö (till exempel utvecklingsmiljö, testmiljö och produktionsmiljö) för att minimera risken för oavsiktlig exponering.
• Restriera tillgången till API-nycklar genom att begränsa tillgången till endast nödvändiga tjänster och användare.

Modell-ID-verifiering och endpoint-kontroll

För att undvika felaktiga anrop eller missförstådda modeller är det viktigt att:

• Välj rätt modell-ID vid anrop. Verifiera att du använder den korrekta modellen (till exempel text-embedding-001, text-generation-2.0, eller multimodal-1.0) innan du skickar anrop.
• Kontrollera API-dokumentationen för att säkerställa att du använder rätt endpoint och parametrar. Endpointnamn som /v1/models/{model_id}/... kan variera beroende på version och ändringar från DeepSeek.
• Testa modeller i olika scenarier innan du implementerar dem i produktion, särskilt om du använder modeller som stöder multimodal input eller långa textprocessering.

Loggning av anrop utan känsliga uppgifter

För att underlätta felsökning och övervakning är det viktigt att logga API-anrop på ett säkert sätt:

• Exkludera känsliga uppgifter från loggfilerna, till exempel API-nycklar, personuppgifter eller inkommande text som kan identifiera användare.
• Logga endast nödvändiga detaljer, såsom:
  • Anrops-ID (om tillgängligt)
  • Endpoint och modell-ID
  • Statuskod och eventuella felmeddelanden
  • Timestamps för anrop och svar
• Använd en loggningstjänst som stöder säker lagring (till exempel Cloud Logging, ELK-stack eller en egen säker loggserver) för att undvika exponering av känsliga data.

Felhantering och retry/idempotens

DeepSeek API kan ibland ge temporära fel, till exempel rate limiting eller tidsbaserade restriktioner. För att hantera detta effektivt:

• Implementera retry-logik för temporära fel (till exempel HTTP-statuskoder 429 eller 500). Använd exponenserande backoff för att undvika att överbelasta API:t.
• Använd idempotens för anrop som kan upprepas utan att ha negativa effekter (till exempel generering av en unik ID eller uppdatering av en bestående resurs).
• Testa retry-mekanismen i en testmiljö innan du implementerar den i produktion för att säkerställa att anrop återställs korrekt utan att förlora viktig data.

Streaming och avbrott

Om din applikation använder streaming-funktioner (till exempel för realtidssvar eller generering av långa texter) är det viktigt att hantera avbrott och återanslutning:

• Testa avbrott under streaming genom