2026-11-03/04, AIHubMix를 통해 DeepSeek V4.1 Flash 1017을 다섯 공급자에서 APB Full 제품군으로 테스트했습니다. 매번 동일한 질문, 매개변수, 요청 스크립트를 사용했습니다. 이 APB 프로필은 ByteDance 실행 결과만 섹션별로 다룹니다.
아래 수치는 점수이며 순위나 공급자 추천이 아닙니다. Q, F, P, K, R을 먼저 살펴봅니다. 종합 점수는 요약 지표일 뿐 인증이 아니며, 신뢰 구간도 없습니다. 채점 규칙은 AIHubMix Provider Benchmark Standard v2.0에 정의되어 있습니다.
다섯 공급자의 점수
굵게 표시된 항목은 이 게시물에서 다루는 공급자입니다. 공급자 순서는 고정되어 있으며 순위가 아닙니다. K는 P의 하위 점수로, P의 20%를 차지합니다. 종합 점수는 신뢰 구간이 없는 요약 지표입니다. DeepSeek 공식 채널과 Alibaba Cloud의 차이는 0.37이며, 두 공급자는 구분할 수 없습니다.
한눈에 보기
- Q 42.05. BFCL 85.20%, HLE 15.34%, AA-LCR 49.20%. 공식 채널과의 차이는 −0.40%포인트이며, 95% 구간은 −1.46~+0.66으로 구분할 수 없습니다. AA-LCR에서는 요청 오류 28건이 발생했고 모두 1번 윈도우에서 발생했으며, 오답으로 계산했습니다.
- F 74.98. 집계 대상 검사 174개 중 124개를 통과했습니다.
reasoning_effort=none으로 설정해도 사고 모드가 꺼지지 않습니다. 입력 10k 토큰은 10,026토큰으로 보고됐고(네이티브 개수는 10,000), 입력 8토큰은 34로 보고됐습니다. - P 84.37. 본문 첫 토큰까지 걸린 시간은 동시성 1에서 중앙값 2.12초, 동시성 10에서 2.10초였습니다. TPOT는 3.43ms/토큰이었고, 속도 요청 180건 모두 유효했습니다.
- K 93.83. 8k 핫 요청은 9/9 적중했고, 32k는 8회 적중했습니다. 요청 1건은 마감 시간인 300초까지 완료되지 않았습니다.
- R 100. 전용 요청 300건 모두 첫 시도에 성공했습니다.
테스트 설정
| 항목 | 상세 정보 |
|---|---|
| 모델 | DeepSeek V4.1 Flash 1017 |
| 요청한 모델 ID | doubao-deepseek-v4.1-flash-1017 |
| 반환된 모델명 | deepseek-v4-1-flash-261017 |
| 접속 경로 | 공급자별 모델 ID를 사용해 AIHubMix 경유. 공급자 계정에 직접 연결한 것은 아님 |
| 매개변수 | 비사고 모드, temperature 1.0, max_tokens 16,384, 시간 제한 300 s, 자동 재시도 없음 |
| 사고 모드 끄기 | 응답 품질, 속도, 캐시, 안정성 요청에는 네이티브 thinking.type=disabled를 사용했습니다(이 공급자에서는 reasoning_effort=none으로 사고 모드가 꺼지지 않음). 함수 사례에서는 매개변수가 적용되는지 확인하기 위해 reasoning_effort=none을 그대로 사용했습니다. |
| 시간 | 2026-11-03 18:07 – 11-04 16:33 UTC+8. 다섯 공급자가 Mac mini 한 대, 네트워크 하나, 계정 하나를 공유했습니다. |
| 샘플 | 응답 품질 질문 인스턴스 4,250개(BFCL 500 × 3, HLE 250 × 10, AA-LCR 25 × 10), 함수 사례 60개 × 윈도우 3개, 속도 요청 동시성 1 90건 및 동시성 10 90건, 안정성 300건, 캐시 30건(8k 및 32k 접두사를 각각 세 그룹에서 테스트) |
요청에는 AIHubMix 빠른 시작 경로와 공급자별 ID를 사용했고, 매개변수는 DeepSeek의 API 문서를 따랐습니다. 다른 공급자의 ID는 모델 페이지에서 확인할 수 있습니다.
Q — 응답 품질: 42.05
응답 품질은 세 가지 제품군으로 평가합니다. BFCL 질문 500개를 각각 3회, HLE 질문 250개를 각각 10회, AA-LCR 질문 25개를 각각 10회 진행했습니다. BFCL은 자동 규칙으로 채점하고, HLE와 AA-LCR은 모델 deepseek-flash로 판정합니다. 다섯 공급자 모두 동일한 질문을 받았으며, 세 제품군을 합산해 하나의 정확도로 집계합니다. 채점할 수 없는 질문에 대한 답변 10개를 제외해, 채점 대상 질문 인스턴스는 4,240개였습니다.
| 제품군 | 질문 수 | 정답 수 | 정확도 | 오류 |
|---|---|---|---|---|
| BFCL 도구 호출 | 500 × 3 | 1,278/1,500 | 85.20% | 0 |
| HLE 고난도 QA | 250 × 10 | 382/2,490 | 15.34% | 7 |
| AA-LCR 장문 문서 추론 | 25 × 10 | 123/250 | 49.20% | 28 |
| 통합 · 95% 구간 39.70%–44.33% | — | 1,783/4,240 | 42.05% | 35 |
서비스 오류(요청 오류 또는 출력 잘림)는 분모에 포함하고 오답으로 계산합니다. HLE 출력은 max_tokens 한도에 7회 도달했고, AA-LCR에서는 요청 오류 28건이 발생했으며 모두 1번 윈도우에서 발생했습니다. BFCL은 자동 채점하고, HLE와 AA-LCR은 판정 모델로 채점합니다.
BFCL의 각 질문은 3회 답변을 받았으며, 표에는 3회분을 합산해 표시했습니다.
| BFCL 범주 | 통과 | 통과율 |
|---|---|---|
| simple_python — 함수 하나, 올바른 호출과 인수 | 329/360 | 91.39% |
| multiple — 여러 함수 중 하나 선택 | 268/300 | 89.33% |
| parallel — 동일한 함수를 여러 번 호출 | 271/300 | 90.33% |
| parallel_multiple — 서로 다른 함수를 여러 개 호출 | 207/240 | 86.25% |
| irrelevance — 관련 함수가 없어 호출하지 않아야 함 | 102/150 | 68.00% |
| ahm_multi_turn — 3단계 도구 체인 | 101/150 | 67.33% |
나머지 네 곳과 비교
공식 채널과의 차이를 %포인트로 표시하고, 95% 구간은 오차 막대로 나타냅니다. 구간이 0을 지나면 구분할 수 없는 것으로 기록합니다. 판정 모델 deepseek-flash는 테스트 대상 모델과 같은 DeepSeek 계열에 속하며 보정되지 않았으므로, 판정이 관대할 수 있습니다.
F — 함수 지원: 74.98
함수 제품군은 인터페이스 동작이 프로토콜과 일치하는지만 평가하며, 모델의 답변 품질은 평가하지 않습니다. 6개 그룹의 사례 60개를 윈도우마다 한 번씩, 총 3회 실행해 180개를 검사했으며, 각 공급자가 문서화한 형식에 따라 판정했습니다. 해당 없음, 유효하지 않음 또는 관측되지 않은 검사는 분모에서 제외합니다. ByteDance는 집계 대상 검사 174개 중 124개를 통과했으며, 그룹별 가중치 기준 점수는 74.98입니다.
가중 점수는 그룹별 가중치를 적용한 결과이며, 통과 검사 수를 174로 나눈 값이 아닙니다.
| 그룹 | 가중치 | 통과 | 제외 | 그룹 점수 |
|---|---|---|---|---|
| 스트리밍 및 메시지 프로토콜 | 20% | 23/27 | 3 | 85.19 |
| 도구 인터페이스 | 20% | 30/30 | — | 100.00 |
| 출력 제약 및 매개변수 | 20% | 24/30 | — | 80.00 |
| 컨텍스트 및 상태 | 15% | 14/30 | — | 46.67 |
| 오류 및 복구 | 15% | 21/30 | — | 70.00 |
| 사용량 집계 및 캐시 프로토콜 | 10% | 12/27 | 3 | 44.44 |
| 합계 · 가중 점수 | — | 124/174 | 6 | 74.98 |
“실패한 윈도우”는 검사에 실패한 3개 윈도우의 수입니다.
| 실패한 사례 | 실패한 윈도우 | 이유 |
|---|---|---|
| 추론이 콘텐츠에 노출되지 않음 — 스트리밍 및 메시지 프로토콜 | 3/3 | reasoning_effort=none으로 설정해도 사고 콘텐츠가 반환됨 |
| 사고 모드 설정 적용 — 출력 제약 및 매개변수 | 3/3 | reasoning_effort=none으로 설정해도 사고 콘텐츠가 반환됨 |
| 샘플링 다양성 — 출력 제약 및 매개변수 | 3/3 | temperature 0과 1에서 출력 차이가 사전 등록된 임계값보다 작았음 |
| 10k 장문 입력 — 컨텍스트 및 상태 | 3/3 | 입력 토큰 수를 10,026으로 보고함. 네이티브 개수는 10,000이어야 함 |
| 컨텍스트 한도 이내 — 컨텍스트 및 상태 | 3/3 | 입력 토큰 수를 10,026으로 보고함. 네이티브 개수는 10,000이어야 함 |
| 32k 장문 입력 — 컨텍스트 및 상태 | 3/3 | 입력 토큰 수를 10,026으로 보고함. 네이티브 개수는 10,000이어야 함 |
| 100k 장문 입력 — 컨텍스트 및 상태 | 3/3 | 입력 토큰 수를 10,026으로 보고함. 네이티브 개수는 10,000이어야 함 |
| 컨텍스트 한도 초과 — 컨텍스트 및 상태 | 3/3 | 업스트림 연결 실패 또는 시간 초과(1). 매개변수 오류를 반환해야 하지만 200을 반환함(2) |
| 12턴 대화 기록 — 컨텍스트 및 상태 | 1/3 | 업스트림 연결 실패 또는 시간 초과 |
| messages 형식 오류 — 오류 및 복구 | 3/3 | 본문이 비어 있는 400을 반환함. 구조화된 오류 설명 없음 |
| 고아 도구 결과 — 오류 및 복구 | 3/3 | 매개변수 오류를 반환해야 하지만 200을 반환함 |
| stream_options 형식 오류 — 오류 및 복구 | 3/3 | 본문이 비어 있는 400을 반환함. 구조화된 오류 설명 없음 |
| 사고 토큰 집계 — 사용량 집계 및 캐시 프로토콜 | 3/3 | 사고 모드를 비활성화한 후에도 사고 토큰을 보고함 |
| 네이티브 입력 개수 — 사용량 집계 및 캐시 프로토콜 | 3/3 | 34토큰으로 보고함. 네이티브 개수는 8이어야 함 |
| 입력에 포함된 도구 정의 — 사용량 집계 및 캐시 프로토콜 | 3/3 | 도구가 없는 대조 요청에서도 네이티브 입력 개수와 이미 불일치함 |
| 캐시 전후의 입력 개수 일관성 — 사용량 집계 및 캐시 프로토콜 | 3/3 | 동일한 접두사를 반복 사용했을 때 보고된 입력 토큰 수가 네이티브 개수와 일치하지 않음 |
| 스트리밍 및 비스트리밍 입력 일관성 — 사용량 집계 및 캐시 프로토콜 | 3/3 | 둘 다 34토큰으로 보고함. 네이티브 개수는 8이어야 함 |
| 정확한 텍스트 출력 — 스트리밍 및 메시지 프로토콜 | 1/3 | 본문 끝에 마침표가 하나 더 붙음. 요청한 텍스트와 정확히 일치하지 않음 |
이 검사들은 분모에서 제외하며, 통과나 실패 어느 쪽으로도 계산하지 않습니다.
| 상태 | 사례 | 수 | 이유 |
|---|---|---|---|
| 관측되지 않음 | 스트리밍 중지 시퀀스 | 3 | 이전 단계 이후 이 요청을 보내지 않아 판정할 수 없음 |
| 해당 없음 | 명시적 cache_control | 3 | 이 인터페이스에서 지원하지 않는다고 사전 등록됨 |
messages 형식 오류와 stream_options 형식 오류 사례는 다섯 공급자 모두에서 실패했습니다. 둘 다 본문이 비어 있는 400을 반환해 클라이언트가 구조화된 오류 설명을 받지 못했습니다. 다섯 공급자 모두에서 발생한 실패는 AIHubMix 게이트웨이 계층의 문제일 가능성이 높으며 별도 조사가 필요합니다. 사고 토큰 집계도 다섯 공급자 모두에서 실패했지만 원인은 달랐습니다. ByteDance와 Fireworks는 사고 모드를 비활성화한 뒤에도 사고 토큰을 보고했고, 나머지 세 곳은 사고 토큰 수를 반환하지 않았습니다.
나머지 네 곳과 비교
P — 응답 속도: 84.37
각 요청에는 입력 토큰 약 10,000개가 포함됐고, 본문 텍스트로 출력 토큰 약 1,100개를 요청했습니다. 세 윈도우 각각에서 동시성 1로 요청 30건, 동시성 10으로 요청 30건을 실행해 총 180건을 보냈습니다.
| 지표 | 결과 |
|---|---|
| 본문 첫 토큰 대기 시간(TTFA) | 동시성 1에서 중앙값 2.12초, 동시성 10에서 중앙값 2.10초 |
| 생성 속도(TPOT) | 동시성 1에서 3.43ms/토큰, 동시성 10에서 3.41ms/토큰 |
| 실효 처리량 | 동시성 10에서 1,250.0 token/s |
| 유효한 요청 | 동시성 1에서 90/90, 동시성 10에서 90/90 |
| 구성 점수 | TTFA 48.59, TPOT 100.00, 처리량 100.00. TTFA와 TPOT에는 두 티어 중 낮은 값을 적용합니다. 가중치 35% / 35% / 30%. 응답 점수 82.00 |
| P 점수 | 응답 점수 82.00에 80%, 캐시 K 93.83에 20%를 적용해 총 84.37 |
TPOT는 하드웨어에서 토큰별로 측정한 값이 아니라 스트리밍 청크를 기반으로 추정합니다. 처리량은 동시성 10에서 유효 출력 토큰 수를 배치의 총 경과 시간으로 나눈 값입니다.
나머지 네 곳과 비교
다섯 공급자가 기기, 네트워크, 계정 하나를 공유했습니다. 세 윈도우는 공급자별로 순차 예약되어 데이터 수집 기간이 완전히 겹치지는 않습니다. 작은 차이를 과도하게 해석하지 마세요.
K — 캐시: 93.83
각 그룹은 요청 5건을 보냅니다. 첫 요청에는 약 8k 또는 32k 토큰의 고정 접두사를 넣어 캐시를 채웁니다. 요청 2~4에서는 접두사를 그대로 두고 마지막 질문만 바꿔 5초, 30초, 120초 간격으로 보냅니다. 다섯 번째 요청은 새 접두사를 사용해 콜드 대조군으로 삼습니다. 윈도우 3개와 길이 2종에 그룹당 요청 5건을 실행해 총 30건입니다. K는 핫 요청에서 캐시로 읽은 토큰 수를 규칙상 재사용할 수 있어야 하는 토큰 수로 나눈 값이며, 두 길이는 동일한 가중치를 적용합니다. K는 P의 20%를 차지합니다.
| 접두사 | 윈도우 | 시드 | +5 s | +30 s | +120 s | 콜드 대조군 |
|---|---|---|---|---|---|---|
| 8k | 윈도우 1 | 0 | 7,936 | 7,936 | 7,936 | 0 |
| 8k | 윈도우 2 | 0 | 7,936 | 7,936 | 7,936 | 0 |
| 8k | 윈도우 3 | 0 | 7,936 | 7,936 | 7,936 | 0 |
| 32k | 윈도우 1 | 0 | 32,000 | 32,000 | 32,000 | 0 |
| 32k | 윈도우 2 | 0 | 32,000 | 32,000 | 실패 | 0 |
| 32k | 윈도우 3 | 0 | 32,000 | 32,000 | 32,000 | 0 |
서버가 보고한 캐시 읽기 토큰 값입니다.
8k 핫 요청 9건은 모두 적중해 각각 7,936토큰을 읽었습니다. 32k 핫 요청 9건 중 8건이 적중해 각각 32,000토큰을 읽었고, 요청 1건은 실패했습니다. 두 길이에 동일한 가중치를 적용한 K는 93.83입니다. 콜드 요청은 캐시를 읽지 않았으므로 핫 요청과 콜드 요청을 명확히 구분할 수 있습니다. 실패한 요청은 윈도우 2의 32k 그룹에서 네 번째 요청으로, 완료되지 않은 채 300 s 마감 시간에 도달했습니다.
나머지 4개와 비교
R — 서비스 안정성: 100
300건의 요청은 짧은 텍스트, 긴 입력, 도구 호출, 멀티턴 대화 기록의 네 가지 유형으로 나뉘며, 세 개 윈도우에서 동시성 1로 실행했습니다. 첫 시도에서 유효하고 완전한 응답을 반환한 경우에만 요청을 성공으로 계산했습니다. 답변의 정확성은 확인하지 않았고 재시도도 없습니다. 답변 품질과 속도 섹션의 실패는 Q와 P에 반영되며, R에 다시 반영하지 않습니다.
| 요청 유형 | 첫 시도 성공률 |
|---|---|
| 짧은 텍스트 | 120/120 |
| 10k 장문 입력 | 90/90 |
| 도구 호출 | 60/60 |
| 멀티턴 대화 기록 | 30/30 |
| 전체 · 95% 구간 98.78%–100% | 300/300 |
300건의 요청 모두 첫 시도에서 유효하고 완전한 응답을 반환했습니다. R = 100은 이 300건의 전용 요청만을 나타내며, 전체 체인에서 실패가 없었다는 뜻은 아닙니다. 95% 구간의 하한은 98.78%입니다. 성공 300건만으로는 실패율이 1.22% 미만일 가능성이 높다고 말할 수 있을 뿐입니다.
나머지 4개와 비교
R에는 이 300건의 전용 요청만 반영됩니다. 답변 품질과 속도 섹션의 실패는 Q와 P에 기록되며, R에 다시 반영하지 않습니다.
| 공급자 | 첫 시도 성공률 | 95% 구간 |
|---|---|---|
| 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% |
자주 묻는 질문
reasoning_effort=none이 실제로 사고 모드를 끄지 못했나요?
네. 세 윈도우 모두에서 reasoning_effort=none 요청이 여전히 사고 내용을 반환해, 확인에 3/3 실패했습니다. 답변 품질, 속도, 캐시, 안정성 요청에서는 대신 기본 thinking.type=disabled 스위치를 사용했습니다. 함수 테스트 모음에서는 매개변수가 적용되는지 확인하기 위해 의도적으로 reasoning_effort=none을 사용했습니다.
BFCL 정확도는 85.20%인데, Q가 42.05인 이유는 무엇인가요?
Q는 난이도가 매우 다른 세 가지 테스트 모음의 결과를 합산합니다. BFCL은 1,500개 중 1,278개, HLE는 2,490개 중 382개, AA-LCR은 250개 중 123개를 맞혔습니다. 채점 대상인 질문 사례 4,240개 중 정답은 총 1,783개로, 42.05%입니다. HLE의 15.34%가 통합 수치를 끌어내립니다.
Q에는 서비스 오류 35건도 포함되나요?
네. 요청 실패와 잘린 출력은 분모에 그대로 포함되며 오답으로 계산됩니다. HLE 답변 7건은 max_tokens에서 잘렸고, AA-LCR 요청 28건은 모두 윈도우 1에서 실패했습니다.
입력 토큰 집계가 중요한 이유는 무엇인가요?
과금 집계가 모델의 기본 토큰 수와 일치해야 하기 때문입니다. 10k 토큰 입력은 10,026토큰으로 보고됐고(기본값은 10,000), 8토큰 입력은 34로 보고됐습니다. 도구를 사용하지 않는 대조 요청에서도 이미 차이가 있었으며, 스트리밍과 비스트리밍 모두 34를 보고했습니다. 토큰 집계 확인 5건은 모두 3/3 실패했습니다.
32k 캐시 결과는 미스였나요, 실패였나요?
실패였습니다. 32k 핫 요청 9건 중 8건이 적중해 32,000토큰을 읽었습니다. 미스 1건은 윈도우 2의 네 번째 요청으로, 완료되지 않은 채 300 s 마감 시간에 도달했습니다. 8k 그룹은 9/9 적중해 7,936토큰을 읽었습니다.
ByteDance와 공식 채널의 답변 품질을 구분할 수 있나요?
아니요. 통합 정확도는 공식 채널보다 0.40포인트 낮으며, 95% 구간은 −1.46~+0.66입니다. 이 구간에는 0이 포함되므로 둘을 구분할 수 없습니다. 이는 이번 배치에만 해당하는 결과이며 순위를 나타내지는 않습니다.
계속 읽기: DeepSeek V4.1 Flash 시리즈
- 이 글의 Q 기준은 공식 채널입니다. 유효하지 않은 단일 동시성 프로브 15건을 포함한 공식 채널 자체 실행 결과는 공식 채널의 DeepSeek V4.1 Flash: F 94.00, 유효하지 않은 프로브 15건에서 다룹니다.
- Q 구간이 공식 채널보다 낮은 공급자는 Baidu뿐입니다. 이 결과를 낳은 채널 실패는 Baidu의 DeepSeek V4.1 Flash: 사용 가능한 채널이 없어 Q와 P에 도달하지 못함에서 확인할 수 있습니다.
- Alibaba Cloud의 캐시 수치는 여기서 보고한 93.83과 함께 살펴볼 만합니다. Alibaba Cloud의 DeepSeek V4.1 Flash: 첫 토큰 1.34s, 캐시 적중률 99.37.
- Fireworks에서도 여기서 확인한 사고 모드 및 토큰 집계 실패가 나타났으며, 빈 stop 응답도 추가로 확인됐습니다. Fireworks의 DeepSeek V4.1 Flash: 빈 stop 응답, 캐시 적중 3/9.
