Am 2026-11-03/04 wurde DeepSeek V4.1 Flash 1017 über AIHubMix mit der vollständigen APB-Suite bei fünf Anbietern getestet: jedes Mal dieselben Fragen, Parameter und Anfrage-Skripte. Dieses APB-Profil behandelt ausschließlich den ByteDance-Lauf, Abschnitt für Abschnitt.
Die folgenden Zahlen sind Ergebnisse, kein Ranking und keine Anbieterempfehlung. Q, F, P, K und R stehen an erster Stelle; der Gesamtwert ist ein zusammenfassender Index, keine Zertifizierung, und verfügt über kein Konfidenzintervall. Die Bewertungsregeln sind im AIHubMix Provider Benchmark Standard v2.0 festgelegt.
Ergebnisse bei fünf Anbietern
Fett markiert den Anbieter dieses Beitrags. Die Anbieterreihenfolge ist fest und stellt kein Ranking dar. K ist ein Teilwert von P und macht 20% davon aus. Der Gesamtwert ist ein zusammenfassender Index ohne Konfidenzintervall. Der Unterschied zwischen dem offiziellen DeepSeek-Kanal und Alibaba Cloud beträgt 0.37; die beiden sind nicht unterscheidbar.
Auf einen Blick
- Q 42.05. BFCL 85.20%, HLE 15.34%, AA-LCR 49.20%. Der Abstand zum offiziellen Kanal beträgt −0.40 Prozentpunkte, mit einem 95%-Intervall von −1.46 bis +0.66: nicht unterscheidbar. Bei AA-LCR traten 28 Anfragenfehler auf, alle in Fenster 1; sie wurden als falsch gewertet.
- F 74.98. 124 von 174 gewerteten Prüfungen bestanden.
reasoning_effort=nonedeaktiviert den Denkmodus nicht. Eine Eingabe mit 10k Token wurde mit 10,026 Token angegeben (nativer Zähler: 10,000); eine Eingabe mit 8 Token wurde mit 34 angegeben. - P 84.37. Erstes Body-Token: Median 2.12 s bei einfacher Parallelität und 2.10 s bei 10-facher Parallelität; TPOT 3.43 ms/Token; alle 180 Geschwindigkeitsanfragen waren gültig.
- K 93.83. Bei 8k trafen die Hot-Anfragen 9/9 Mal den Cache; bei 32k gab es 8 Treffer, und eine Anfrage wurde innerhalb der Frist von 300 s nicht abgeschlossen.
- R 100. Alle 300 dedizierten Anfragen waren beim ersten Versuch erfolgreich.
Testaufbau
| Element | Details |
|---|---|
| Modell | DeepSeek V4.1 Flash 1017 |
| Angeforderte Modell-ID | doubao-deepseek-v4.1-flash-1017 |
| Zurückgegebener Modellname | deepseek-v4-1-flash-261017 |
| Zugriffsweg | Über AIHubMix mit einer anbieterspezifischen Modell-ID, keine direkte Verbindung zum Anbieterkonto |
| Parameter | Denkmodus aus, temperature 1.0, max_tokens 16,384, Timeout 300 s, keine automatischen Wiederholungsversuche |
| Denkmodus aus | Bei den Anfragen zur Antwortqualität, Geschwindigkeit, zum Cache und zur Stabilität wurde das native thinking.type=disabled verwendet (bei diesem Anbieter schaltete reasoning_effort=none den Denkmodus nicht aus); bei den Funktionsfällen blieb reasoning_effort=none gesetzt, um zu prüfen, ob der Parameter wirksam ist |
| Zeit | 2026-11-03 18:07 – 11-04 16:33 UTC+8; fünf Anbieter nutzten denselben Mac mini, dasselbe Netzwerk und dasselbe Konto |
| Stichproben | Antwortqualität: 4,250 Frageinstanzen (BFCL 500 × 3, HLE 250 × 10, AA-LCR 25 × 10); Funktionen: 60 Fälle × 3 Fenster; Geschwindigkeit: 90 bei einfacher und 90 bei 10-facher Parallelität; Stabilität: 300; Cache: 30 (drei Gruppen mit jeweils 8k- und 32k-Präfixen) |
Die Anfragen nutzten den AIHubMix-Pfad Schnellstart mit einer anbieterspezifischen ID; die Parameter richten sich nach der API-Dokumentation von DeepSeek. IDs anderer Anbieter sind auf der Modellseite aufgeführt.
Q — Antwortqualität: 42.05
Die Antwortqualität basiert auf drei Testsuiten: 500 BFCL-Fragen mit jeweils 3 Durchläufen, 250 HLE-Fragen mit jeweils 10 Durchläufen und 25 AA-LCR-Fragen mit jeweils 10 Durchläufen. BFCL wird anhand automatischer Regeln bewertet; HLE und AA-LCR werden vom Modell deepseek-flash beurteilt. Alle fünf Anbieter erhielten dieselben Fragen, und die drei Suiten fließen in eine gemeinsame Genauigkeitsrate ein. Zehn Antworten wurden ausgeschlossen, weil die Frage nicht bewertet werden konnte. Damit blieben 4,240 bewertete Frageinstanzen.
| Testsuite | Fragen | Richtig | Genauigkeit | Fehler |
|---|---|---|---|---|
| BFCL-Tool-Aufrufe | 500 × 3 | 1,278/1,500 | 85.20% | 0 |
| HLE-Fragen und -Antworten mit hohem Schwierigkeitsgrad | 250 × 10 | 382/2,490 | 15.34% | 7 |
| AA-LCR-Reasoning zu langen Dokumenten | 25 × 10 | 123/250 | 49.20% | 28 |
| Kombiniert · 95%-Intervall 39.70%–44.33% | — | 1,783/4,240 | 42.05% | 35 |
Servicefehler – Anfragenfehler oder abgeschnittene Ausgabe – bleiben im Nenner und zählen als falsch. Bei HLE erreichte die Ausgabe 7-mal die Obergrenze von max_tokens; bei AA-LCR traten 28 Anfragenfehler auf, alle in Fenster 1. BFCL wird automatisch bewertet; HLE und AA-LCR werden von einem Judge bewertet.
Jede BFCL-Frage wurde 3-mal beantwortet; die Tabelle summiert die 3 Durchläufe.
| BFCL-Kategorie | Bestanden | Erfolgsrate |
|---|---|---|
| simple_python — eine Funktion, korrekter Aufruf und korrekte Argumente | 329/360 | 91.39% |
| multiple — eine von mehreren Funktionen auswählen | 268/300 | 89.33% |
| parallel — dieselbe Funktion mehrmals aufrufen | 271/300 | 90.33% |
| parallel_multiple — mehrere verschiedene Funktionen aufrufen | 207/240 | 86.25% |
| irrelevance — keine Funktion ist relevant; es sollte kein Aufruf erfolgen | 102/150 | 68.00% |
| ahm_multi_turn — dreistufige Tool-Kette | 101/150 | 67.33% |
Vergleich mit den anderen vier
Abweichung vom offiziellen Kanal in Prozentpunkten, mit dem 95%-Intervall als Fehlerbalken. Wenn ein Intervall die 0 einschließt, wird das Ergebnis als nicht unterscheidbar eingestuft. Der Judge deepseek-flash für HLE und AA-LCR gehört zur selben DeepSeek-Familie wie das getestete Modell und wurde nicht kalibriert; daher könnten seine Bewertungen großzügig ausfallen.
F — Funktionsunterstützung: 74.98
Die Funktionssuite prüft ausschließlich, ob das Schnittstellenverhalten dem Protokoll entspricht, nicht, ob das Modell gute Antworten liefert. 60 Fälle in sechs Gruppen wurden jeweils dreimal, einmal pro Fenster, ausgeführt: 180 Prüfungen, bewertet anhand des Formats, das jeder Anbieter dokumentiert. Nicht anwendbare, ungültige oder nicht beobachtete Prüfungen bleiben außen vor und fließen nicht in den Nenner ein. ByteDance bestand 124 von 174 gewerteten Prüfungen und erzielte mit den Gruppen-Gewichtungen 74.98 Punkte.
Für den gewichteten Wert gelten die Gruppen-Gewichtungen; er entspricht nicht dem Anteil bestandener Prüfungen an 174.
| Gruppe | Gewichtung | Bestanden | Ausgeschlossen | Gruppenwert |
|---|---|---|---|---|
| Streaming- und Nachrichtenprotokoll | 20% | 23/27 | 3 | 85.19 |
| Tool-Schnittstelle | 20% | 30/30 | — | 100.00 |
| Ausgabebeschränkungen und Parameter | 20% | 24/30 | — | 80.00 |
| Kontext und Status | 15% | 14/30 | — | 46.67 |
| Fehler und Wiederherstellung | 15% | 21/30 | — | 70.00 |
| Abrechnungs- und Cache-Protokoll | 10% | 12/27 | 3 | 44.44 |
| Gesamt · gewichteter Wert | — | 124/174 | 6 | 74.98 |
„Fehlgeschlagene Fenster“ gibt an, in wie vielen der 3 Fenster die Prüfung fehlschlug.
| Fehlgeschlagener Fall | Fehlgeschlagene Fenster | Grund |
|---|---|---|
| Reasoning gelangt nicht in den Inhalt — Streaming- und Nachrichtenprotokoll | 3/3 | Bei reasoning_effort=none wurde weiterhin Denkmodus-Inhalt zurückgegeben |
| Denkmodus-Konfiguration wird wirksam — Ausgabebeschränkungen und Parameter | 3/3 | Bei reasoning_effort=none wurde weiterhin Denkmodus-Inhalt zurückgegeben |
| Sampling-Diversität — Ausgabebeschränkungen und Parameter | 3/3 | Die Ausgaben bei temperature 0 und 1 unterschieden sich nicht genug; der vorab festgelegte Schwellenwert wurde unterschritten |
| Lange Eingabe mit 10k — Kontext und Status | 3/3 | Eingabe mit 10,026 Token angegeben; der native Zähler sollte 10,000 ergeben |
| Innerhalb des Kontextlimits — Kontext und Status | 3/3 | Eingabe mit 10,026 Token angegeben; der native Zähler sollte 10,000 ergeben |
| Lange Eingabe mit 32k — Kontext und Status | 3/3 | Eingabe mit 10,026 Token angegeben; der native Zähler sollte 10,000 ergeben |
| Lange Eingabe mit 100k — Kontext und Status | 3/3 | Eingabe mit 10,026 Token angegeben; der native Zähler sollte 10,000 ergeben |
| Über dem Kontextlimit — Kontext und Status | 3/3 | Verbindungsfehler oder Timeout beim Upstream (1); sollte einen Parameterfehler zurückgeben, gab 200 zurück (2) |
| Verlauf mit 12 Dialogrunden — Kontext und Status | 1/3 | Verbindungsfehler oder Timeout beim Upstream |
| Fehlerhaftes messages-Format — Fehler und Wiederherstellung | 3/3 | Gab 400 mit leerem Body zurück; keine strukturierte Fehlererklärung |
| Verwaistes Tool-Ergebnis — Fehler und Wiederherstellung | 3/3 | Sollte einen Parameterfehler zurückgeben, gab 200 zurück |
| Fehlerhaftes stream_options-Format — Fehler und Wiederherstellung | 3/3 | Gab 400 mit leerem Body zurück; keine strukturierte Fehlererklärung |
| Abrechnung von Denkmodus-Token — Abrechnungs- und Cache-Protokoll | 3/3 | Denkmodus-Token wurden angegeben, obwohl der Denkmodus deaktiviert war |
| Nativer Eingabezähler — Abrechnungs- und Cache-Protokoll | 3/3 | 34 Token angegeben; der native Zähler sollte 8 ergeben |
| Tool-Definitionen werden zur Eingabe gezählt — Abrechnungs- und Cache-Protokoll | 3/3 | Schon die Kontrollanfrage ohne Tools wich vom nativen Eingabezähler ab |
| Eingabezähler vor und nach dem Cache konsistent — Abrechnungs- und Cache-Protokoll | 3/3 | Bei Wiederverwendung desselben Präfixes stimmten die angegebenen Eingabe-Token nicht mit dem nativen Zähler überein |
| Eingabe bei Streaming und ohne Streaming konsistent — Abrechnungs- und Cache-Protokoll | 3/3 | Beide gaben 34 Token an; der native Zähler sollte 8 ergeben |
| Exakter Textausgabe — Streaming- und Nachrichtenprotokoll | 1/3 | Ein zusätzlicher Punkt am Ende des Bodys; nicht der angeforderte exakte Text |
Diese Prüfungen bleiben außen vor und zählen weder als bestanden noch als fehlgeschlagen.
| Status | Fall | Anzahl | Grund |
|---|---|---|---|
| Nicht beobachtet | Streaming-Stoppsequenzen | 3 | Nach dem vorherigen Schritt wurde diese Anfrage nicht gesendet; keine Bewertung möglich |
| Nicht anwendbar | Explizites cache_control | 3 | Vorab als von dieser Schnittstelle nicht unterstützt registriert |
Die Fälle mit fehlerhaftem messages-Format und fehlerhaftem stream_options-Format schlugen bei allen fünf Anbietern fehl: Beide gaben 400 mit leerem Body zurück, sodass Clients keine strukturierte Fehlererklärung erhalten. Ein Fehler, der bei allen fünf auftritt, liegt wahrscheinlich auf der Ebene des AIHubMix-Gateways und muss separat untersucht werden. Auch die Abrechnung von Denkmodus-Token schlug bei allen fünf fehl, allerdings aus unterschiedlichen Gründen: ByteDance und Fireworks gaben Denkmodus-Token an, obwohl der Denkmodus deaktiviert war; die anderen drei lieferten keine Anzahl von Denkmodus-Token zurück.
Vergleich mit den anderen vier
P — Antwortgeschwindigkeit: 84.37
Jede Anfrage enthielt etwa 10,000 Eingabe-Token und verlangte etwa 1,100 Token Body-Text als Ausgabe. In jedem der drei Fenster liefen 30 Anfragen mit einfacher und 30 mit 10-facher Parallelität: insgesamt 180 Anfragen.
| Metrik | Ergebnis |
|---|---|
| Wartezeit bis zum ersten Body-Token (TTFA) | Median 2.12 s bei einfacher Parallelität; Median 2.10 s bei 10-facher Parallelität |
| Generierungsgeschwindigkeit (TPOT) | 3.43 ms/Token bei einfacher Parallelität; 3.41 ms/Token bei 10-facher Parallelität |
| Effektiver Durchsatz | 1,250.0 Token/s bei 10-facher Parallelität |
| Gültige Anfragen | 90/90 bei einfacher Parallelität; 90/90 bei 10-facher Parallelität |
| Teilwerte | TTFA 48.59, TPOT 100.00, Durchsatz 100.00; für TTFA und TPOT gilt jeweils der niedrigere Wert der beiden Stufen; Gewichtungen 35% / 35% / 30%; Antwortwert 82.00 |
| P-Wert | Antwortwert 82.00 mit einer Gewichtung von 80%, Cache K 93.83 mit 20%; Gesamt 84.37 |
TPOT wird anhand gestreamter Chunks geschätzt und nicht pro Token auf der Hardware gemessen. Der Durchsatz entspricht den gültigen Ausgabe-Token bei 10-facher Parallelität geteilt durch die Wall-Clock-Zeit des Batches.
Vergleich mit den anderen vier
Alle fünf nutzten dasselbe Gerät, Netzwerk und Konto. Die drei Fenster wurden Anbieter für Anbieter geplant, sodass sich die Erhebungszeiträume nicht vollständig überschneiden; kleine Unterschiede sollten nicht überinterpretiert werden.
K — Cache: 93.83
Jede Gruppe sendet fünf Anfragen. Die erste enthält ein festes Präfix mit etwa 8k oder 32k Token und befüllt den Cache. Bei den Anfragen 2–4 bleibt das Präfix gleich, nur die abschließende Frage ändert sich – nach 5 s, 30 s und 120 s. Die fünfte verwendet ein neues Präfix als Kontrolle ohne Cache. Drei Fenster und zwei Längen mit jeweils fünf Anfragen pro Gruppe ergeben 30 Anfragen. K entspricht den bei Hot-Anfragen gelesenen Cache-Token geteilt durch die Token, die laut den Regeln wiederverwendbar sein sollten; beide Längen werden gleich gewichtet. K macht 20% von P aus.
| Präfix | Fenster | Initialisierung | +5 s | +30 s | +120 s | Kontrolle ohne Cache |
|---|---|---|---|---|---|---|
| 8k | Fenster 1 | 0 | 7,936 | 7,936 | 7,936 | 0 |
| 8k | Fenster 2 | 0 | 7,936 | 7,936 | 7,936 | 0 |
| 8k | Fenster 3 | 0 | 7,936 | 7,936 | 7,936 | 0 |
| 32k | Fenster 1 | 0 | 32,000 | 32,000 | 32,000 | 0 |
| 32k | Fenster 2 | 0 | 32,000 | 32,000 | fehlgeschlagen | 0 |
| 32k | Fenster 3 | 0 | 32,000 | 32,000 | 32,000 | 0 |
Dies sind die vom Server gemeldeten Cache-Lese-Token.
Alle neun Hot-Requests mit 8k trafen den Cache und lasen jeweils 7,936 Token. Acht von neun Hot-Requests mit 32k trafen den Cache und lasen jeweils 32,000 Token; ein Request schlug fehl. K beträgt 93.83, wobei beide Längen gleich gewichtet werden. Bei Cold-Requests wurde kein Cache gelesen, sodass sich Hot und Cold klar unterscheiden. Der fehlgeschlagene Request war der vierte Request der 32k-Gruppe in Fenster 2; er erreichte die Frist von 300 s, ohne abgeschlossen zu werden.
Im Vergleich zu den anderen vier
R — Dienststabilität: 100
Die 300 Requests verteilen sich auf vier Typen – kurze Texte, lange Eingaben, Tool-Aufrufe und Mehrfach-Turn-Verläufe – und wurden in drei Fenstern bei einer Parallelität von 1 ausgeführt. Ein Request zählt nur dann als erfolgreich, wenn der erste Versuch eine gültige, vollständige Antwort lieferte; die Antwortkorrektheit wird nicht geprüft, und es gibt keine Wiederholung. Fehler in den Abschnitten zu Antwortqualität und Geschwindigkeit werden in Q und P gezählt, nicht erneut in R.
| Request-Typ | Erfolg beim ersten Versuch |
|---|---|
| Kurzer Text | 120/120 |
| 10k lange Eingabe | 90/90 |
| Tool-Aufrufe | 60/60 |
| Mehrfach-Turn-Verlauf | 30/30 |
| Gesamt · 95%-Intervall 98.78%–100% | 300/300 |
Alle 300 Requests lieferten beim ersten Versuch eine gültige, vollständige Antwort. R = 100 beschreibt ausschließlich diese 300 eigens dafür ausgeführten Requests; es bedeutet nicht, dass die gesamte Kette fehlerfrei war. Die Untergrenze des 95%-Intervalls liegt bei 98.78%: Bei 300 Erfolgen lässt sich lediglich sagen, dass die Fehlerrate wahrscheinlich unter 1.22% liegt.
Im Vergleich zu den anderen vier
R umfasst nur diese 300 eigens dafür ausgeführten Requests; Fehler in den Abschnitten zu Antwortqualität und Geschwindigkeit werden in Q und P erfasst und nicht erneut in R gezählt.
| Anbieter | Erfolg beim ersten Versuch | 95%-Intervall |
|---|---|---|
| ByteDance | 300/300 | 98.78%–100% |
| Baidu | 300/300 | 98.78%–100% |
| Alibaba Cloud | 300/300 | 98.78%–100% |
| DeepSeek official | 300/300 | 98.78%–100% |
| Fireworks | 300/300 | 98.78%–100% |
FAQ
Hat reasoning_effort=none den Denkmodus tatsächlich nicht ausgeschaltet?
Ja. In allen drei Fenstern lieferten Requests mit reasoning_effort=none weiterhin Denkinhalte; der Test schlug also 3/3-mal fehl. Für die Requests zur Antwortqualität, Geschwindigkeit, zum Cache und zur Stabilität wurde stattdessen der native Schalter thinking.type=disabled verwendet. In der Funktionssuite blieb reasoning_effort=none absichtlich aktiviert, um zu prüfen, ob der Parameter wirksam war.
Die BFCL-Genauigkeit beträgt 85.20%. Warum liegt Q bei 42.05?
Q fasst drei Suites mit sehr unterschiedlichem Schwierigkeitsgrad zusammen. BFCL steuerte 1,278 richtige Antworten von 1,500 bei, HLE 382 von 2,490 und AA-LCR 123 von 250. Insgesamt waren 1,783 von 4,240 bewerteten Frageinstanzen richtig: 42.05%. Die 15.34% von HLE drücken den zusammengefassten Wert nach unten.
Sind die 35 Dienstfehler in Q in der Wertung enthalten?
Ja. Request-Fehler und abgeschnittene Ausgaben bleiben im Nenner und zählen als falsch. Sieben HLE-Antworten wurden bei max_tokens abgeschnitten; 28 AA-LCR-Requests schlugen fehl, alle in Fenster 1.
Warum ist die Abrechnung der Eingabe-Token wichtig?
Weil die Abrechnung mit der nativen Zählung des Modells übereinstimmen sollte. Eine Eingabe mit 10k Token wurde als 10,026 Token gemeldet (nativ: 10,000), eine Eingabe mit 8 Token als 34. Bereits der Kontroll-Request ohne Tools wich ab, und sowohl Streaming als auch Nicht-Streaming meldeten 34. Bei fünf Abrechnungsprüfungen schlugen alle 3/3 fehl.
War das Ergebnis für den 32k-Cache ein Fehltreffer oder ein Fehler?
Ein Fehler. Acht von neun Hot-Requests mit 32k trafen den Cache und lasen 32,000 Token. Der eine Fehltreffer ist der vierte Request in Fenster 2, der die Frist von 300 s erreichte, ohne abgeschlossen zu werden. Die 8k-Gruppe traf den Cache bei 9/9 Requests und las 7,936 Token.
Lässt sich die Antwortqualität von ByteDance von der des offiziellen Kanals unterscheiden?
Nein. Die kombinierte Genauigkeit liegt 0.40 Punkte unter der des offiziellen Kanals; das 95%-Intervall reicht von −1.46 bis +0.66. Da das Intervall 0 einschließt, lassen sich die beiden nicht unterscheiden. Das gilt nur für diesen Durchlauf und ist kein Ranking.
Weiterlesen: die DeepSeek V4.1 Flash-Reihe
- Die Q-Baseline in diesem Beitrag ist der offizielle Kanal. Der eigene Durchlauf dieses Kanals, einschließlich der 15 ungültigen Sonden bei Einzelparallelität, wird in DeepSeek V4.1 Flash im offiziellen Kanal: 94.00 F, 15 ungültige Sonden behandelt.
- Baidu ist der einzige Anbieter, dessen Q-Intervall unter dem des offiziellen Kanals liegt; die Kanalfehler hinter diesem Ergebnis werden in DeepSeek V4.1 Flash bei Baidu: kein verfügbarer Kanal erreicht Q und P beschrieben.
- Die Cache-Werte von Alibaba Cloud stehen neben dem hier gemeldeten Wert von 93.83: DeepSeek V4.1 Flash bei Alibaba Cloud: 1.34s bis zum ersten Token, 99.37 Cache.
- Bei Fireworks traten dieselben Fehler beim Denkmodus und bei der Token-Abrechnung wie hier auf; zusätzlich gab es leere Antworten bei stop: DeepSeek V4.1 Flash bei Fireworks: leere stop-Antworten, 3/9 Cache-Treffer.
