Em 2026-11-03/04, DeepSeek V4.1 Flash 1017 foi testado em cinco provedores por meio da AIHubMix, usando a suíte APB Full: as mesmas perguntas, parâmetros e scripts de requisição em todas as rodadas. Este perfil APB cobre apenas a execução na ByteDance, seção por seção.
Os números abaixo são pontuações, não um ranking nem uma recomendação de provedor. Q, F, P, K e R vêm primeiro; a pontuação geral é um índice resumido, não uma certificação, e não tem intervalo de confiança. As regras de pontuação estão definidas no AIHubMix Provider Benchmark Standard v2.0.
Pontuações dos cinco provedores
Negrito indica o provedor desta publicação. Ordem fixa de provedores, não um ranking. K é uma subpontuação de P e representa 20% dela. A pontuação geral é um índice resumido sem intervalo de confiança. DeepSeek oficial e Alibaba Cloud diferem por 0.37 e não podem ser distinguidos.
Em resumo
- Q 42.05. BFCL 85.20%, HLE 15.34%, AA-LCR 49.20%. A diferença em relação ao canal oficial é de −0.40 pontos percentuais, com intervalo de 95% entre −1.46 e +0.66: não podem ser distinguidos. AA-LCR teve 28 falhas de requisição, todas na janela 1, contabilizadas como incorretas.
- F 74.98. 124 das 174 verificações contabilizadas foram aprovadas.
reasoning_effort=nonenão desativa o modo de pensamento. Uma entrada de 10k tokens foi informada como 10,026 tokens (contagem nativa 10,000); uma entrada de 8 tokens foi informada como 34. - P 84.37. Primeiro token do corpo: mediana de 2.12 s com concorrência única e 2.10 s com concorrência de 10; TPOT de 3.43 ms/token; todas as 180 requisições de velocidade foram válidas.
- K 93.83. Requisições quentes com 8k tokens acertaram 9/9; com 32k, acertaram 8 vezes, e uma requisição não terminou no prazo de 300 s.
- R 100. Todas as 300 requisições dedicadas tiveram êxito na primeira tentativa.
Configuração do teste
| Item | Detalhe |
|---|---|
| Modelo | DeepSeek V4.1 Flash 1017 |
| ID do modelo solicitado | doubao-deepseek-v4.1-flash-1017 |
| Nome do modelo retornado | deepseek-v4-1-flash-261017 |
| Rota de acesso | Por meio da AIHubMix, usando um ID de modelo específico do provedor, não uma conexão direta à conta do provedor |
| Parâmetros | Modo sem pensamento, temperature 1.0, max_tokens 16,384, timeout 300 s, sem novas tentativas automáticas |
| Modo de pensamento desativado | As requisições de qualidade das respostas, velocidade, cache e estabilidade usaram thinking.type=disabled nativo (para este provedor, reasoning_effort=none não desativou o modo de pensamento); os casos de função mantiveram reasoning_effort=none para verificar se o parâmetro surte efeito |
| 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 instâncias de perguntas (BFCL 500 × 3, HLE 250 × 10, AA-LCR 25 × 10); funções: 60 casos × 3 janelas; velocidade: 90 com concorrência única e 90 com concorrência de 10; estabilidade: 300; cache: 30 (três grupos cada um com prefixos de 8k e 32k) |
As requisições usaram a rota de início rápido da AIHubMix com um ID específico do provedor, e os parâmetros seguem a documentação da API da DeepSeek; os IDs dos outros provedores estão listados na página de modelos.
Q — qualidade das respostas: 42.05
A qualidade das respostas é avaliada por três suítes: 500 perguntas BFCL com 3 rodadas cada, 250 perguntas HLE com 10 rodadas cada e 25 perguntas AA-LCR com 10 rodadas cada. A BFCL é pontuada por regras automáticas; HLE e AA-LCR são avaliadas pelo modelo deepseek-flash. Os cinco provedores receberam as mesmas perguntas, e as três suítes são agrupadas em uma única métrica de precisão. Dez respostas foram removidas porque não era possível pontuar a pergunta, restando 4,240 instâncias de perguntas pontuadas.
| Suíte | Perguntas | Corretas | Precisão | Falhas |
|---|---|---|---|---|
| Chamadas de ferramenta BFCL | 500 × 3 | 1,278/1,500 | 85.20% | 0 |
| Perguntas e respostas difíceis HLE | 250 × 10 | 382/2,490 | 15.34% | 7 |
| Raciocínio sobre documentos longos AA-LCR | 25 × 10 | 123/250 | 49.20% | 28 |
| Combinado · intervalo de 95%: 39.70%–44.33% | — | 1,783/4,240 | 42.05% | 35 |
Falhas de serviço — falhas de requisição ou saída truncada — permanecem no denominador e contam como incorretas. A saída HLE atingiu o limite de max_tokens 7 vezes; AA-LCR teve 28 falhas de requisição, todas na janela 1. BFCL é pontuada automaticamente; HLE e AA-LCR são avaliadas por um juiz.
Cada pergunta BFCL foi respondida 3 vezes; a tabela soma as 3 rodadas.
| Categoria BFCL | Aprovadas | Taxa de aprovação |
|---|---|---|
| simple_python — uma função, chamada e argumentos corretos | 329/360 | 91.39% |
| multiple — escolher uma entre várias funções | 268/300 | 89.33% |
| parallel — chamar a mesma função várias vezes | 271/300 | 90.33% |
| parallel_multiple — chamar várias funções diferentes | 207/240 | 86.25% |
| irrelevance — nenhuma função é pertinente; não deve chamar nenhuma | 102/150 | 68.00% |
| ahm_multi_turn — cadeia de ferramentas em três etapas | 101/150 | 67.33% |
Comparação com os outros quatro
Diferença em relação ao canal oficial, em pontos percentuais, com o intervalo de 95% indicado pelas barras. Um intervalo que cruza 0 é registrado como não distinguível. O juiz de HLE e AA-LCR, deepseek-flash, pertence à mesma família DeepSeek que o modelo testado e não foi calibrado, portanto suas avaliações podem ser lenientes.
F — suporte a funções: 74.98
A suíte de funções avalia apenas se o comportamento da interface corresponde ao protocolo, não se o modelo responde bem. Sessenta casos em seis grupos foram executados três vezes, uma por janela: 180 verificações, avaliadas com base no formato documentado por cada provedor. Verificações não aplicáveis, inválidas ou não observadas são excluídas do denominador. A ByteDance aprovou 124 das 174 verificações contabilizadas e obteve 74.98 com base nos pesos dos grupos.
A pontuação ponderada aplica os pesos dos grupos; não corresponde às verificações aprovadas divididas por 174.
| Grupo | Peso | Aprovadas | Excluídas | Pontuação do grupo |
|---|---|---|---|---|
| Protocolo de streaming e mensagens | 20% | 23/27 | 3 | 85.19 |
| Interface de ferramentas | 20% | 30/30 | — | 100.00 |
| Restrições de saída e parâmetros | 20% | 24/30 | — | 80.00 |
| Contexto e estado | 15% | 14/30 | — | 46.67 |
| Erros e recuperação | 15% | 21/30 | — | 70.00 |
| Medição de tokens e protocolo de cache | 10% | 12/27 | 3 | 44.44 |
| Total · pontuação ponderada | — | 124/174 | 6 | 74.98 |
“Janelas com falha” indica quantas das 3 janelas falharam na verificação.
| Caso com falha | Janelas com falha | Motivo |
|---|---|---|
| O raciocínio não vaza para o conteúdo — protocolo de streaming e mensagens | 3/3 | Com reasoning_effort=none, o conteúdo de pensamento ainda foi retornado |
| A configuração de pensamento surte efeito — restrições de saída e parâmetros | 3/3 | Com reasoning_effort=none, o conteúdo de pensamento ainda foi retornado |
| Diversidade de amostragem — restrições de saída e parâmetros | 3/3 | As saídas com temperature 0 e 1 não foram suficientemente diferentes; ficaram abaixo do limite pré-registrado |
| Entrada longa de 10k — contexto e estado | 3/3 | Entrada informada: 10,026 tokens; a contagem nativa deveria ser 10,000 |
| Dentro do limite de contexto — contexto e estado | 3/3 | Entrada informada: 10,026 tokens; a contagem nativa deveria ser 10,000 |
| Entrada longa de 32k — contexto e estado | 3/3 | Entrada informada: 10,026 tokens; a contagem nativa deveria ser 10,000 |
| Entrada longa de 100k — contexto e estado | 3/3 | Entrada informada: 10,026 tokens; a contagem nativa deveria ser 10,000 |
| Acima do limite de contexto — contexto e estado | 3/3 | Falha ou timeout na conexão upstream (1); deveria retornar um erro de parâmetro, mas retornou 200 (2) |
| Histórico de 12 turnos — contexto e estado | 1/3 | Falha ou timeout na conexão upstream |
| Erro de formato de messages — erros e recuperação | 3/3 | Retornou 400 com corpo vazio; sem explicação estruturada do erro |
| Resultado de ferramenta órfão — erros e recuperação | 3/3 | Deveria retornar um erro de parâmetro, mas retornou 200 |
| Erro de formato de stream_options — erros e recuperação | 3/3 | Retornou 400 com corpo vazio; sem explicação estruturada do erro |
| Contabilização de tokens de pensamento — medição de tokens e protocolo de cache | 3/3 | Foram informados tokens de pensamento mesmo depois de desativar o modo de pensamento |
| Contagem nativa de entrada — medição de tokens e protocolo de cache | 3/3 | Foram informados 34 tokens; a contagem nativa deveria ser 8 |
| Definições de ferramentas contabilizadas na entrada — medição de tokens e protocolo de cache | 3/3 | A requisição de controle sem ferramentas já divergia da contagem nativa de entrada |
| Contagem de entrada consistente antes e depois do cache — medição de tokens e protocolo de cache | 3/3 | Quando o mesmo prefixo foi repetido, os tokens de entrada informados não correspondiam à contagem nativa |
| Entrada consistente em streaming e sem streaming — medição de tokens e protocolo de cache | 3/3 | Ambos informaram 34 tokens; a contagem nativa deveria ser 8 |
| Saída de texto exata — protocolo de streaming e mensagens | 1/3 | Um ponto final extra no corpo; o texto não corresponde exatamente ao solicitado |
Essas verificações são excluídas do denominador; não contam como aprovação nem como falha.
| Status | Caso | Quantidade | Motivo |
|---|---|---|---|
| Não observado | Sequências de parada de streaming | 3 | Essa requisição não foi enviada após a etapa anterior; não é possível avaliar |
| Não aplicável | Explicit cache_control | 3 | Registrado previamente como não compatível com esta interface |
Os casos de erro de formato de messages e de stream_options falharam nos cinco provedores: ambos retornaram 400 com corpo vazio, portanto os clientes não recebem uma explicação estruturada do erro. Uma falha compartilhada pelos cinco provavelmente está na camada de gateway da AIHubMix e requer uma investigação à parte. A contabilização de tokens de pensamento também falhou nos cinco, mas por motivos diferentes: ByteDance e Fireworks informaram tokens de pensamento mesmo depois de desativar o modo de pensamento; os outros três não retornaram uma contagem de tokens de pensamento.
Comparação com os outros quatro
P — velocidade de resposta: 84.37
Cada requisição carregava cerca de 10,000 tokens de entrada e solicitava cerca de 1,100 tokens de texto no corpo da saída. Em cada uma das três janelas, 30 requisições foram executadas com concorrência única e 30 com concorrência de 10: 180 requisições no total.
| Métrica | Resultado |
|---|---|
| Espera até o primeiro token do corpo (TTFA) | Mediana de 2.12 s com concorrência única; mediana de 2.10 s com concorrência de 10 |
| Velocidade de geração (TPOT) | 3.43 ms/token com concorrência única; 3.41 ms/token com concorrência de 10 |
| Taxa de transferência efetiva | 1,250.0 token/s com concorrência de 10 |
| Requisições válidas | 90/90 com concorrência única; 90/90 com concorrência de 10 |
| Pontuações dos componentes | TTFA 48.59, TPOT 100.00, taxa de transferência 100.00; para TTFA e TPOT, considera-se o menor valor entre os dois níveis; pesos 35% / 35% / 30%; pontuação de resposta 82.00 |
| Pontuação P | Pontuação de resposta 82.00 com peso de 80%, cache K 93.83 com peso de 20%; total 84.37 |
O TPOT é estimado a partir dos blocos transmitidos por streaming, não medido por token no hardware. A taxa de transferência corresponde aos tokens de saída válidos com concorrência de 10 divididos pelo tempo total do lote.
Comparação com os outros quatro
Os cinco compartilharam uma máquina, uma rede e uma conta. As três janelas foram agendadas provedor por provedor, portanto os períodos de coleta não se sobrepõem totalmente; não se deve dar peso excessivo a pequenas diferenças.
K — cache: 93.83
Cada grupo envia cinco requisições. A primeira inclui um prefixo fixo de cerca de 8k ou 32k tokens e prepara o cache. As requisições 2–4 mantêm o prefixo e alteram apenas a pergunta final, após 5 s, 30 s e 120 s. A quinta usa um novo prefixo como controle frio. Três janelas e dois tamanhos, com cinco requisições por grupo, totalizam 30 requisições. K é o número de tokens lidos do cache nas requisições quentes dividido pelos tokens que deveriam ser reutilizáveis segundo as regras, com peso igual para os dois tamanhos; K representa 20% de P.
| Prefixo | Janela | Preparação | +5 s | +30 s | +120 s | Controle frio |
|---|---|---|---|---|---|---|
| 8k | Janela 1 | 0 | 7,936 | 7,936 | 7,936 | 0 |
| 8k | Janela 2 | 0 | 7,936 | 7,936 | 7,936 | 0 |
| 8k | Janela 3 | 0 | 7,936 | 7,936 | 7,936 | 0 |
| 32k | Janela 1 | 0 | 32,000 | 32,000 | 32,000 | 0 |
| 32k | Janela 2 | 0 | 32,000 | 32,000 | falhou | 0 |
| 32k | Janela 3 | 0 | 32,000 | 32,000 | 32,000 | 0 |
Estes são os tokens lidos do cache, conforme informados pelo servidor.
Todas as nove solicitações quentes de 8k acertaram o cache, cada uma lendo 7,936 tokens. Oito das nove solicitações quentes de 32k acertaram o cache, cada uma lendo 32,000 tokens; uma solicitação falhou. K é 93.83, com os dois comprimentos ponderados igualmente. As solicitações frias não leram nada do cache, portanto as quentes e as frias ficam claramente separadas. A solicitação que falhou foi a quarta do grupo de 32k na janela 2, que atingiu o prazo de 300 s sem ser concluída.
Em comparação com os outros quatro
R — estabilidade do serviço: 100
As 300 solicitações se dividem em quatro tipos — texto curto, entrada longa, chamadas de ferramenta e histórico de várias rodadas — e foram executadas com concorrência única em três janelas. Uma solicitação só conta como bem-sucedida se a primeira tentativa retornar uma resposta válida e completa; a correção da resposta não é verificada e não há novas tentativas. As falhas nas seções de qualidade da resposta e velocidade são contabilizadas em Q e P, 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 rodadas | 30/30 |
| Total · intervalo de 95%: 98.78%–100% | 300/300 |
Todas as 300 solicitações retornaram uma resposta válida e completa na primeira tentativa. R = 100 descreve apenas estas 300 solicitações dedicadas; não significa que toda a cadeia não teve falhas. O limite inferior do intervalo de 95% é 98.78%: 300 sucessos permitem apenas afirmar que a taxa de falhas provavelmente fica abaixo de 1.22%.
Em comparação com os outros quatro
R abrange apenas estas 300 solicitações dedicadas; as falhas nas seções de qualidade da resposta e velocidade são registradas em Q e P e não são contabilizadas novamente em R.
| Provedor | Sucesso na primeira tentativa | Intervalo 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
O reasoning_effort=none realmente não conseguiu desativar o modo de pensamento?
Sim. Nas três janelas, as solicitações com reasoning_effort=none ainda retornaram conteúdo de pensamento, então a verificação falhou em 3/3. As solicitações de qualidade da resposta, velocidade, cache e estabilidade usaram, em vez disso, a opção nativa thinking.type=disabled. A suíte de funções manteve reasoning_effort=none intencionalmente, para testar se o parâmetro surtia efeito.
A precisão no BFCL é de 85.20%. Por que Q é 42.05?
Q combina três suítes de dificuldades muito diferentes. O BFCL contribuiu com 1,278 respostas corretas em 1,500, o HLE com 382 em 2,490 e o AA-LCR com 123 em 250. No total, 1,783 das 4,240 instâncias de perguntas avaliadas estavam corretas: 42.05%. Os 15.34% do HLE reduzem o resultado combinado.
As 35 falhas de serviço de Q estão incluídas na pontuação?
Sim. As solicitações com falha e as saídas truncadas permanecem no denominador e contam como incorretas. Sete respostas do HLE foram cortadas em max_tokens; 28 solicitações do AA-LCR falharam, todas na janela 1.
Por que a contabilização dos tokens de entrada é importante?
Porque a medição deve corresponder à contagem nativa do modelo. Uma entrada de 10k tokens foi informada como 10,026 tokens (10,000 nativos), e uma entrada de 8 tokens foi informada como 34. A solicitação de controle sem ferramentas já apresentou divergência, e tanto o streaming quanto o modo sem streaming informaram 34. As cinco verificações de medição falharam em 3/3.
O resultado do cache de 32k foi uma falha de acerto ou uma falha da solicitação?
Foi uma falha da solicitação. Oito das nove solicitações quentes de 32k acertaram o cache e leram 32,000 tokens. A única solicitação com falha é a quarta na janela 2, que atingiu o prazo de 300 s sem ser concluída. O grupo de 8k acertou o cache em 9/9, com 7,936 tokens.
É possível distinguir a qualidade das respostas da ByteDance daquela do canal oficial?
Não. A precisão combinada é 0.40 pontos inferior à do canal oficial, com um intervalo de 95% de −1.46 a +0.66. O intervalo inclui 0, portanto os dois não são distinguíveis. Isso descreve apenas este lote e não é um ranking.
Continue lendo: a série DeepSeek V4.1 Flash
- A referência de Q nesta publicação é o canal oficial; a execução própria desse canal, incluindo as 15 sondagens inválidas com concorrência única, está detalhada em DeepSeek V4.1 Flash no canal oficial: 94.00 F, 15 sondagens inválidas.
- O Baidu é o único provedor cujo intervalo de Q fica abaixo do canal oficial; as falhas de canal por trás desse resultado estão em DeepSeek V4.1 Flash no Baidu: nenhum canal disponível atinge Q e P.
- Os números de cache da Alibaba Cloud ficam ao lado dos 93.83 informados aqui: DeepSeek V4.1 Flash na Alibaba Cloud: 1.34s até o primeiro token, 99.37 de cache.
- A Fireworks apresenta as mesmas falhas no modo de pensamento e na contabilização de tokens observadas aqui, além de respostas stop vazias: DeepSeek V4.1 Flash na Fireworks: respostas stop vazias, 3/9 acertos de cache.
