Qwen3.8 벤치마크: 확인된 결과와 추가 검증 항목
이름 확인: Qwen3.8 Max Preview와 Qwen3-8B는 다른 모델입니다. 이전 8B 모델의 Score는 Qwen3.8 근거가 아닙니다.
이 페이지는 확인된 사실과 한계를 정리할 수 있지만 Qwen3.8이 Fable 5, GPT-5.6, Kimi K3, Qwen3.7 Max를 종합적으로 능가한다고 결론 내릴 수 없습니다.
현재 Qwen3.8 증거 수준
| 증거 수준 | 현재 상태 | 판단 가능한 것 | 판단 불가능한 것 |
|---|---|---|---|
| 공식 상태와 기능 | 있음 | Preview ID, 채널, 추론·시각·텍스트 분류 | 종합 품질 순위 |
| Qwen 출시 포지셔닝 | 있음 | Test 가설과 비교 모델 | 독립적인 승자 주장 |
| 제3자 Workload Test | 제한적 | 특정 Task와 Route에서 관찰한 차이 | 일반 능력과 안정 평균 |
| 광범위한 독립 Benchmark | 불충분 | 향후 Cross-model 비교 | 현재의 결정적 Leaderboard |
문서화된 기능은 Performance Score가 아니며 Vendor 순위는 독립 증거가 아닙니다. 이를 하나의 “확인된 Benchmark” 표로 섞지 마세요.
Qwen이 공식 주장한 내용
Qwen은 총 2.4조 파라미터, 지속적 개선, Open Weights 계획 및 Frontier에 가까운 내부 평가를 발표했습니다. 이는 다음 Test 가설을 만듭니다.
| 발표 | 유용한 가설 | 위험한 결론 |
|---|---|---|
| 총 2.4조 파라미터 | 어려운 Task에서 Scale 효과 검증 | 크면 항상 더 좋다 |
| Frontier 근접 내부 평가 | Fable, GPT, Kimi, Qwen3.7 Baseline 포함 | 독립 평가 세계 2위 |
| 코딩·복잡 업무 중심 | Repo Task와 긴 Tool Loop 검증 | 최고의 Coding Model |
| Open Weights 계획 | Serving과 재현성 질문 준비 | 공개 Weight가 Hosted Preview와 동일 |
활성 파라미터와 Architecture가 없으면 총 파라미터만으로 추론 비용, Latency, Memory 또는 Token당 계산량을 설명할 수 없습니다.
초기 제3자 테스트가 알려 주는 것
Trilogy AI의 초기 Repository Architecture Test는 269개 파일에서 Qwen3.8 Max Preview와 Kimi K3를 비교했습니다. Blind Review 점수는 Kimi 83, Qwen 80이었습니다. Qwen은 일부 System Boundary와 Replay Metadata 결정에서 강했고, Kimi는 더 빠르고 적은 Token으로 완료하며 Lifecycle State를 더 폭넓게 다뤘습니다.
Task 구조, 오류, Token 및 질적 차이를 보고했다는 점에서 유용하지만, 하나의 Task, 모델당 한 Session, 특정 Serving Route에 한정돼 일반 Benchmark는 아닙니다.
방법론상 중요한 교훈은 다음과 같습니다.
- 고정된 입력으로 비교합니다.
- 산출물 구조뿐 아니라 Claim의 정확성도 평가합니다.
- Model Behavior와 Route Behavior를 분리합니다.
- 품질과 함께 Latency와 Token을 공개합니다.
- 가능하면 Reviewer를 Blind 처리합니다.
- 총점뿐 아니라 Failure Analysis를 남깁니다.
Qwen 실행은 대화형 Coding Harness의 Token Plan Endpoint를 사용했습니다. 개인 Plan은 Custom Backend, 자동 Script, 비대화형 Batch를 금지합니다. 따라서 83 대 80은 특정 날짜의 End-to-End 평가 경로 비교이지 교환 가능한 두 프로덕션 API 비교가 아닙니다.
아직 부족한 Qwen3.8 증거
완전한 공식 Benchmark 공개
Model Version, Reasoning 설정, Tool Access, Prompt Policy, Trial 수, 채점 방법, 경쟁 모델 설정이 필요합니다. Harness가 없는 Score는 재현하기 어렵습니다.
독립 Coding 및 Agent 재현
함수 생성만이 아니라 Repository 탐색, 다중 파일 변경, Test, Tool Call, 실패 복구 및 Review를 포함해야 합니다.
멀티모달 Task 증거
OCR, Visual Grounding, 문서 이해, Chart Reasoning, Sampling한 Video Frame, Hallucination을 분리해야 합니다. Native Video Input은 아직 가정하지 않습니다.
Latency와 Token 효율
점수가 높아도 긴 추론, 큰 출력, 불안정한 Latency로 제품 경험과 비용이 악화될 수 있습니다.
Route 안정성과 이용 권한
정확한 ID, 날짜, 채널, 지역, Client, 설정을 기록합니다. Interactive Evaluation, 자동 Regression, Application Backend, Batch 사용 권한도 별도 확인합니다.
재현 가능한 이용 권한
대화형 구독에서 가능한 작업과 앱 Backend 또는 자동 회귀 Test에서 허용되는 작업을 구분해 기록합니다. Route 이용 조건은 품질 Score와 별도의 Gate입니다.
공개 Benchmark가 프로덕션 팀을 오도하는 이유
| Blind Spot | 숨겨지는 장애 | 더 나은 측정 |
|---|---|---|
| One-shot 품질 | 계획은 맞지만 구현이 깨짐 | End-to-End 합격 Task |
| 이상적 Prompt | 실제 사용자 입력에서 취약 | Prompt Variation 합격률 |
| Tool 실패 없음 | 나쁜 Call 후 Agent Loop | 실패 주입 복구 |
| 단일 Run | 높은 분산 | 다회 Trial과 신뢰 범위 |
| Token 가격만 | 싸지만 Retry가 많음 | 성공 작업 비용 |
| 최대 Context | 긴 입력에서 근거를 못 찾음 | 위치 통제 Evidence Recall |
| 최종 답변 Score | 매끄러운 글에 Unsupported Claim 은폐 | Claim 단위 Evidence Audit |
향후 EvoLink Qwen3.8 Benchmark Gate
이 Protocol은 프로덕션 적격 API Route가 공개된 뒤에만 실행합니다. 공개된 Test 결과도 아니며 지금 대규모 Token Plan 시험에 지출할 이유도 아닙니다.
1. Task Set 고정
API 공개 후 소규모 Pilot으로 시작하고 결과와 Route 조건이 타당할 때만 확대합니다. Qwen3.7 Max, Kimi K3, Claude, GPT 등 현재 Route를 Baseline으로 둡니다.
| Category | 최소 Test | 합격 Signal |
|---|---|---|
| Repository Coding | Bug Fix와 Cross-module Feature | Test 통과, 무관한 변경 없음 |
| Coding Agent | 여러 Tool을 쓰는 긴 Task | 올바른 Call, 미해결 Loop 없음 |
| Reasoning | 다단계 기술 결정 | 정답과 추적 가능한 가정 |
| Long Context | Repo 또는 문서 검색 | 정확한 근거와 인용 |
| Vision | Screenshot, Chart, Document | Grounded Extraction, 낮은 조작률 |
| Data Work | 표 분석 및 Report | 수치 정확성과 사용 가능한 산출물 |
| Routine Workload | 작고 일반적인 Task | Frontier Route가 측정 가능한 가치를 추가 |
2. 환경 고정
Model ID, 날짜, Provider Route, 지역, System/User Prompt, Reasoning, Tool 권한, Timeout, Retry, Fallback, Input/Output Token, Cache Hit를 기록합니다.
3. Style보다 Acceptance 우선
Test, Schema, 인용, 숫자 및 필수 산출물을 먼저 판정하고 유지보수성, 명확성, 선호도를 다음에 평가합니다.
production_score = acceptance_rate
- severe_defect_rate
- intervention_penalty
- timeout_penalty4. 성공 작업 경제성 계산
accepted_task_cost = model_calls + retries + fallback_calls + reviewer_time + repairQwen3.8 표준 Token 가격은 아직 없습니다. Credits는 Preview 실험 소비로 기록할 수 있지만 일반 API 가격으로 비교하면 안 됩니다.
5. 보편 순위가 아니라 Route 역할 결정
| 역할 | 필요한 증거 |
|---|---|
| Default Route | 일반 Traffic에서 안정된 품질, Latency, 비용 |
| Coding Specialist | Repo와 Tool Task의 명확한 우위 |
| Long-context Specialist | 실제 길이에서 더 높은 Recall과 일관성 |
| Quality Escalation | 어렵고 실패 비용이 큰 Task의 높은 합격률 |
| Evaluation Only | 강한 능력이나 ID, 비용, 동작이 불안정 |
Evaluation Only가 올바른 현재 역할입니다.새로운 Score를 읽는 8가지 질문
- 발표자는 Vendor, 비교 대상 또는 독립 평가자 중 누구인가?
- 정확한 Qwen3.8 Build와 Route는 무엇인가?
- Reasoning을 켰고 Effort는 무엇인가?
- Tool, Browsing, Code Execution을 쓸 수 있었나?
- Trial은 몇 번인가?
- Prompt와 채점이 재현 가능한가?
- 우리 제품의 실제 Task를 측정하는가?
- Latency, Token, Retry, Failure를 포함하는가?
이 정보가 없으면 방향성 증거로 표시하고 Winner 표에 넣지 않습니다.
EvoLink 사용자 권장 사항
자주 묻는 질문
Qwen3.8 벤치마크 점수는 무엇인가요?
신뢰할 수 있는 단일 종합 점수는 없습니다. Vendor 포지셔닝은 있으나 완전한 표와 광범위한 독립 재현이 부족합니다.
Fable 5 다음으로 2위인가요?
Qwen의 Vendor 포지셔닝이며 독립 검증된 보편 순위가 아닙니다.
독립 테스트가 있나요?
269개 파일 Repository 비교 같은 초기 테스트가 있지만 종합 순위를 정하기에는 범위가 좁습니다.
코딩에 좋은가요?
주요 출시 Use Case이지만 프로덕션에서는 Repo 변경, Tool, Recovery, Test, Review까지 검증해야 합니다.
Kimi K3와 어떻게 비교하나요?
입력, 권한, 평가 기준, Budget을 고정하고 여러 번 실행하여 품질, Latency, Token, 개입 및 비용을 따로 측정합니다.
Token Plan Credits를 비용 비교에 쓸 수 있나요?
Preview 실험 소비를 표현할 수는 있지만 표준 API Token 가격으로 변환해 다른 Provider와 직접 비교하면 안 됩니다.
어떤 Baseline을 포함해야 하나요?
실제로 교체할 수 있는 Qwen3.7 Max와 Kimi K3에 더해 품질 상한을 볼 Fable 5나 GPT-5.6 등을 포함하세요. 사용할 수 없는 모델을 장식용 비교 대상으로 삼지 마세요.
언제 프로덕션 준비가 되나요?
안정 Route, ID, 가격, 제한, 이용 조건이 공개되고 실제 Workload에서 품질, 신뢰성, Latency, 비용 Gate를 통과했을 때입니다.
