Em 2026-11-03/04, a suíte APB Full foi executada com DeepSeek V4.1 Flash 1017 em cinco provedores por meio do AIHubMix. As mesmas perguntas, os mesmos parâmetros e os mesmos scripts de solicitação foram usados com todos os provedores; as cinco entradas de provedores estão na página de modelos. Este APB Profile abrange apenas o canal oficial do DeepSeek. O acesso é feito pela rota do fornecedor oficial do DeepSeek no AIHubMix, não por uma conexão direta à API do DeepSeek.
Esta publicação apresenta apenas as pontuações, sem classificar os provedores nem recomendar um deles: Q 42.45, F 94.00, P 86.14, K 98.38 e R 100. Q, F, P e R são as pontuações das quatro seções; K é uma subpontuação de P. A pontuação geral, 73.76, é um índice-resumo, não uma certificação, e não tem intervalo de confiança. O padrão de pontuação é AIHubMix Provider Benchmark Standard v2.0.
Pontuações dos cinco provedores
Negrito indica o provedor desta publicação. Ordem fixa dos provedores, não uma classificação. K é uma subpontuação de P, com peso de 20%, e é apresentada separadamente para referência. A pontuação geral é um índice-resumo sem intervalo de confiança. O canal oficial do DeepSeek e a Alibaba Cloud diferem em 0.37 na pontuação geral e não são distinguíveis.
Visão geral
- Qualidade das respostas: Q 42.45. BFCL 86.13%, HLE 15.06%, AA-LCR 53.20%. Sete respostas HLE foram truncadas ao atingir o limite de max_tokens e consideradas incorretas. Este canal é a referência de Q para os outros quatro.
- Suporte a funções: F 94.00. 137 das 147 verificações contabilizadas foram aprovadas. Outras 27 verificações que dependiam de contagens exatas de tokens foram declaradas inválidas e excluídas do denominador.
- Velocidade de resposta: P 86.14. Na primeira janela de concorrência única, houve 15 solicitações inválidas em 30 (12 × 503, 2 × prazo esgotado, 1 × tempo limite de leitura), contabilizadas como infinito; mediana do primeiro token: 1.87 s (1.72 s apenas para solicitações válidas); 10 de concorrência: 1.72 s; TPOT: 2.84 ms.
- Cache: K 98.38. Todas as 18 solicitações quentes em 8k e 32k acertaram; os controles frios não leram nada do cache.
- Estabilidade do serviço: R 100. Todas as 300 solicitações dedicadas foram bem-sucedidas na primeira tentativa.
Configuração do teste
As solicitações passaram pelo AIHubMix, selecionando a rota do fornecedor oficial do DeepSeek; o início rápido explica a configuração de acesso.
| Item | Detalhe |
|---|---|
| Modelo | DeepSeek V4.1 Flash 1017 |
| ID do modelo solicitado | deepseek-flash |
| Nome do modelo retornado | deepseek-flash |
| Rota de acesso | Rota do fornecedor oficial do DeepSeek no AIHubMix; não é uma conexão direta à API do DeepSeek |
| Parâmetros | Modo sem pensamento, temperature 1.0, max_tokens 16,384, tempo limite 300 s, sem novas tentativas automáticas |
| Pensamento desativado | Todas as solicitações usaram reasoning_effort=none |
| Período | 2026-11-03 18:07 – 11-04 16:33 UTC+8; os cinco provedores compartilharam um Mac mini, uma rede e uma conta |
| Amostras | Qualidade das respostas: 4,250 tentativas (BFCL 500 × 3, HLE 250 × 10, AA-LCR 25 × 10); casos de funções: 60 × 3 janelas; velocidade: 90 com concorrência única e 90 com 10 de concorrência; estabilidade: 300; cache: 30 (três grupos, cada um com prefixos de 8k e 32k) |
Q — qualidade das respostas: 42.45
A suíte reúne BFCL 500 perguntas × 3 execuções, HLE 250 × 10 e AA-LCR 25 × 10. O BFCL é avaliado por regras automáticas; HLE e AA-LCR são avaliados pelo modelo juiz deepseek-flash. Os cinco provedores responderam às mesmas perguntas. Dez respostas não puderam ser avaliadas e foram removidas, restando 4,240 tentativas pontuadas.
| Benchmark | Perguntas | Corretas | Precisão | Falhas |
|---|---|---|---|---|
| Chamadas de ferramenta BFCL | 500 × 3 | 1,292/1,500 | 86.13% | 0 |
| Perguntas e respostas difíceis HLE | 250 × 10 | 375/2,490 | 15.06% | 7 |
| Raciocínio sobre documentos longos AA-LCR | 25 × 10 | 133/250 | 53.20% | 0 |
| Total · IC de 95%: 40.08%–44.73% | 4,240 avaliadas | 1,800/4,240 | 42.45% | 7 |
Falhas do serviço — uma solicitação com falha ou uma resposta truncada — permanecem no denominador e contam como incorretas. Neste caso, isso inclui sete respostas HLE que atingiram o limite de max_tokens. O BFCL é avaliado automaticamente; HLE e AA-LCR são avaliados por um modelo juiz.
Os denominadores do BFCL são os totais das três execuções.
| Categoria BFCL | Aprovadas | Taxa de aprovação |
|---|---|---|
| simple_python — uma função, chamada e argumentos corretos | 334/360 | 92.78% |
| multiple — escolher a função certa entre várias | 268/300 | 89.33% |
| parallel — chamar a mesma função várias vezes em paralelo | 271/300 | 90.33% |
| parallel_multiple — chamar várias funções diferentes em paralelo | 207/240 | 86.25% |
| irrelevance — nenhuma função é relevante; nenhuma deve ser chamada | 113/150 | 75.33% |
| ahm_multi_turn — cadeia de ferramentas em três etapas | 99/150 | 66.00% |
Comparação com os outros quatro
Cada diferença é expressa em pontos percentuais em relação a esta referência, com um intervalo de 95% indicado pelas barras; se o intervalo cruzar 0, não há distinção. O modelo juiz pertence à mesma família DeepSeek que o modelo testado e não foi calibrado, portanto a avaliação de HLE e AA-LCR pode ser leniente.
F — suporte a funções: 94.00
Os casos de funções testam o comportamento do protocolo, não a qualidade das respostas. Sessenta casos em seis grupos foram executados em cada uma de três janelas — 180 verificações — e avaliados segundo o formato especificado na documentação de cada provedor. Verificações não aplicáveis, inválidas e não observadas são excluídas do denominador. Este canal aprovou 137 das 147 verificações contabilizadas, com uma pontuação ponderada de 94.00; a pontuação ponderada não é simplesmente 137/147.
| Grupo | Peso | Aprovadas | Excluídas | Pontuação do grupo |
|---|---|---|---|---|
| Streaming e protocolo de mensagens | 20% | 27/27 | 3 | 100.00 |
| Interface de ferramentas | 20% | 30/30 | — | 100.00 |
| Restrições de saída e parâmetros | 20% | 30/30 | — | 100.00 |
| Contexto e estado | 15% | 14/15 | 15 | 93.33 |
| Erros e recuperação | 15% | 24/30 | — | 80.00 |
| Protocolo de medição e cache | 10% | 12/15 | 15 | 80.00 |
| Total · ponderado | — | 137/147 | 33 | 94.00 |
A pontuação ponderada segue os pesos dos grupos; não é o número de verificações aprovadas dividido por 147.
| Caso reprovado | Janelas reprovadas | Motivo |
|---|---|---|
| Mensagens malformadas (Erros e recuperação) | 3/3 | Retornou 400, mas o corpo estava vazio, sem descrição estruturada do erro |
| stream_options malformado (Erros e recuperação) | 3/3 | Retornou 400, mas o corpo estava vazio, sem descrição estruturada do erro |
| Medição de tokens de pensamento (Protocolo de medição e cache) | 3/3 | Nenhuma contagem de tokens de pensamento retornada |
| Isolamento de solicitações (Contexto e estado) | 1/3 | A primeira etapa não respondeu apenas com STORED, conforme exigido, portanto não foi possível prosseguir com a verificação de isolamento |
As verificações excluídas não contam como aprovadas nem reprovadas.
| Status | Caso | Contagem | Motivo |
|---|---|---|---|
| Não observada | Sequência de parada do streaming | 3 | Após a etapa anterior, a solicitação desta etapa não foi enviada, portanto não foi possível avaliá-la |
| Inválidas | Entrada longa de 10k; dentro do limite de contexto; entrada longa de 32k; entrada longa de 100k; acima do limite de contexto; contagem nativa de entrada; definições de ferramentas contabilizadas na entrada; contagem de entrada consistente antes e depois do cache; consistência da entrada entre streaming e modo sem streaming | 27 | O modelo de contagem nativa fixado pelo teste não correspondia ao uso informado por este canal, por isso as verificações que dependiam de contagens exatas foram declaradas inválidas e excluídas do denominador |
| Não aplicável | cache_control explícito | 3 | Registrado previamente como não suportado por esta interface |
As 27 verificações inválidas são os casos de entrada longa, limite de contexto, contagem nativa e consistência de cache da lista. Como o modelo fixado não correspondia ao uso informado por este canal, todas as verificações que dependiam de uma contagem exata foram excluídas, em vez de pontuadas.
Dois casos falharam em todos os cinco provedores: messages malformadas e stream_options malformado. Ambos retornaram 400 com o corpo vazio, portanto o cliente não recebeu uma descrição estruturada do erro. Esse padrão compartilhado aponta mais para a camada de gateway do AIHubMix, que precisa ser investigada separadamente. A medição de tokens de pensamento também falhou nos cinco provedores, mas por motivos diferentes: ByteDance e Fireworks continuaram informando tokens de pensamento após a desativação do modo de pensamento, enquanto os outros três não retornaram uma contagem de tokens de pensamento.
Comparação com os outros quatro
P — velocidade de resposta: 86.14
Cada solicitação continha cerca de 10,000 tokens de entrada e pedia cerca de 1,100 tokens de saída. Em três janelas, foram enviadas 30 solicitações com concorrência única e 30 com 10 de concorrência, totalizando 180.
| Métrica | Valor |
|---|---|
| TTFA do primeiro token | Concorrência única: mediana de 1.87 s (mediana de 1.72 s para solicitações válidas). 10 de concorrência: mediana de 1.72 s |
| TPOT | Concorrência única: 2.84 ms/token. 10 de concorrência: 2.67 ms/token |
| Vazão válida (goodput) | 10 de concorrência: 1,546.0 token/s |
| Solicitações válidas | Concorrência única: 75/90 (janela 1: 15/30); 10 de concorrência: 90/90. Inválidas: 12 × 503 service_unavailable_error, 2 × prazo esgotado, 1 × tempo limite de leitura |
| Pontuações dos componentes | TTFA 51.65, TPOT 100.00, vazão 100.00; TTFA e TPOT usam o menor valor entre as duas faixas, com pesos de 35% / 35% / 30%; pontuação de resposta 83.08 |
| Composição de P | Pontuação de resposta 83.08 com peso de 80%, cache K 98.38 com peso de 20%; P 86.14 |
As 15 solicitações inválidas ocorreram todas na primeira janela de concorrência única: 12 retornaram 503, 2 atingiram o prazo limite e 1 teve tempo limite de leitura. As solicitações inválidas são contabilizadas como infinito, portanto a mediana informada é 1.87 s. Considerando apenas as solicitações válidas, a mediana é 1.72 s. Com 10 de concorrência, a mediana também é 1.72 s. O TPOT é 2.84 ms/token com concorrência única e 2.67 ms/token com 10 de concorrência.
Comparação com os outros quatro
Os cinco provedores compartilharam um Mac mini, uma rede e uma conta. As três janelas foram programadas provedor por provedor, portanto os períodos de coleta não se sobrepõem completamente; não se deve dar importância excessiva a pequenas diferenças.
K — cache: 98.38
Cada grupo envia cinco solicitações. A primeira prepara um prefixo fixo de 8k ou 32k. Nas solicitações de duas a quatro, o prefixo é mantido e apenas a pergunta final muda, após 5, 30 e 120 segundos. A quinta usa um prefixo novo como controle frio. Três janelas × dois comprimentos totalizam 30 solicitações. K divide os tokens lidos do cache nas solicitações quentes pelos tokens que deveriam ser reutilizáveis, atribuindo metade do peso a cada comprimento; K corresponde a 20% de P. A documentação da API do DeepSeek explica o cache de contexto.
| Prefixo | Janela | Preparação | +5 s | +30 s | +120 s | Controle frio |
|---|---|---|---|---|---|---|
| 8k | Janela 1 | 0 | 7,808 | 7,808 | 7,808 | 0 |
| 8k | Janela 2 | 0 | 7,808 | 7,808 | 7,808 | 0 |
| 8k | Janela 3 | 0 | 7,808 | 7,808 | 7,808 | 0 |
| 32k | Janela 1 | 0 | 31,872 | 31,872 | 31,872 | 0 |
| 32k | Janela 2 | 0 | 31,872 | 31,872 | 31,872 | 0 |
| 32k | Janela 3 | 0 | 31,872 | 31,872 | 31,872 | 0 |
As solicitações quentes de 8k acertaram 9 de 9 e leram 7,808 tokens cada: 70,272 lidos de 72,261 reutilizáveis, 97.25. As solicitações quentes de 32k acertaram 9 de 9 e leram 31,872 cada: 286,848 de 288,270, 99.51. Os controles frios não leram nada do cache. K é 98.38 nos dois comprimentos.
Comparação com os outros quatro
R — estabilidade do serviço: 100
As 300 solicitações abrangem texto curto, entrada longa de 10k, chamadas de ferramenta e histórico de várias interações, enviadas com concorrência única em três janelas. Verificam-se apenas a validade e a completude na primeira tentativa — não a correção das respostas — e não há novas tentativas. As falhas de qualidade das respostas e de velocidade são contabilizadas em Q e P, e não novamente em R.
| Tipo de solicitação | Sucesso na primeira tentativa |
|---|---|
| Texto curto | 120/120 |
| Entrada longa de 10k | 90/90 |
| Chamadas de ferramenta | 60/60 |
| Histórico de várias interações | 30/30 |
| Total · IC de 95%: 98.78%–100% | 300/300 |
As 300 solicitações retornaram respostas válidas e completas na primeira tentativa. R 100 abrange apenas essas 300 solicitações dedicadas; isso não significa que todo o percurso não teve falhas. Com 300 sucessos, o limite inferior do intervalo de 95% é 98.78%, portanto, as evidências indicam que a taxa de falhas provavelmente está abaixo de 1.22%.
Comparação com os outros quatro
R abrange apenas as 300 solicitações dedicadas; falhas na qualidade e na velocidade das respostas são registradas em Q e P, sem serem contabilizadas novamente em R.
| Provedor | Sucesso na primeira tentativa | IC de 95% |
|---|---|---|
| ByteDance | 300/300 | 98.78%–100% |
| Baidu | 300/300 | 98.78%–100% |
| Alibaba Cloud | 300/300 | 98.78%–100% |
| DeepSeek oficial | 300/300 | 98.78%–100% |
| Fireworks | 300/300 | 98.78%–100% |
Perguntas frequentes
Esta é uma conexão direta com a API da DeepSeek?
Não. As solicitações passam pela rota oficial do provedor DeepSeek da AIHubMix; elas não são enviadas diretamente à API da DeepSeek.
Por que o canal oficial da DeepSeek é a referência de Q?
É o canal oficial da DeepSeek para o mesmo modelo, então os resultados de qualidade das respostas dos outros quatro provedores são expressos como diferenças em relação a ele. O papel de referência não implica uma classificação da qualidade das respostas.
O que aconteceu na primeira janela de velocidade com concorrência única?
Quinze das 30 solicitações foram inválidas: 12 retornaram 503, 2 atingiram o prazo limite e 1 sofreu um tempo limite de leitura. Elas são contabilizadas como infinito, então a mediana é 1.87 s; considerando apenas as solicitações válidas, é 1.72 s.
O que são as 27 verificações de função inválidas?
Elas dependem de contagens exatas de tokens: entradas longas, limites de contexto, contagens nativas de entrada e consistência da entrada em cache. O modelo fixado no lado do teste para a contagem nativa não correspondia ao uso informado por este canal, então as verificações foram excluídas do denominador, em vez de serem contabilizadas como falhas.
Por que R 100 não garante que a rota esteja livre de falhas?
R abrange apenas as 300 solicitações dedicadas de estabilidade. As falhas durante as execuções de qualidade das respostas e velocidade são registradas em Q e P. Com 300 sucessos em 300 tentativas, o limite inferior do intervalo de 95% é 98.78%, portanto, a taxa de falhas provavelmente está abaixo de 1.22%, mas não foi comprovado que seja zero.
Como o teste de cache distingue leituras em cache de leituras frias?
Cada grupo prepara um prefixo de 8k ou 32k, repete o prefixo após 5, 30 e 120 segundos com uma nova pergunta final e, em seguida, envia um novo prefixo como controle frio. Ambos os comprimentos acertaram 9 de 9 solicitações em cache, e cada leitura de controle frio teve zero tokens em cache.
Continue lendo: a série DeepSeek V4.1 Flash
- O Q da ByteDance fica a 0.40 pontos desta referência, enquanto os resultados de suporte a funções e cache são diferentes: DeepSeek V4.1 Flash na ByteDance: chamadas de ferramentas correspondem, medição não.
- A Baidu perdeu solicitações por causa de
no_available_channel, o que aparece tanto em Q quanto em P: DeepSeek V4.1 Flash na Baidu: ausência de canal disponível afeta Q e P. - A Alibaba Cloud difere em 0.37 no total, uma diferença que não é estatisticamente distinguível: DeepSeek V4.1 Flash na Alibaba Cloud: primeiro token em 1.34s, cache em 99.37.
- A Fireworks acertou 3 de 9 solicitações quentes de 8k, contra 9 de 9 aqui: DeepSeek V4.1 Flash na Fireworks: respostas stop vazias, 3/9 acertos de cache.
