Ein Modellwechsel sollte eine Entscheidung aus Geschäftskennzahlen sein, nicht das Verfolgen neuer Veröffentlichungen. DeepSeek hat eigene Stärken bei chinesischer Sprache, Code und Kostenkontrolle, ist aber nicht für jede Aufgabe die richtige Antwort. Teams müssen zuerst klären, ob das aktuelle Problem an der Modellfähigkeit liegt oder an Retrieval, Prompting, Parallelität, Netz oder Compliance. Nur im ersten Fall lohnt ein Modellwechsel; im zweiten wandert das Problem mit.
Dieser Artikel gibt eine Entscheidungsreihenfolge: sechs Signale prüfen, Nicht-Modell-Probleme ausschließen, dann mit derselben Aufgabenmenge Alternativen vergleichen und schließlich über vollständigen Wechsel, teilweises Routing oder Verbleib bei DeepSeek entscheiden. Modelle und Preise richten sich nach den Modellpreisen.
Hinweis: DeepSeek, Claude, GPT, GLM, Qwen und weitere Namen sind Marken der jeweiligen Inhaber. Dieser Artikel dient der technischen Auswahl. Fähigkeiten, Preise und Bedingungen ändern sich; vor dem Einkauf die offiziellen Seiten prüfen.
1. Sechs Signale für einen möglichen Modellwechsel
| Signal | Konkretes Bild | Zuerst prüfen | Ergebnis |
|---|---|---|---|
| Qualitätsgrenze | dieselben Aufgaben scheitern wiederholt, Prompt-Änderungen helfen nicht | Evaluationsset, Kennzeichnungsstandard, Retrieval-Qualität | Wechsel erwägen |
| Kontext zu kurz | Dokumente müssen vollständig hinein, um korrekt zu antworten | Chunking, Zusammenfassung, Retrieval-Augmentierung | zuerst Architektur ändern |
| Latenz zu hoch | p95 überschreitet die Geschäftstoleranz | Netz, Parallelität, Ausgabelänge | zuerst optimieren |
| Häufige Ratenbegrenzung | 429 nimmt in Spitzenzeiten deutlich zu | Kontingent, geteilte Keys, Retry-Strategie | zuerst Governance |
| Fähigkeitslücke | Multimodalität oder bestimmte Tool-Aufrufe nötig | offizielle Fähigkeitsliste und Versionshinweise | Wechsel oder Multi-Modell erwägen |
| Compliance-Anforderung | Daten dürfen bestimmte Wege oder Regionen nicht passieren | Rechtsabteilung, Datenklauseln, Branchenregeln | Auswahl nach Compliance |
| unpassende Kostenstruktur | lange Ausgaben, wenige Cache-Treffer, hoher Preisanteil | Verhältnis Input/Output, Retry-Anzahl | erst Kosten senken, dann bewerten |
Signale müssen auf Daten beruhen, nicht auf „fühlt sich nicht gut an“. Mindestens eine Woche Fehlerquote, manuelle Nacharbeit, p95-Latenz und 429-Anzahl betrachten, bevor ein Auswahlprozess beginnt.
2. Zuerst „kein Modellproblem“ ausschließen
Vor dem Wechsel eine Selbstprüfung in dieser Reihenfolge:
- Hat der Prompt klare Abnahmekriterien? Ohne Standard lässt sich bei keinem Modell beurteilen, ob es besser ist.
- Findet das Retrieval die richtigen Passagen? Bei falschem RAG-Abruf kann auch ein stärkeres Modell nur erfinden.
- Wird das ganze lange Dokument hineingegeben? Ein zu langer Kontext erhöht Latenz und Kosten und verwässert Schlüsselinformationen.
- Wird für jede Anfrage ein Reasoning-Modell verwendet? Einfache Klassifikation und Extraktion werden damit langsam und teuer.
- Teilen mehrere Dienste einen Key? Gegenseitige Verdrängung wirkt wie „instabiles Modell“.
- Sind Modellname oder Version falsch? 404 und Fähigkeitsunterschiede sind manchmal reine Konfigurationsfragen.
Wenn eines dieser sechs Probleme klar vorliegt, zuerst beheben und dann erneut evaluieren. Viele Schlussfolgerungen „wir brauchen ein anderes Modell“ lösen sich nach diesem Schritt auf.
3. Vier Kategorien von Alternativen
| Typ | Beispiele | Vorteile | Kosten | Geeignet für |
|---|---|---|---|---|
| weitere inländische Allround-Modelle | GLM, Qwen, Doubao u. a. | chinesische Sprachqualität, inländische Zahlung, niedrige Latenz | unterschiedliche Fähigkeiten, Tests nötig | inländisches Geschäft mit klaren Compliance-Anforderungen |
| internationale Modelle | Claude, GPT, Gemini | komplexes Reasoning, Code, Ökosystem | Zugang, Zahlung, Datencompliance | anspruchsvolle Aufgaben, Auslandsgeschäft |
| Open-Source-Betrieb | offene Gewichte wie Qwen, Llama | Datenkontrolle, Anpassbarkeit, Private Deployment | GPU, Betrieb, Engineering | eigene Infrastruktur und Datenisolation |
| Multi-Modell-Gateway | ZSQH AI Gateway | ein Einstieg, einheitliche Abrechnung, wechselbare Modelle | Abhängigkeit von der Verfügbarkeit des Anbieters | Teams mit mehreren Modellanbietern |
Auswahl ist keine Rangliste, sondern Aufgabenabgleich. Chinesischer Kundenservice, Massenextraktion, Code-Vervollständigung und komplexes Reasoning stellen völlig unterschiedliche Anforderungen; ein einheitliches Bewertungsschema führt oft zu falschen Schlüssen.
4. Ersetzung mit derselben Aufgabenmenge bewerten
- Aus dem realen Geschäft 30–50 Aufgaben ziehen und einfache, mittlere und schwere Fälle abdecken.
- Für jede Aufgabe Abnahmekriterien formulieren; Blindbewertung durch zwei Personen ist besser.
- Altes und neues Modell mit denselben Eingaben und identischen Parametern laufen lassen.
- Qualitätsbewertung, p50/p95-Latenz, Input- und Output-Token, Fehlerquote und Retry-Anzahl erfassen.
- Kosten „je erfolgreich abgeschlossener Aufgabe“ berechnen, nicht den Listenpreis je Million Token.
- Fehlerbeispiele aufbewahren und einordnen, ob Fähigkeit, Prompt oder Daten die Ursache sind.
| Kennzahl | Erfassung | Entscheidungsnutzen |
|---|---|---|
| Erfolgsquote | manuelle Bewertung nach Abnahmekriterien | Erreichen der Geschäftsmindestanforderung |
| Nacharbeitsquote | Anteil mit manueller Korrektur | versteckte Personalkosten |
| Latenzausläufer | p95, p99 | Auswirkung auf Nutzererlebnis |
| Token-Struktur | Input, Output, Cache-Treffer | Ursache der Kostenunterschiede |
| Fehlerquote | Anteil 4xx, 5xx, Timeouts | Produktionsstabilität |
| Migrationsaufwand | Konfigurations- oder Codeänderung | Zeit bis zum Start |
Modellname und Base URL in die Konfiguration legen, sodass beim Wechsel nur Umgebungsvariablen geändert werden:
import os
from openai import OpenAI
BASE_URL = os.environ.get("API_BASE_URL", "https://ai.zhongshangqihang.com/v1")
MODEL = os.environ.get("API_MODEL", "deepseek-chat")
client = OpenAI(
api_key=os.environ["API_KEY"],
base_url=BASE_URL,
)
resp = client.chat.completions.create(
model=MODEL,
messages=[{"role": "user", "content": "Extrahiere aus diesem Kundendialog JSON"}],
max_tokens=512,
)
print(resp.choices[0].message.content)
Ist das Zielmodell nicht OpenAI-kompatibel, wird eine Adapterschicht benötigt; ist es kompatibel, besteht die Migration meist aus drei Konfigurationsänderungen. Maßgeblich für Modellnamen ist die Preisseite; alte Anleitungen nicht unverändert übernehmen.
5. Migrationsschritte
- Version, Parameter und Prompt des aktuellen Modells einfrieren und eine rückrollbare Konfiguration sichern.
- Das neue Modell zunächst im Parallelbetrieb ohne echten Verkehr laufen lassen und nur Ausgaben vergleichen.
- 5–10 % des Verkehrs schrittweise umstellen und Erfolgsquote, Latenz und Fehlerquote beobachten.
- Ein Ausweichmodell oder einen Ausweichkanal vorbereiten, damit bei Ausfall des Hauptmodells automatisch gewechselt wird.
- Monitoring nach Modell, Szenario und Version trennen, damit Unterschiede sichtbar bleiben.
- Rückrollbedingungen definieren; bei Überschreiten der Schwellen zurückwechseln statt aus Gefühl festzuhalten.
- Nach der Migration Dokumentation aktualisieren mit Modellname, Parametern, bekannten Unterschieden und Ansprechpartnern.
6. Wann ein Wechsel nicht sinnvoll ist
- Nur eine neue Modellveröffentlichung gesehen, ohne Geschäftskennzahl als Grundlage.
- Kein Evaluationsset, nur einige Dialoge als Entscheidungsbasis.
- Das Problem liegt in Retrieval, Prompt, Parallelität oder Netz; ein Modellwechsel löst es nicht.
- Das Team hat weder GPU noch Betriebskompetenz, will aber ein offenes Modell selbst betreiben.
- Datencompliance ist ungeklärt; ein Wechsel vor der Klärung vergrößert das Risiko.
Robuster ist teilweises Routing: Das Hauptmodell bearbeitet weiter chinesische Massenaufgaben, während komplexes Reasoning, Code-Review oder multimodale Anfragen nach Aufgabentyp an andere Modelle gehen. Die Routing-Regeln liegen im Gateway oder in der Anwendungsschicht und wählen nach Aufgabenlabel, statt alles umzustellen.
| Aufgabentyp | Empfehlung | Grund |
|---|---|---|
| chinesischer Kundenservice, Zusammenfassung, Umschreibung | Hauptmodell | hohes Volumen, Stabilität und Kosten zuerst |
| komplexes Reasoning, Architektur-Review | leistungsfähigeres Modell | ein korrekter Lauf ist günstiger als wiederholte Nacharbeit |
| Klassifikation und Extraktion mit hoher Parallelität | leichtes Modell | Latenz und Kosten zuerst |
| sensible Daten, Private Deployment | Open-Source-Betrieb | Daten verlassen das interne Netz nicht |
Häufige Fragen
Wie wählt man zwischen DeepSeek, Claude und GPT?
Nach Aufgabe, nicht nach Bekanntheit. Für chinesische Massenverarbeitung und kostensensible Fälle kann DeepSeek zuerst geeignet sein; bei komplexem Reasoning, Code und bestimmten Ökosystemanforderungen erst mit einem Evaluationsset vergleichen. Ein Einzelfall ersetzt keine systematische Bewertung.
Wie viel Code muss bei einem Modellwechsel geändert werden?
Ist das Zielmodell OpenAI-kompatibel, meist nur Base URL, Key und Modellname. Werden herstellerspezifische Parameter, Tool-Formate oder multimodale Felder genutzt, sind eine Adapterschicht und Regressionstests nötig.
Können zwei Modelle gleichzeitig verwendet werden?
Ja. Üblich ist ein Hauptmodell mit Ausweichmodell oder Routing nach Aufgabentyp. Der Preis ist die Pflege zweier Evaluations-, Monitoring- und Abrechnungsschemata; dafür braucht es eine verantwortliche Person.
Ist Selbstbetrieb mit offenen Modellen immer günstiger?
Nicht unbedingt. GPU, Bandbreite, Betrieb, Modellupdates und Personal müssen eingerechnet werden. Bei geringem Volumen liegen die Gesamtkosten meist über der nutzungsbasierten Zahlung; Datenisolation und Anpassbarkeit sind die eigentlichen Gründe für Selbstbetrieb.
Was tun, wenn die Qualität nach dem Wechsel sinkt?
Zuerst anhand der Fehlerbeispiele klären, ob Fähigkeit oder Prompt die Ursache ist, dann mit einem festen Evaluationsset vergleichen. Das alte Modell als Rückrolloption behalten und während der schrittweisen Umstellung klare Rückrollschwellen setzen; nicht auf einmal vollständig wechseln.
Nächster Schritt
Im ZSQH AI Gateway einen Test-Key anlegen, DeepSeek und die Kandidatenmodelle über denselben Einstieg anbinden, eine Runde mit derselben Aufgabenmenge vergleichen und die Kosten anhand der Modellpreise berechnen. Maßgeblich für die Verfügbarkeit ist die Preisseite.
Weiterlesen:
