Il 2026-11-03/04, DeepSeek V4.1 Flash 1017 è stato testato su cinque fornitori tramite AIHubMix con la suite APB Full: ogni volta le stesse domande, gli stessi parametri e gli stessi script di richiesta. Questo profilo APB riguarda esclusivamente l’esecuzione su Baidu, sezione per sezione.
I valori seguenti sono solo punteggi, non una classifica né una raccomandazione di fornitore. Q 38.00, F 88.39, P 37.77, K 68.85 e R 100 vengono prima; il punteggio complessivo, 56.48, è un indice riepilogativo senza intervallo di confidenza. I criteri di valutazione sono quelli dello standard AIHubMix Provider Benchmark Standard v2.0.
Punteggi di cinque fornitori a confronto
Il grassetto indica il fornitore di questo articolo. I fornitori sono elencati in un ordine fisso, non in classifica. K è un sottopunteggio di P con un peso del 20%. Il punteggio complessivo è un indice riepilogativo senza intervallo di confidenza. La differenza di 0.37 tra il canale ufficiale e Alibaba Cloud non è statisticamente distinguibile.
In breve
- Q: 38.00. BFCL 86.40%, HLE 9.36%, AA-LCR 32.80%. Il risultato combinato è inferiore di 4.46 punti rispetto al canale ufficiale, con un intervallo al 95% da −5.78 a −3.16 che esclude lo 0. HLE ha registrato 864 richieste fallite e AA-LCR 100, quasi tutte nella prima finestra, conteggiate come risposte errate.
- F: 88.39. Superati 148 dei 174 controlli conteggiati. Il campo di lettura della cache e il conteggio dei token di ragionamento non sono stati restituiti; i casi di superamento del contesto e di risultato orfano dello strumento hanno restituito 200.
- P: 37.77. 50 delle 90 sonde con concorrenza 10 hanno restituito
no_available_channel, quindi più della metà non erano valide e TTFA e TPOT sono stati valutati con i rispettivi valori di penalità. Le sonde a concorrenza singola sono risultate valide 78 volte su 90. - K: 68.85. Le richieste calde da 8k hanno generato un cache hit 5 volte su 9, con 3 richieste fallite; il prefisso da 32k ha generato 8 cache hit su 9. I cache hit sono riportati in blocchi da 1,024 token: 7,168 token per 8k e 31,744 per 32k.
- R: 100. Tutte le 300 richieste dedicate sono riuscite al primo tentativo. Gli errori di canale durante le prove di risposta e velocità sono conteggiati in Q e P.
Configurazione del test
Le richieste hanno usato l’endpoint AIHubMix di avvio rapido con un ID specifico del fornitore, e i parametri seguono la documentazione API di DeepSeek; gli ID degli altri fornitori sono elencati nella pagina dei modelli. Non si tratta di una connessione diretta all’account Baidu.
| Campo | Valore |
|---|---|
| Modello | DeepSeek V4.1 Flash 1017 |
| ID modello richiesto | baidu-deepseek-v4.1-flash-1017 |
| Nome modello restituito | deepseek-v4.1-flash-1017 |
| Percorso di accesso | Tramite AIHubMix con l’ID modello specifico del fornitore; non è una connessione diretta all’account del fornitore |
| Parametri | Modalità senza ragionamento, temperature 1.0, max_tokens 16,384, timeout 300 s, nessun nuovo tentativo automatico |
| Ragionamento disattivato | Ogni richiesta ha usato reasoning_effort=none |
| Orario | 2026-11-03 18:07 – 11-04 16:33 UTC+8; tutti e cinque i fornitori hanno condiviso un Mac mini, la rete e l’account |
| Campioni | 4,250 tentativi di risposta (BFCL 500 × 3, HLE 250 × 10, AA-LCR 25 × 10); 60 casi di funzione × 3 finestre; 90 sonde a concorrenza singola e 90 con concorrenza 10 per la velocità; 300 richieste di stabilità; 30 sonde della cache (tre gruppi ciascuno per i prefissi da 8k e 32k) |
Q — qualità delle risposte: 38.00
La qualità delle risposte si basa su tre tipi di attività: 500 attività BFCL, ciascuna con tre risposte; 250 attività HLE, ciascuna con dieci risposte; e 25 attività AA-LCR, ciascuna con dieci risposte. BFCL viene valutato con regole automatiche; HLE e AA-LCR sono giudicati corretti o errati dal modello giudice deepseek-flash. Tutti e cinque i fornitori hanno ricevuto lo stesso insieme di attività, e i tre tipi sono combinati in un’unica percentuale di accuratezza. Dieci risposte sono state rimosse perché non era possibile giudicare l’attività, lasciando 4,240 tentativi valutati.
| Attività | Elementi | Corrette | Accuratezza | Errori |
|---|---|---|---|---|
| Chiamate agli strumenti BFCL | 500 × 3 | 1,296/1,500 | 86.40% | 0 |
| Domande difficili HLE, valutate dal giudice | 250 × 10 | 233/2,490 | 9.36% | 875 |
| Ragionamento su documenti lunghi AA-LCR | 25 × 10 | 82/250 | 32.80% | 100 |
| Combinato · intervallo al 95% 36.23%–39.58% | — | 1,611/4,240 | 38.00% | 975 |
Gli errori di servizio, che si tratti di una richiesta fallita o di un output troncato, restano al denominatore e vengono conteggiati come risposte errate. HLE ha registrato 864 richieste fallite (863 nella prima finestra, 1 nella seconda) e 11 output troncati al limite max_tokens. AA-LCR ha registrato 100 richieste fallite, tutte nella prima finestra.
BFCL viene eseguito tre volte per attività; la tabella mostra i risultati aggregati dei tre round.
| Categoria BFCL | Superati | Tasso di superamento |
|---|---|---|
| simple_python: una funzione, chiamata e argomenti corretti | 336/360 | 93.33% |
| multiple: scegliere la funzione giusta tra diverse | 269/300 | 89.67% |
| parallel: chiamare più volte una funzione in parallelo | 268/300 | 89.33% |
| parallel_multiple: chiamare più funzioni diverse in parallelo | 206/240 | 85.83% |
| irrelevance: nessuna funzione applicabile, non chiamarne alcuna | 113/150 | 75.33% |
| ahm_multi_turn: catena di strumenti in tre fasi | 104/150 | 69.33% |
Confronto con gli altri quattro
La differenza è espressa in punti percentuali rispetto al canale ufficiale, con l’intervallo al 95% indicato dalle barre. Un intervallo che attraversa lo 0 è considerato non distinguibile. Il giudice per HLE e AA-LCR, deepseek-flash, appartiene alla stessa famiglia DeepSeek del modello testato e non è stato calibrato, quindi i suoi giudizi potrebbero essere indulgenti.
F — supporto delle funzioni: 88.39
I casi relativi alle funzioni verificano se l’interfaccia si comporta secondo le specifiche del protocollo, non se il modello risponde bene. Sono stati eseguiti una volta in ciascuna delle tre finestre 60 casi suddivisi in sei gruppi, per un totale di 180 controlli, valutati rispetto al formato documentato dal fornitore. I controlli non applicabili, non validi o non osservati sono esclusi dal denominatore. Per Baidu sono stati conteggiati 174 controlli e 148 sono stati superati, per un punteggio ponderato di 88.39.
Il punteggio del gruppo è ponderato in base alla quota di ciascun gruppo, non calcolato come semplice rapporto 148/174.
| Gruppo di casi | Peso | Superati | Esclusi | Punteggio del gruppo |
|---|---|---|---|---|
| Streaming e protocollo dei messaggi | 20% | 27/27 | 3 | 100.00 |
| Interfaccia degli strumenti | 20% | 30/30 | — | 100.00 |
| Vincoli di output e parametri | 20% | 29/30 | — | 96.67 |
| Contesto e stato | 15% | 26/30 | — | 86.67 |
| Errori e ripristino | 15% | 21/30 | — | 70.00 |
| Protocollo di misurazione e cache | 10% | 15/27 | 3 | 55.56 |
| Totale, ponderato | 100% | 148/174 | 6 | 88.39 |
| Caso non superato | Finestre non superate | Motivo |
|---|---|---|
| Contesto superato (contesto e stato) | 3/3 | Avrebbe dovuto restituire un errore di parametro; ha restituito 200 |
| Messaggi malformati (errori e ripristino) | 3/3 | Ha restituito 400 con corpo vuoto, senza un errore strutturato |
| Risultato orfano dello strumento (errori e ripristino) | 3/3 | Avrebbe dovuto restituire un errore di parametro; ha restituito 200 |
| stream_options malformato (errori e ripristino) | 3/3 | Ha restituito 400 con corpo vuoto, senza un errore strutturato |
| Campo di lettura della cache (protocollo di misurazione e cache) | 3/3 | Nessun campo di lettura della cache restituito; la lettura non può essere confermata |
| Misurazione dei token di ragionamento (protocollo di misurazione e cache) | 3/3 | Nessun conteggio dei token di ragionamento restituito |
| Definizioni degli strumenti conteggiate nell’input (protocollo di misurazione e cache) | 3/3 | Con le definizioni degli strumenti, i token di input riportati non erano superiori a quelli senza |
| Conteggio dell’input coerente prima e dopo la cache (protocollo di misurazione e cache) | 3/3 | Nessun campo di lettura della cache restituito; la lettura non può essere confermata |
| Diversità del campionamento (vincoli di output e parametri) | 1/3 | Gli output ripetuti con temperature 0 e 1 differivano troppo poco, sotto la soglia prestabilita |
| Isolamento tra richieste (contesto e stato) | 1/3 | Il primo passaggio non ha risposto solo con STORED come richiesto, quindi non è stato possibile procedere con il controllo di isolamento |
Questi controlli sono esclusi dal denominatore: non sono né superati né non superati.
| Stato | Caso | Numero | Motivo |
|---|---|---|---|
| Non osservato | Sequenza di arresto dello streaming | 3 | La richiesta per questo passaggio non è stata inviata dopo quello precedente, quindi non è possibile valutarla |
| Non applicabile | cache_control esplicito | 3 | Registrato in anticipo come non supportato da questa interfaccia |
I messages malformati e stream_options malformati hanno causato errori per tutti e cinque i fornitori: entrambi hanno restituito 400 con corpo vuoto, senza fornire al client un errore strutturato. Un errore condiviso da tutti e cinque probabilmente si trova nel livello gateway di AIHubMix e richiede un’indagine separata. Anche la misurazione dei token di ragionamento è fallita per tutti e cinque, per motivi diversi: ByteDance e Fireworks hanno riportato token di ragionamento anche con il ragionamento disattivato, mentre gli altri tre non hanno restituito il conteggio dei token di ragionamento.
Confronto con gli altri quattro
P — velocità di risposta: 37.77
Ogni richiesta conteneva circa 10,000 token di input e chiedeva un corpo di circa 1,100 token di output. In ciascuna delle tre finestre sono state inviate 30 sonde a concorrenza singola e 30 con concorrenza 10, per un totale di 180 richieste.
| Metrica | Risultato |
|---|---|
| TTFA al primo token | Mediana a concorrenza singola 2.26 s (mediana delle richieste valide 2.05 s); con concorrenza 10, più della metà non valide, mediana conteggiata come infinito (mediana delle richieste valide 1.86 s) |
| Velocità di generazione TPOT | Concorrenza singola 3.48 ms/token; concorrenza 10 50.00 ms/token (più della metà non valide, valore di penalità) |
| Goodput (throughput valido) | Concorrenza 10: 1,329.2 token/s |
| Richieste valide | Concorrenza singola 78/90 (prima finestra 18/30); concorrenza 10 40/90 (prima finestra 0/30, terza finestra 10/30) |
| Motivo di invalidità | 62 sonde hanno restituito 400 no_available_channel |
| Punteggio delle componenti | TTFA 0.00, TPOT 0.00, throughput 100.00; punteggio di risposta 30.00 |
| Composizione di P | Punteggio di risposta 30.00 con peso dell’80%, cache K 68.85 con peso del 20%, totale 37.77 |
TPOT è stimato dai blocchi trasmessi in streaming, non misurato token per token sull’hardware. Il goodput è il numero di token di output validi a concorrenza 10 diviso per il tempo di parete del batch.
Nel livello con concorrenza 10, 50 delle 90 sonde hanno restituito no_available_channel. Poiché più della metà non erano valide, il tempo mediano al primo token è considerato infinito e TTFA e TPOT assumono entrambi i rispettivi valori di penalità. Il livello a concorrenza singola è rimasto valido per 78 sonde su 90.
Tutti e cinque i fornitori hanno condiviso una macchina, la rete e l’account. Le tre finestre sono state pianificate un fornitore alla volta, quindi i periodi di raccolta non si sovrappongono del tutto; non bisogna dare troppo peso a piccole differenze.
K — cache: 68.85
Ogni gruppo invia cinque richieste. La prima contiene un prefisso fisso di circa 8k o 32k token e inizializza la cache. Le richieste dalla 2 alla 4 mantengono il prefisso e modificano solo la domanda finale, a intervalli di 5 s, 30 s e 120 s. La quinta usa un nuovo prefisso come controllo a freddo. Tre finestre × due lunghezze equivalgono a 30 richieste. K è il numero di token letti dalla cache nelle richieste calde, diviso per i token che, secondo i criteri, dovrebbero essere riutilizzabili; le due lunghezze hanno ciascuna un peso pari alla metà. K rappresenta il 20% di P.
La tabella mostra il conteggio dei token letti dalla cache riportato dal server; «non restituito» significa che il campo era assente nella risposta.
| Prefisso | Finestra | Inizializzazione | +5 s | +30 s | +120 s | Controllo a freddo |
|---|---|---|---|---|---|---|
| 8k | 1 | Fallita | Fallita | Fallita | Non restituito | Non restituito |
| 8k | 2 | Non restituito | 7,168 | 7,168 | Fallita | Fallita |
| 8k | 3 | Non restituito | 7,168 | 7,168 | 7,168 | Non restituito |
| 32k | 1 | Non restituito | Non restituito | 31,744 | 31,744 | Non restituito |
| 32k | 2 | Non restituito | 31,744 | 31,744 | 31,744 | Non restituito |
| 32k | 3 | Non restituito | 31,744 | 31,744 | 31,744 | Non restituito |
Il prefisso 8k ha registrato cache hit per 5 delle 9 richieste frequenti, leggendo 35,840 dei 72,252 token che avrebbero dovuto essere riutilizzabili, con un punteggio di 49.60. Il prefisso 32k ha registrato cache hit per 8 delle 9 richieste, leggendo 253,952 token su 288,261, con un punteggio di 88.10. K è 68.85, calcolato ponderando allo stesso modo le due lunghezze. Cinque richieste 8k sono fallite complessivamente: la richiesta seed della finestra 1, quelle a 5 s e 30 s, e le richieste a 120 s e di controllo a cache fredda della finestra 2; tutte con no_available_channel. Restano quindi tre richieste frequenti fallite nel livello 8k.
In caso di cache hit, la lettura indicata viene conteggiata in blocchi da 1,024 token: 7,168 token per il prefisso 8k e 31,744 per il prefisso 32k. In caso di cache miss, il blocco di utilizzo non include prompt_tokens_details; la tabella riporta «non restituito» e il valore viene conteggiato come 0.
Confronto con gli altri quattro
R — stabilità del servizio: 100
Le 300 richieste si dividono in quattro tipi: testo breve, input lungo, chiamata allo strumento e cronologia multi-turno. Sono state inviate con concorrenza singola in tre finestre. Si verifica soltanto se la prima risposta era valida e completa; le risposte non vengono valutate e non si ripetono le richieste. Gli errori durante i test di risposta e di velocità sono conteggiati rispettivamente in Q e P, non di nuovo in R.
| Tipo di richiesta | Successo al primo tentativo |
|---|---|
| Testo breve | 120/120 |
| Input lungo da 10k | 90/90 |
| Chiamata allo strumento | 60/60 |
| Cronologia multi-turno | 30/30 |
| Totale | 300/300, IC 95% 98.78%–100% |
Tutte le 300 richieste hanno restituito una risposta valida e completa al primo tentativo. R 100 riguarda solo queste 300 richieste dedicate; non significa che l'intero percorso non abbia avuto errori. Con 300 successi su 300, il limite inferiore dell'intervallo al 95% è 98.78%, quindi è probabile che il tasso di errore sia inferiore all'1.22%.
Confronto con gli altri quattro
R riguarda solo queste 300 richieste dedicate; gli errori durante i test di risposta e di velocità sono registrati rispettivamente in Q e P, non di nuovo in R.
| Fornitore | Successo al primo tentativo | Intervallo al 95% |
|---|---|---|
| ByteDance | 300/300 | 98.78%–100% |
| Baidu | 300/300 | 98.78%–100% |
| Alibaba Cloud | 300/300 | 98.78%–100% |
| DeepSeek ufficiale | 300/300 | 98.78%–100% |
| Fireworks | 300/300 | 98.78%–100% |
FAQ
Che cosa rappresenta il punteggio complessivo?
È un indice riepilogativo senza intervallo di confidenza, non una certificazione. Questo articolo riporta Q, F, P, K e R e non raccomanda alcun fornitore.
Perché metà dei test con dieci richieste concorrenti è fallita?
50 delle 90 richieste hanno restituito no_available_channel. Poiché più della metà non era valida, il tempo mediano al primo token viene considerato infinito e TTFA e TPOT ricevono i rispettivi valori di penalità.
R 100 significa che non ci sono stati errori di canale?
No. R riguarda 300 richieste dedicate, tutte riuscite al primo tentativo. Le 62 risposte no_available_channel nel test di velocità e gli errori nel test di risposta sono conteggiati rispettivamente in P e Q.
Perché K è 68.85 se il prefisso 32k ha registrato 8 cache hit su 9?
Le due lunghezze hanno lo stesso peso. Il prefisso 8k ha registrato cache hit per 5 delle 9 richieste frequenti e ottenuto 49.60, mentre il prefisso 32k ne ha registrate 8 su 9 e ottenuto 88.10; la media è 68.85.
È possibile distinguere la qualità delle risposte di Baidu da quella del canale ufficiale?
Sì. La differenza complessiva Q è di −4.46 punti percentuali, con un intervallo al 95% da −5.78 a −3.16 che esclude 0. È l'unico risultato di un fornitore inferiore a quello del canale ufficiale il cui intervallo esclude 0.
Quali verifiche sono state escluse da F?
Sei: tre verifiche delle sequenze di arresto dello streaming, mai osservate perché la richiesta del passaggio precedente non è stata inviata, e tre verifiche esplicite di cache_control, preregistrate come non supportate da questa interfaccia.
Continua a leggere: la serie DeepSeek V4.1 Flash
- L'accuratezza BFCL di Baidu era vicina a quella del canale ufficiale; l'articolo su ByteDance applica la stessa suite ai risultati delle chiamate allo strumento e della misurazione dei consumi: DeepSeek V4.1 Flash su ByteDance: le chiamate allo strumento coincidono, la misurazione dei consumi no
- La TTFA di 2.26 s di Baidu con concorrenza singola si contrappone a un test che ha raggiunto 1.34 s: DeepSeek V4.1 Flash su Alibaba Cloud: primo token in 1.34s, cache al 99.37
- Il valore F 88.39 di Baidu si confronta con un test di riferimento a 94.00 con 15 test non validi: DeepSeek V4.1 Flash sul canale ufficiale: F 94.00, 15 test non validi
- I 5/9 cache hit del prefisso 8k di Baidu si confrontano con un test a 3/9 e risposte di arresto vuote: DeepSeek V4.1 Flash su Fireworks: risposte di arresto vuote, 3/9 cache hit
