2026-11-03/04, APB Full 제품군을 AIHubMix를 통해 5개 공급자의 DeepSeek V4.1 Flash 1017에 실행했습니다. 모든 공급자에 동일한 질문, 매개변수, 요청 스크립트를 사용했으며, 5개 공급자 항목은 모델 페이지에서 확인할 수 있습니다. 이 APB 프로필은 DeepSeek 공식 채널만 다룹니다. DeepSeek API에 직접 연결한 것이 아니라 AIHubMix의 DeepSeek 공식 공급자 경로를 통해 이용했습니다.
이 게시물은 점수만 보고하며, 공급자 순위를 매기거나 특정 공급자를 추천하지 않습니다. Q 42.45, F 94.00, P 86.14, K 98.38, R 100입니다. Q, F, P, R은 네 가지 섹션 점수이고 K는 P의 하위 점수입니다. 종합 점수 73.76은 요약 지표일 뿐 인증 점수가 아니며, 신뢰 구간도 없습니다. 점수 산정 기준은 AIHubMix Provider Benchmark Standard v2.0입니다.
5개 공급자 점수
굵은 글씨는 이 게시물에서 다루는 공급자를 나타냅니다. 공급자 순서는 고정되어 있으며 순위가 아닙니다. K는 P의 하위 점수로 가중치가 20%이며 참고용으로 별도 표기했습니다. 종합 점수는 신뢰 구간이 없는 요약 지표입니다. DeepSeek 공식 채널과 Alibaba Cloud의 종합 점수 차이는 0.37로, 두 공급자를 구분할 수 없습니다.
한눈에 보기
- 답변 품질: Q 42.45. BFCL 86.13%, HLE 15.06%, AA-LCR 53.20%. HLE 출력 7건이 max_tokens 한도에서 잘려 오답으로 처리됐습니다. 이 채널은 나머지 4개 공급자와 비교할 때 Q 기준선입니다.
- 함수 지원: F 94.00. 집계 대상 검사 147건 중 137건을 통과했습니다. 정확한 토큰 수에 의존하는 검사 27건은 추가로 무효 판정되어 분모에서 제외됐습니다.
- 응답 속도: P 86.14. 단일 동시성 첫 번째 윈도에서 요청 30건 중 15건이 무효 처리됐습니다(503 12건, deadline 2건, read timeout 1건). 이 요청들은 무한대로 계산했습니다. 첫 토큰 중앙값은 1.87초(유효 요청만 계산하면 1.72초), 동시성 10에서는 1.72초, TPOT는 2.84ms였습니다.
- 캐시: K 98.38. 8k 및 32k에서 핫 요청 18건 모두 캐시 적중했고, 콜드 대조 요청은 캐시를 읽지 않았습니다.
- 서비스 안정성: R 100. 전용 요청 300건 모두 첫 시도에 성공했습니다.
테스트 설정
DeepSeek 공식 공급자 경로를 선택해 AIHubMix를 통해 요청을 보냈습니다. 액세스 구성은 빠른 시작을 참고하세요.
| 항목 | 세부 정보 |
|---|---|
| 모델 | DeepSeek V4.1 Flash 1017 |
| 요청한 모델 ID | deepseek-flash |
| 반환된 모델 이름 | deepseek-flash |
| 액세스 경로 | AIHubMix DeepSeek 공식 공급자 경로. DeepSeek API에 직접 연결한 것이 아님 |
| 매개변수 | 비사고 모드, temperature 1.0, max_tokens 16,384, 타임아웃 300 s, 자동 재시도 없음 |
| 사고 모드 끔 | 모든 요청에 reasoning_effort=none 사용 |
| 시간 | 2026-11-03 18:07 – 11-04 16:33 UTC+8. 5개 공급자 모두 Mac mini 한 대, 네트워크, 계정을 공유 |
| 표본 | 답변 품질 4,250회 시도(BFCL 500 × 3, HLE 250 × 10, AA-LCR 25 × 10); 함수 사례 윈도 3개에서 각 60건; 속도는 단일 동시성 90건, 동시성 10에서 90건; 안정성 300건; 캐시 30건(8k 및 32k 접두사 각각 3개 그룹) |
Q — 답변 품질: 42.45
제품군에는 BFCL 질문 500개 × 3회 실행, HLE 250개 × 10회, AA-LCR 25개 × 10회가 포함됩니다. BFCL은 자동 규칙으로 채점하고, HLE와 AA-LCR은 심사 모델 deepseek-flash로 채점합니다. 5개 공급자 모두 동일한 질문에 답했습니다. 답변 10건은 채점할 수 없어 제외했으며, 채점된 시도는 4,240회입니다.
| 벤치마크 | 질문 수 | 정답 | 정확도 | 실패 |
|---|---|---|---|---|
| BFCL 도구 호출 | 500 × 3 | 1,292/1,500 | 86.13% | 0 |
| HLE 어려운 QA | 250 × 10 | 375/2,490 | 15.06% | 7 |
| AA-LCR 장문서 추론 | 25 × 10 | 133/250 | 53.20% | 0 |
| 합계 · 95% 신뢰 구간 40.08%–44.73% | 채점 대상 4,240건 | 1,800/4,240 | 42.45% | 7 |
서비스 실패(요청 실패 또는 출력 잘림)는 분모에 포함되며 오답으로 계산됩니다. 이 사례에서는 max_tokens 한도에 도달한 HLE 출력 7건이 해당합니다. BFCL은 자동 채점하고, HLE와 AA-LCR은 심사 모델로 채점합니다.
BFCL 분모는 3회 실행 합계입니다.
| BFCL 범주 | 통과 | 통과율 |
|---|---|---|
| simple_python — 함수 하나, 올바른 호출과 인수 | 334/360 | 92.78% |
| multiple — 여러 함수 중 적절한 함수 선택 | 268/300 | 89.33% |
| parallel — 동일한 함수를 여러 번 병렬 호출 | 271/300 | 90.33% |
| parallel_multiple — 서로 다른 여러 함수를 병렬 호출 | 207/240 | 86.25% |
| irrelevance — 관련 함수가 없으므로 아무 함수도 호출하지 않아야 함 | 113/150 | 75.33% |
| ahm_multi_turn — 3단계 도구 체인 | 99/150 | 66.00% |
나머지 4개와 비교
각 차이는 이 기준선과의 퍼센트 포인트 차이이며, 수염으로 95% 구간을 표시했습니다. 구간이 0을 넘나들면 구분할 수 없습니다. 심사 모델은 테스트 대상 모델과 같은 DeepSeek 계열이며 보정되지 않았으므로 HLE와 AA-LCR 채점이 관대할 수 있습니다.
F — 함수 지원: 94.00
함수 사례는 답변 품질이 아니라 프로토콜 동작을 테스트합니다. 6개 그룹에서 사례 60건을 윈도 3개에 걸쳐 실행해 총 180건을 공급자별 문서에 명시된 형식과 비교해 판정했습니다. 적용 불가, 무효, 관측 불가 검사는 분모에서 제외됩니다. 이 채널은 집계 대상 검사 147건 중 137건을 통과해 가중 점수 94.00을 받았습니다. 가중 점수는 단순한 137/147이 아닙니다.
| 그룹 | 가중치 | 통과 | 제외 | 그룹 점수 |
|---|---|---|---|---|
| 스트리밍 및 메시지 프로토콜 | 20% | 27/27 | 3 | 100.00 |
| 도구 인터페이스 | 20% | 30/30 | — | 100.00 |
| 출력 제약 및 매개변수 | 20% | 30/30 | — | 100.00 |
| 컨텍스트 및 상태 | 15% | 14/15 | 15 | 93.33 |
| 오류 및 복구 | 15% | 24/30 | — | 80.00 |
| 사용량 측정 및 캐시 프로토콜 | 10% | 12/15 | 15 | 80.00 |
| 합계 · 가중치 적용 | — | 137/147 | 33 | 94.00 |
가중 점수는 그룹별 가중치를 따릅니다. 통과한 검사 수를 147로 나눈 값이 아닙니다.
| 실패한 사례 | 실패한 윈도 | 이유 |
|---|---|---|
| 잘못된 형식의 메시지(오류 및 복구) | 3/3 | 400을 반환했으나 본문이 비어 있어 구조화된 오류 설명이 없음 |
| 잘못된 형식의 stream_options(오류 및 복구) | 3/3 | 400을 반환했으나 본문이 비어 있어 구조화된 오류 설명이 없음 |
| 사고 토큰 사용량 측정(사용량 측정 및 캐시 프로토콜) | 3/3 | 사고 토큰 수가 반환되지 않음 |
| 요청 격리(컨텍스트 및 상태) | 1/3 | 첫 단계에서 요구된 대로 STORED만 반환하지 않아 격리 검사를 진행할 수 없었음 |
제외된 검사는 통과나 실패 어느 쪽에도 포함되지 않습니다.
| 상태 | 사례 | 개수 | 이유 |
|---|---|---|---|
| 관측 불가 | 스트리밍 종료 시퀀스 | 3 | 이전 단계 이후 이 단계의 요청이 전송되지 않아 판정할 수 없었음 |
| 무효 | 10k 장문 입력; 컨텍스트 한도 내; 32k 장문 입력; 100k 장문 입력; 컨텍스트 초과; 네이티브 입력 수; 입력에서 계산된 도구 정의; 캐시 전후 입력 수 일관성; 스트리밍과 비스트리밍 입력 일관성 | 27 | 테스트 측에 고정한 네이티브 수 템플릿이 이 채널에서 보고한 사용량과 일치하지 않아 정확한 수에 의존하는 검사는 무효로 판정해 분모에서 제외했습니다. |
| 해당 없음 | 명시적 cache_control | 3 | 이 인터페이스에서 지원되지 않는 것으로 사전 등록됨 |
무효 검사 27건은 목록에 있는 장문 입력, 컨텍스트 한도, 네이티브 수, 캐시 일관성 사례입니다. 고정 템플릿이 이 채널에서 보고한 사용량과 일치하지 않았으므로 정확한 수에 의존하는 검사는 모두 점수화하지 않고 제외했습니다.
잘못된 형식의 messages와 잘못된 형식의 stream_options는 5개 공급자 모두에서 실패했습니다. 두 경우 모두 400을 반환했지만 본문이 비어 있어 클라이언트에 구조화된 오류 설명이 전달되지 않았습니다. 이러한 공통 패턴은 AIHubMix 게이트웨이 계층의 문제일 가능성이 더 높으며 별도 조사가 필요합니다. 사고 토큰 사용량 측정도 5개 공급자 모두에서 실패했지만 원인은 달랐습니다. ByteDance와 Fireworks는 사고 모드를 꺼도 사고 토큰을 보고했고, 나머지 3개는 사고 토큰 수를 반환하지 않았습니다.
나머지 4개와 비교
P — 응답 속도: 86.14
각 요청에는 입력 토큰 약 10,000개가 포함됐고 출력 토큰 약 1,100개를 요청했습니다. 윈도 3개에서 각각 단일 동시성 요청 30건과 동시성 10 요청 30건을 보내 총 180건을 실행했습니다.
| 측정 항목 | 값 |
|---|---|
| 첫 토큰 TTFA | 단일 동시성: 중앙값 1.87초(유효 요청 중앙값 1.72초). 동시성 10: 중앙값 1.72초 |
| TPOT | 단일 동시성: 토큰당 2.84ms. 동시성 10: 토큰당 2.67ms |
| 유효 처리량(goodput) | 동시성 10: 1,546.0 token/s |
| 유효 요청 | 단일 동시성 75/90(윈도 1: 15/30); 동시성 10 90/90. 무효: 503 service_unavailable_error 12건, deadline reached 2건, read timeout 1건 |
| 구성 요소 점수 | TTFA 51.65, TPOT 100.00, 처리량 100.00. TTFA와 TPOT는 두 티어 중 낮은 쪽을 적용하고, 가중치는 35% / 35% / 30%입니다. 응답 점수 83.08 |
| P 구성 | 응답 점수 83.08에 가중치 80%, 캐시 K 98.38에 가중치 20%를 적용해 P 86.14 |
무효 요청 15건은 모두 단일 동시성 첫 번째 윈도에서 발생했습니다. 12건은 503을 반환했고, 2건은 기한에 도달했으며, 1건은 읽기 타임아웃이 발생했습니다. 무효 요청은 무한대로 계산하므로 보고된 중앙값은 1.87초입니다. 유효 요청만 보면 중앙값은 1.72초입니다. 동시성 10에서도 중앙값은 1.72초입니다. TPOT는 단일 동시성에서 토큰당 2.84ms, 동시성 10에서 토큰당 2.67ms입니다.
나머지 4개와 비교
5개 공급자는 Mac mini 한 대, 네트워크, 계정을 공유했습니다. 세 윈도는 공급자별로 일정을 나눠 진행했으므로 데이터 수집 기간이 완전히 겹치지는 않습니다. 작은 차이를 지나치게 해석하지 않도록 주의하세요.
K — 캐시: 98.38
각 그룹은 요청 5건을 보냅니다. 첫 번째 요청은 고정된 8k 또는 32k 접두사를 캐시에 저장합니다. 2~4번째 요청은 접두사를 유지하고 마지막 질문만 바꾸며, 5초, 30초, 120초 간격으로 전송합니다. 다섯 번째 요청은 콜드 대조군으로 새 접두사를 사용합니다. 길이 두 가지에 윈도 3개를 적용해 총 30건을 보냅니다. K는 핫 요청에서 읽은 캐시 토큰을 재사용 가능해야 하는 토큰 수로 나누고, 길이별 가중치는 절반씩 적용합니다. K는 P의 20%를 차지합니다. 컨텍스트 캐싱은 DeepSeek의 API 문서를 참고하세요.
| 접두사 | 윈도 | 시드 | +5 s | +30 s | +120 s | 콜드 대조군 |
|---|---|---|---|---|---|---|
| 8k | 윈도 1 | 0 | 7,808 | 7,808 | 7,808 | 0 |
| 8k | 윈도 2 | 0 | 7,808 | 7,808 | 7,808 | 0 |
| 8k | 윈도 3 | 0 | 7,808 | 7,808 | 7,808 | 0 |
| 32k | 윈도 1 | 0 | 31,872 | 31,872 | 31,872 | 0 |
| 32k | 윈도 2 | 0 | 31,872 | 31,872 | 31,872 | 0 |
| 32k | 윈도 3 | 0 | 31,872 | 31,872 | 31,872 | 0 |
8k 핫 요청은 9건 중 9건에서 캐시 적중했고 각 요청에서 7,808개 토큰을 읽었습니다. 재사용 가능 토큰 72,261개 중 70,272개를 읽어 점수는 97.25였습니다. 32k 핫 요청은 9건 중 9건에서 캐시 적중했고 각 요청에서 31,872개를 읽었습니다. 재사용 가능 토큰 288,270개 중 286,848개를 읽어 점수는 99.51이었습니다. 콜드 대조군은 캐시를 읽지 않았습니다. 두 길이를 합친 K는 98.38입니다.
나머지 4개와 비교
R — 서비스 안정성: 100
요청 300건은 짧은 텍스트, 10k 장문 입력, 도구 호출, 다중 턴 기록을 대상으로 하며, 윈도 3개에 걸쳐 단일 동시성으로 전송했습니다. 답변의 정확성이 아닌 첫 시도 유효성과 완전성만 검사하며 재시도는 없습니다. 답변 품질과 속도에서 발생한 실패는 Q와 P에 반영되므로 R에 다시 포함하지 않습니다.
| 요청 유형 | 첫 시도 성공 |
|---|---|
| 짧은 텍스트 | 120/120 |
| 10k 장문 입력 | 90/90 |
| 도구 호출 | 60/60 |
| 다중 턴 기록 | 30/30 |
| 합계 · 95% 신뢰 구간 98.78%–100% | 300/300 |
300건의 요청 모두 첫 시도에서 유효하고 완전한 응답을 반환했습니다. R 100은 이 전용 요청 300건만 다루며, 전체 경로에 실패가 없었다는 뜻은 아닙니다. 300건이 모두 성공한 경우 95% 신뢰 구간의 하한은 98.78%이므로, 실패율이 1.22% 미만일 가능성이 높다는 근거가 됩니다.
나머지 네 곳과 비교
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 공식 | 300/300 | 98.78%–100% |
| Fireworks | 300/300 | 98.78%–100% |
자주 묻는 질문
DeepSeek API에 직접 연결되나요?
아니요. 요청은 AIHubMix의 DeepSeek 공식 공급자 경로를 거치며, DeepSeek API로 직접 전송되지 않습니다.
DeepSeek 공식 채널을 Q의 기준선으로 삼은 이유는 무엇인가요?
같은 모델을 제공하는 DeepSeek의 공식 채널이므로, 나머지 네 공급자의 응답 품질 결과를 이 채널과 비교한 차이로 표시합니다. 기준선이라는 역할이 응답 품질 순위를 뜻하는 것은 아닙니다.
첫 번째 단일 동시성 속도 측정 구간에서는 어떤 일이 있었나요?
요청 30건 중 15건이 유효하지 않았습니다. 12건은 503을 반환했고, 2건은 제한 시간에 도달했으며, 1건은 읽기 시간 초과가 발생했습니다. 이 요청들은 무한대로 집계되므로 중앙값은 1.87초이며, 유효한 요청만 보면 1.72초입니다.
유효하지 않은 함수 검사 27건은 무엇인가요?
정확한 토큰 수에 따라 달라지는 검사입니다. 긴 입력, 컨텍스트 제한, 네이티브 입력 수, 캐시 입력 일관성을 확인합니다. 테스트 측에서 고정한 네이티브 입력 수 템플릿이 이 채널에서 보고한 사용량과 일치하지 않아, 해당 검사들은 실패로 채점하지 않고 분모에서 제외했습니다.
R 100으로 경로에 실패가 없다고 보장할 수 없는 이유는 무엇인가요?
R은 전용 안정성 요청 300건만 다룹니다. 응답 품질 및 속도 측정 중 발생한 실패는 Q와 P에 기록됩니다. 300건 모두 성공한 경우 95% 신뢰 구간의 하한은 98.78%이므로, 실패율이 1.22% 미만일 가능성이 높다는 뜻이지 실패율이 0이라고 입증된 것은 아닙니다.
캐시 테스트에서는 캐시 적중 읽기와 콜드 읽기를 어떻게 구분하나요?
각 그룹에서 8k 또는 32k 프리픽스를 먼저 입력한 뒤, 새로운 마지막 질문을 붙여 5초, 30초, 120초 후에 해당 프리픽스를 반복 전송하고, 콜드 대조군으로 새로운 프리픽스를 전송합니다. 두 길이 모두 캐시 적중 요청 9건 중 9건을 기록했으며, 모든 콜드 대조군 읽기에서 캐시된 토큰은 0개였습니다.
계속 읽기: DeepSeek V4.1 Flash 시리즈
- ByteDance의 Q는 이 기준선과 0.40점 이내의 차이를 보이지만, 함수 지원 및 캐시 결과는 다릅니다. ByteDance의 DeepSeek V4.1 Flash: 도구 호출은 일치하지만 사용량 집계는 다름.
- Baidu에서는
no_available_channel로 인해 요청이 손실됐으며, 이는 Q와 P 모두에 나타납니다. Baidu의 DeepSeek V4.1 Flash: 사용 가능한 채널 없음 오류가 Q와 P에 영향. - Alibaba Cloud는 전체 점수에서 0.37 차이를 보이며, 통계적으로 구분할 수 없습니다. Alibaba Cloud의 DeepSeek V4.1 Flash: 첫 토큰 1.34초, 캐시 99.37.
- Fireworks는 8k 캐시 적중 요청 9건 중 3건만 기록했으며, 여기서는 9건 중 9건이 적중했습니다. Fireworks의 DeepSeek V4.1 Flash: 빈 stop 응답, 캐시 적중 3/9.
