2026-11-03/04, APB Full 테스트 스위트를 AIHubMix를 통해 5개 공급자의 DeepSeek V4.1 Flash 1017에 실행했습니다. 모든 공급자에 동일한 모델, 질문, 매개변수 및 요청 스크립트를 사용했습니다. 모델은 AIHubMix 모델 페이지에 등록되어 있으며, 5개 공급자 항목은 모델 페이지에서 확인할 수 있습니다. 이 APB Profile은 Alibaba Cloud만 다룹니다. 각 섹션에서 무엇을 측정했고 어떤 결과가 나왔는지 살펴봅니다.
이 게시물은 공급자 순위를 매기거나 특정 공급자를 추천하지 않고 점수만 보고합니다. Q, F, P, K, R 순으로 살펴보며, K는 P의 하위 점수입니다. 종합 점수는 요약 지표이지 인증이 아니며, 신뢰 구간도 없습니다. 점수 산정 규칙은 AIHubMix Provider Benchmark Standard v2.0에 정의되어 있습니다.
5개 공급자의 점수 비교
굵은 글씨는 이 게시물에서 다루는 공급자입니다. 공급자는 순위가 아니라 고정된 순서로 표시했습니다. K는 P의 하위 점수로, 20%를 차지하며 참고용으로 별도 표시했습니다. 종합 점수는 신뢰 구간이 없는 요약 지표입니다. DeepSeek 공식 채널과 Alibaba Cloud의 종합 점수 차이는 0.37이며, 둘을 구분할 수 없습니다.
한눈에 보기
- 응답 품질: Q 41.75. BFCL 87.00%, HLE 13.29%, AA-LCR 53.60%입니다. 공식 채널과 비교한 차이는 −0.71%포인트이며, 95% 구간은 −1.72~+0.26이므로 두 채널을 구분할 수 없습니다.
- 함수 지원: F 89.78. 분모에 포함된 177개 검사 중 155개를 통과했습니다. 잘못된 도구 스키마에 매개변수 오류 대신 503을 반환했고, 컨텍스트 초과 시 문서에 명시된 오류 유형을 반환하지 않았으며, 단독 도구 결과에는 200을 반환했습니다.
- 응답 속도: P 88.58. 첫 콘텐츠 토큰의 중앙값은 동시성 1에서 1.34 s, 동시성 10에서 1.35 s였고, TPOT는 4.69 ms였으며, 속도 측정 요청 180개가 모두 유효했습니다.
- 캐시: K 99.37. 8k 및 32k 프리픽스에 걸친 핫 요청 18개가 모두 캐시 적중했으며, 콜드 대조 요청은 캐시를 읽지 않았습니다.
- 서비스 안정성: R 100. 전용 요청 300개가 모두 첫 시도에 성공했습니다.
테스트 설정
공급자 모델 ID를 선택해 AIHubMix를 거쳐 실행했습니다. 경로는 빠른 시작 가이드에 설명되어 있습니다. DeepSeek의 가격 페이지에는 모델의 공개 요금이 나와 있습니다.
| 항목 | 세부 정보 |
|---|---|
| 모델 | DeepSeek V4.1 Flash 1017 |
| 요청한 모델 ID | alicloud-deepseek-v4.1-flash-1017 |
| 반환된 모델 이름 | deepseek-v4.1-flash-1017 |
| 접속 경로 | 공급자 자체 계정에 연결하지 않고 공급자 모델 ID를 선택해 AIHubMix를 통해 접속 |
| 매개변수 | 비사고 모드, 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회); 함수 사례 60개 × 3개 윈도우; 속도 측정 동시성 1에서 90개, 동시성 10에서 90개; 안정성 300개; 캐시 30개(8k 및 32k 프리픽스, 각 3개 그룹) |
Q — 응답 품질: 41.75
응답 품질 측정에는 질문 세트 3개를 사용했습니다. BFCL 질문 500개는 각각 3회, HLE 질문 250개는 각각 10회, AA-LCR 질문 25개는 각각 10회 실행했습니다. BFCL은 자동 규칙으로 채점했고, HLE와 AA-LCR은 판정 모델 deepseek-flash로 평가했습니다. 5개 공급자에 모두 같은 질문을 사용했으며, 세 세트의 결과를 하나의 정확도로 합산했습니다. 채점할 수 없는 질문 10개에 대한 응답은 제외되어 채점된 질문 실행은 4,240개였습니다.
| 작업 | 질문 수 | 정답 | 정확도 | 실패 |
|---|---|---|---|---|
| BFCL 도구 호출 | 500 × 3 | 1,305/1,500 | 87.00% | 0 |
| HLE 고난도 QA | 250 × 10 | 331/2,490 | 13.29% | 8 |
| AA-LCR 장문서 추론 | 25 × 10 | 134/250 | 53.60% | 0 |
| 통합 · 95% 구간 39.56%–43.85% | — | 1,770/4,240 | 41.75% | 8 |
서비스 실패(요청 실패 또는 출력 잘림)는 분모에 포함하고 오답으로 계산하며, 제외하지 않습니다. Alibaba Cloud에서는 HLE 출력이 max_tokens 제한에 도달해 8회 잘렸습니다.
BFCL은 각 질문에 3회 답변하며, 표에는 3회 결과를 합산해 표시했습니다.
| BFCL 범주 | 통과 | 통과율 |
|---|---|---|
| simple_python: 함수 하나를 올바른 인수로 호출 | 332/360 | 92.22% |
| multiple: 여러 함수 중 올바른 함수 선택 | 270/300 | 90.00% |
| parallel: 같은 함수를 여러 번 병렬 호출 | 273/300 | 91.00% |
| parallel_multiple: 서로 다른 여러 함수를 병렬 호출 | 212/240 | 88.33% |
| irrelevance: 관련 함수가 없으므로 아무 함수도 호출하지 않음 | 113/150 | 75.33% |
| ahm_multi_turn: 3단계 도구 체인 | 105/150 | 70.00% |
나머지 4개와 비교
공식 채널과 비교한 정확도 차이를 %포인트로 표시했으며, 95% 구간은 수염으로 나타냈습니다. 구간이 0을 포함하면 차이가 없는 것으로 간주합니다. HLE와 AA-LCR의 판정 모델 deepseek-flash는 테스트 대상 모델과 같은 DeepSeek 계열이며 보정되지 않았으므로, 평가가 관대할 수 있습니다.
F — 함수 지원: 89.78
함수 사례는 모델의 답변 품질이 아니라 인터페이스 동작이 프로토콜을 따르는지 확인합니다. 사례 60개는 6개 그룹으로 나뉘며, 각 그룹을 3개 윈도우에서 실행해 총 180개 항목을 검사했습니다. 각 공급자가 문서화한 형식에 따라 평가했습니다. 해당 없음, 유효하지 않음 또는 관찰되지 않음으로 분류된 검사는 분모에서 제외합니다. Alibaba Cloud는 분모에 포함된 177개 검사 중 155개를 통과했으며, 그룹별 가중치를 적용한 점수는 89.78입니다.
가중 점수는 177개 항목의 단순 통과 수가 아니라 그룹별 가중치로 계산합니다.
| 그룹 | 가중치 | 통과 | 제외 | 그룹 점수 |
|---|---|---|---|---|
| 스트리밍 및 메시지 프로토콜 | 20% | 30/30 | — | 100.00 |
| 도구 인터페이스 | 20% | 30/30 | — | 100.00 |
| 출력 제약 조건 및 매개변수 | 20% | 30/30 | — | 100.00 |
| 컨텍스트 및 상태 | 15% | 26/30 | — | 86.67 |
| 오류 및 복구 | 15% | 18/30 | — | 60.00 |
| 과금 및 캐시 프로토콜 | 10% | 21/27 | 3 | 77.78 |
| 합계 · 가중 점수 | — | 155/177 | 3 | 89.78 |
윈도우 수가 3/3이면 해당 사례가 세 윈도우 모두에서 실패했다는 뜻입니다.
| 실패한 사례 | 실패한 윈도우 수 | 사유 |
|---|---|---|
| 컨텍스트 초과(컨텍스트 및 상태) | 3/3 | 오류를 반환했지만, 문서에 명시된 컨텍스트 길이 오류는 아니었습니다 |
| messages 형식 오류(오류 및 복구) | 3/3 | 400을 반환했지만 응답 본문은 비어 있었고, 구조화된 오류 설명도 없었습니다 |
| 잘못된 도구 스키마(오류 및 복구) | 3/3 | 매개변수 오류를 반환해야 했지만 503을 반환했습니다 |
| 단독 도구 결과(오류 및 복구) | 3/3 | 매개변수 오류를 반환해야 했지만 200을 반환했습니다 |
| stream_options 형식 오류(오류 및 복구) | 3/3 | 400을 반환했지만 응답 본문은 비어 있었고, 구조화된 오류 설명도 없었습니다 |
| 추론 토큰 과금(과금 및 캐시 프로토콜) | 3/3 | 추론 토큰 수를 반환하지 않음 |
| 도구 정의를 입력으로 집계(과금 및 캐시 프로토콜) | 3/3 | 도구 정의를 포함해도 보고된 입력 토큰 수가 포함하지 않았을 때보다 많지 않았습니다 |
| 요청 격리(컨텍스트 및 상태) | 1/3 | 첫 단계에서 요구된 대로 STORED만 응답하지 않아 격리 검사를 진행할 수 없었습니다 |
이 검사들은 분모에서 제외되며 통과나 실패 어느 쪽으로도 계산되지 않습니다.
| 상태 | 사례 | 수 | 사유 |
|---|---|---|---|
| 해당 없음 | 명시적 cache_control | 3 | 이 인터페이스에서 지원되지 않는 것으로 사전 등록됨 |
messages 형식 오류와 stream_options 형식 오류 사례는 5개 공급자 모두 실패했습니다. 모두 본문이 비어 있는 400을 반환해 클라이언트가 구조화된 오류 설명을 받지 못했습니다. 5개 공급자에서 동작이 모두 같으므로 AIHubMix 게이트웨이 계층에서 발생했을 가능성이 더 높으며 별도로 조사해야 합니다. 추론 토큰 과금도 5개 모두 실패했지만, 사유는 달랐습니다. ByteDance와 Fireworks는 사고 모드를 꺼도 추론 토큰을 보고했고, 나머지 3개 공급자는 추론 토큰 수를 반환하지 않았습니다.
나머지 4개와 비교
P — 응답 속도: 88.58
각 요청에는 입력 토큰 약 10,000개를 넣고 출력 토큰 약 1,100개를 요청했습니다. 세 개의 윈도우에서 동시성 1로 요청 30개, 동시성 10으로 요청 30개를 전송해 총 180개를 보냈습니다. 첫 콘텐츠 토큰 대기 시간(TTFA)은 유효한 각 요청에서 측정했으며, 표에는 중앙값을 표시했습니다. TPOT는 스트리밍 청크 타이밍으로 추정한 값이지 하드웨어의 토큰별 처리 시간이 아닙니다. 처리량은 동시성 10에서 유효한 출력 토큰 수를 전체 배치의 경과 시간으로 나누어 계산했습니다.
| 지표 | 결과 |
|---|---|
| 첫 콘텐츠 토큰 TTFA | 동시성 1 중앙값 1.34 s, 동시성 10 중앙값 1.35 s |
| 생성 속도 TPOT | 동시성 1에서 4.63 ms/토큰, 동시성 10에서 4.69 ms/토큰 |
| 실효 처리량(goodput) | 동시성 10에서 1,313.6 token/s |
| 유효한 요청 | 동시성 1에서 90/90, 동시성 10에서 90/90 |
| 구성 요소 점수 | TTFA 59.65, TPOT 100.00, 처리량 100.00. TTFA와 TPOT에는 두 동시성 수준 중 낮은 값을 적용하고, 가중치는 각각 35% / 35% / 30%로 반영해 응답 점수 85.88을 산출했습니다 |
| P 점수 | 응답 점수 85.88에 80%, 캐시 K 99.37에 20%를 반영해 총점 88.58 |
나머지 4개와 비교
5개 공급자가 모두 같은 머신, 네트워크 및 계정을 공유했습니다. 세 개의 윈도우는 공급자별로 순차 진행했으므로 데이터 수집 기간이 완전히 겹치지 않습니다. 작은 차이를 지나치게 해석하지 않도록 유의해야 합니다.
K — 캐시: 99.37
각 그룹은 요청 5개로 구성됩니다. 첫 요청에는 약 8k 또는 32k 토큰의 고정 프리픽스를 넣어 캐시를 채웁니다. 요청 2~4에서는 프리픽스를 유지하고 끝부분의 질문만 바꿔 각각 5초, 30초, 120초 후에 전송합니다. 다섯 번째 요청은 콜드 대조군으로 새 프리픽스를 사용합니다. 길이 2종과 윈도우 3개를 조합해 요청 30개를 실행합니다. K는 핫 요청에서 읽은 캐시 토큰 수를 규칙상 재사용 가능해야 하는 토큰 수로 나눈 값이며, 각 길이는 절반씩 가중됩니다. K는 P의 20%를 차지합니다. 행렬에는 서버가 보고한 캐시 토큰 읽기 수를 표시했습니다.
| 프리픽스 | 윈도우 | 시드(요청 1) | 5초 후 핫 요청 | 30초 후 핫 요청 | 120초 후 핫 요청 | 콜드 대조군(요청 5) |
|---|---|---|---|---|---|---|
| 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 | 32,000 | 0 |
| 32k | 윈도우 3 | 0 | 32,000 | 32,000 | 32,000 | 0 |
| 프리픽스 | 핫 적중 | 읽은 토큰 | 재사용 가능해야 하는 토큰 | 점수 |
|---|---|---|---|---|
| 8k | 9/9 | 71,424 | 72,270 | 98.83 |
| 32k | 9/9 | 288,000 | 288,279 | 99.90 |
| K(8k 및 32k, 각각 절반 가중) | 99.37 |
핫 8k 요청 9개가 모두 적중해 각각 7,936개 토큰을 읽었고, 핫 32k 요청 9개도 모두 적중해 각각 32,000개 토큰을 읽었습니다. 시드 요청과 콜드 대조군은 캐시를 읽지 않아 핫 요청과 콜드 요청이 명확히 구분됩니다.
나머지 4개와 비교
R — 서비스 안정성: 100
요청 300개는 짧은 텍스트, 입력 10k의 장문, 도구 호출, 멀티턴 기록의 네 가지 유형을 다뤘으며, 세 개의 윈도우에 걸쳐 동시성 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 공식 | 300/300 | 98.78%–100% |
| Fireworks | 300/300 | 98.78%–100% |
FAQ
Alibaba Cloud와 공식 채널 간의 종합 점수 차이 0.37은 의미가 있나요?
아니요. 이번 실행에서는 둘을 구분할 수 없습니다. Q 차이는 −0.71퍼센트포인트이고 95% 구간은 −1.72~+0.26으로 0을 포함합니다. 또한 종합 점수는 신뢰 구간이 없는 요약 지표입니다.
Q 점수에는 무엇이 반영되나요?
세 가지 평가 세트입니다. BFCL은 500개 질문을 3회씩 자동 채점하고, HLE는 250개 질문을 10회씩, AA-LCR은 25개 질문을 10회씩 judge 모델 deepseek-flash로 채점합니다. 총 4,240개의 채점된 질문 실행에서 통합 정확도는 41.75%입니다.
검사 177건 중 155건이 통과했는데 F가 89.78인 이유는 무엇인가요?
단순 통과율이 아니라 그룹별 가중치를 적용한 점수이기 때문입니다. 오류 및 복구 점수는 60.00, 계량 및 캐시 프로토콜 점수는 77.78이었으며, 나머지 세 프로토콜 그룹은 100.00을 기록했습니다.
다른 섹션에서 요청이 실패했는데 R은 왜 100인가요?
R은 전용 안정성 요청 300건에만 해당합니다. 응답 품질과 속도 문제로 인한 실패는 Q와 P에 기록하며, R에서 다시 집계하지 않습니다.
K 99.37은 캐시 적중률인가요?
핫 요청에서 읽은 캐시 토큰을 재사용 가능해야 하는 토큰으로 나눈 비율입니다. 8k와 32k에 각각 절반의 가중치를 적용했습니다. 8k 프리픽스 점수는 98.83, 32k 프리픽스 점수는 99.90입니다.
첫 토큰까지 1.34초라면 전체 답변도 1.34초 만에 도착한다는 뜻인가요?
아니요. 첫 번째 콘텐츠 토큰을 받을 때까지 기다리는 시간을 뜻합니다. 각 요청은 출력 토큰 약 1,100개를 요청했으며, 동시성 10에서 TPOT는 토큰당 4.69ms였습니다.
계속 읽기: DeepSeek V4.1 Flash 시리즈
- Alibaba Cloud의 통합 Q 점수는 공식 기준선과 0.71퍼센트포인트 차이로, 0을 포함하는 구간 안에 있습니다. ByteDance 프로필에서는 같은 비교를 도구 호출 계량까지 이어서 살펴봅니다. ByteDance의 DeepSeek V4.1 Flash: 도구 호출은 일치하지만 계량은 다릅니다.
- Alibaba Cloud는 속도 테스트 요청 180건을 모두 유효하게 반환했습니다. Baidu 프로필에서는 사용 가능한 채널이 Q와 P에 영향을 주지 않은 동일한 테스트 하네스를 살펴봅니다. Baidu의 DeepSeek V4.1 Flash: 사용 가능한 채널이 없어 Q와 P에 영향이 없습니다.
- 이 글에서는 응답 품질 비교의 기준선으로 공식 채널을 사용합니다. 공식 채널 자체의 프로필에는 F 94.00과 유효하지 않은 단일 동시성 프로브 15건이 포함됩니다. 공식 채널의 DeepSeek V4.1 Flash: F 94.00, 유효하지 않은 프로브 15건.
- Alibaba Cloud는 두 프리픽스 길이에서 핫 요청 9/9건을 적중했습니다. Fireworks 프로필에서는 빈 stop 응답과 8k에서의 캐시 적중 3/9건을 다룹니다. Fireworks의 DeepSeek V4.1 Flash: 빈 stop 응답, 캐시 적중 3/9건.
