Phi-4-reasoning-vision-15B
MIT 라이선스 / 오픈웨이트
Phi-4 Reasoning Vision, 5가지 수치로 공식 문서에서 직접 확인했습니다
마이크로소프트가 2026년 3월 4일 공개한 Phi-4-reasoning-vision-15B는 15B 파라미터 모델입니다. 경쟁 모델 대비 훈련 데이터가 5분의 1에 불과한데도 ChartQA에서 83.3점을 기록했습니다. “작으면 부족하다”는 통념이 어느 지점에서 무너지는지, 동시에 어느 지점에서 여전히 유효한지 공식 Technical Report와 HuggingFace 모델 카드를 직접 보면서 정리했습니다.
훈련 데이터 200B vs 1T — 숫자가 말해주는 것
Phi-4-reasoning-vision-15B의 훈련 토큰은 약 200억(200B) 토큰입니다. 경쟁 모델인 Qwen 2.5 VL, Qwen 3 VL, Kimi-VL, Gemma3는 각각 훈련에 1조(1T) 토큰 이상을 사용했습니다. (출처: Microsoft Research 공식 블로그, 2026.03.04) 단순 비교로는 5분의 1 수준입니다. 그런데도 ChartQA에서 83.3점을 기록했고, Kimi-VL-A3B(87점)보다는 낮지만 Gemma3-12B(39점)를 크게 웃돌았습니다. 데이터 양의 절대적 차이가 성능의 절대적 차이로 이어지지 않은 이유는 데이터 처리 방식에 있습니다.
마이크로소프트 연구팀은 오픈소스 데이터셋을 그대로 쓰지 않았습니다. 각 데이터셋을 직접 샘플링하며 5~10분 단위로 품질을 분류했고, 오답이 포함된 데이터는 GPT-4o와 o4-mini를 동원해 재생성했습니다. 공식 Technical Report는 “널리 쓰이는 오픈소스 데이터셋 상당수에서 놀라울 정도로 많은 포맷 오류와 논리적 오류를 발견했다”고 직접 밝히고 있습니다. (출처: arXiv:2603.03975, 2026.03.04) 결국 총량이 아니라 정제 품질이 성능을 결정한 셈입니다.
💡 공식 발표문과 경쟁 모델 훈련 데이터를 나란히 놓고 보니 이런 차이가 보였습니다.
훈련에 240대의 NVIDIA B200 GPU를 4일간 사용했는데, 이는 Qwen이나 Gemma3 수준의 1조 토큰 훈련 대비 컴퓨트 비용이 수십 배 낮은 수준입니다. MIT 라이선스로 공개된 만큼 별도 비용 없이 로컬에서도 실행 가능하며, Azure AI Foundry와 HuggingFace에서 즉시 사용할 수 있습니다.
생각을 켜고 끄는 모델 — 혼합 추론 구조의 실체
Phi-4-reasoning-vision-15B는 하나의 모델이지만 두 가지 응답 모드를 가집니다. <think> 토큰이 붙으면 수학·과학처럼 단계적 추론이 필요한 문제를 길게 생각하고, <nothink> 토큰이 붙으면 이미지 캡셔닝이나 OCR처럼 직관적 인식 작업에서 곧장 답을 냅니다. 훈련 데이터의 약 20%가 추론 트레이스가 포함된 thinking 데이터이고, 나머지 80%는 non-thinking 데이터입니다. (출처: HuggingFace 모델 카드, 2026.03.04)
마이크로소프트가 선택한 방식은 네 가지 훈련 파이프라인 중 하나입니다. 가장 단순한 방식은 비추론 LLM에서 출발해 멀티모달 추론을 한번에 가르치는 것인데, 이 경우 추론 트레이스 데이터를 대량으로 확보해야 합니다. 두 번째 방식은 멀티모달을 먼저 가르치고 나중에 추론을 얹는 것인데, 이때는 앞서 배운 시각 능력이 손상될 위험이 있습니다. 세 번째는 추론 LLM에서 출발하되 모든 학습 데이터에 추론 트레이스를 붙이는 방식인데, 이미지 캡셔닝 같은 단순 작업에도 불필요한 계산이 붙어서 효율이 떨어집니다. Phi-4-reasoning-vision이 선택한 네 번째 방식은 이미 추론 능력을 갖춘 LLM에서 출발해 혼합 데이터로 훈련하는 것입니다.
| 훈련 파이프라인 | 주요 단점 |
|---|---|
| 비추론 LLM → 멀티모달 추론 한번에 | 추론 트레이스 데이터 대량 필요 |
| 비추론 LLM → 멀티모달 먼저 → 추론 추가 | 이전 시각 능력 손상 위험 |
| 추론 LLM → 전 데이터에 추론 트레이스 부착 | 단순 작업에도 불필요한 지연 발생 |
| ✅ 추론 LLM → 혼합(80% nothink / 20% think) | 모드 전환 경계가 암묵적으로 학습됨 (제어 한계) |
추론을 강제하면 오히려 점수가 낮아지는 벤치마크가 있습니다
“AI가 더 오래 생각할수록 더 정확해진다”는 통념이 있습니다. 막상 공식 벤치마크 결과를 보면 꼭 그렇지 않습니다. Phi-4-reasoning-vision-15B에서 thinking을 강제(force thinking)했을 때 AI2D 점수는 84.8에서 79.7로 하락했습니다. ChartQA도 83.3에서 82.9로 미세하게 내려갑니다. (출처: HuggingFace 모델 카드 Table 2, 2026.03.04) 추론 트레이스가 오히려 노이즈를 만들어 지각 중심 작업의 정확도를 낮추는 현상입니다.
반대로 thinking을 강제 해제(force nothink)했을 때는 MathVista에서 75.2에서 68.7로 6.5점 하락합니다. 수학 문제처럼 단계 추론이 필요한 작업에서는 thinking이 확실히 점수를 올립니다. 결론적으로 작업 유형을 가리지 않고 “무조건 많이 생각”하거나 “무조건 빠르게 답”하는 전략은 최적이 아닙니다. 이 모델의 기본 설정이 혼합 모드인 이유입니다.
📊 모드별 점수 비교 (출처: Microsoft Research 공식 벤치마크, 2026.03.04)
| 벤치마크 | 기본(혼합) | 강제 Think | 강제 Nothink |
|---|---|---|---|
| AI2D_TEST | 84.8 | 79.7 ↓ | 84.7 |
| ChartQA_TEST | 83.3 | 82.9 | 76.5 ↓ |
| MathVista_MINI | 75.2 | 74.1 | 68.7 ↓ |
| MathVerse_MINI | 44.9 | 53.1 ↑ | 43.8 ↓ |
↑ 강제 thinking이 유효한 경우 / ↓ 강제 시 성능 하락
수학 데이터를 늘렸더니 화면 조작 성능도 올랐습니다
공식 Technical Report Table 4가 보여주는 수치 하나가 흥미롭습니다. 수학·과학 데이터를 150K에서 450K로 3배 늘린 실험에서, 수학 벤치마크(MathVista)가 오른 건 예상할 수 있었습니다. 그런데 컴퓨터 조작(GUI 조작) 벤치마크인 ScreenSpot-V2도 함께 올랐습니다. 수학 150K + CUA 850K 조합 대비 수학 450K + CUA 850K 조합에서 MMMU가 43.4에서 올라가고 MathVista는 38.9로 최고점을 기록했습니다. (출처: arXiv:2603.03975 Table 4, 2026.03.04)
연구팀은 이 결과를 “단일 모델이 두 도메인에서 동시에 뛰어날 수 있음을 보여준다”고 해석했습니다. 수학적 추론 훈련이 화면 요소를 정확하게 인식하고 조작하는 능력에도 긍정적인 영향을 준 것으로 봅니다. 두 능력이 완전히 분리된 것이 아니라 공통된 추론 기반을 공유한다는 의미입니다. 기존에는 “특화 모델 여러 개를 따로 훈련해야 한다”는 것이 업계 통념이었는데, 이 실험 결과는 그 전제를 흔듭니다.
💡 수학 데이터와 컴퓨터 조작 데이터의 관계를 교차해서 보니 예상 밖의 패턴이 나타났습니다.
이 발견은 실용적으로도 중요합니다. 수학 추론 능력이 강한 모델이 GUI 에이전트 작업에서도 유리할 수 있다는 뜻이기 때문입니다. 화면 속 버튼 위치를 정확히 짚고 다음 클릭을 계획하는 일 자체가 일종의 공간적·순서적 추론이기 때문에, 이 연결고리는 직관적으로도 납득이 됩니다.
OCR과 다국어 — 공식 문서가 직접 인정한 한계
OCRBench 점수는 76점입니다. Qwen3-VL-8B는 같은 벤치마크에서 89~90점을 기록했습니다. 14점 가까운 차이가 납니다. (출처: HuggingFace 모델 카드 Table 1, 2026.03.04) OCR은 이미지 안의 문자를 정확하게 읽어내는 작업으로, 한국어·일본어·중국어 등 영어 외 언어가 포함된 이미지에서 더 두드러지는 약점입니다.
HuggingFace 모델 카드에는 이런 문장이 있습니다. “Phi-4-Reasoning-Vision-15B is not intended to support multilingual use.” 다국어 지원을 공식적으로 배제하겠다는 선언입니다. 영어 외 언어를 포함한 문서나 이미지를 주로 다룬다면 이 점은 실사용에서 상당한 제약이 됩니다. 한국어 영수증 OCR, 한글 UI 화면 이해 같은 작업에서는 Qwen3-VL 계열이 현실적으로 더 나은 선택일 수 있습니다.
⚠️ 한국어 OCR·한글 UI 분석 용도라면 OCRBench 점수 차이(76 vs 89~90)를 반드시 고려하세요.
공식 모델 카드에 다국어 미지원이 명시돼 있으며, 이유는 별도로 밝히지 않았습니다. 영어 환경의 수학·과학 문제 풀이나 영문 GUI 조작에 특화된 용도라면 이 모델이 여전히 효율적인 선택입니다.
Qwen3-VL, Gemma3와의 실제 수치 비교
마이크로소프트 연구팀은 자체 측정 수치를 공개했고, 리더보드 수치를 그대로 인용하지 않았습니다. temperature=0.0, greedy decoding, 최대 출력 4,096 토큰 조건으로 직접 평가했습니다. 아래 수치는 이 조건에서 나온 것입니다.
| 벤치마크 | Phi-4 15B | Qwen3-VL 8B | Qwen3-VL 32B | Gemma3 12B |
|---|---|---|---|---|
| ChartQA | 83.3 | 83.1 | 84.3 | 39.0 |
| MathVista | 75.2 | 77.1 | 82.5 | 57.4 |
| ScreenSpot-v2 | 88.2 | 91.5 | 93.7 | 3.5 |
| OCRBench | 76.0 | 89.2 | 88.5 | 75.3 |
| MMMU | 54.3 | 60.7~64.6 | 68.6~70.6 | 50.0 |
(출처: Microsoft Research 공식 벤치마크, HuggingFace 모델 카드, 2026.03.04 기준 / 모든 수치는 Microsoft 자체 측정값)
Gemma3-12B가 ScreenSpot-v2에서 3.5점을 기록한 건 눈에 띕니다. 같은 파라미터 규모라도 GUI 조작 특화 훈련 없이는 UI 이해 능력이 거의 없다는 뜻입니다. Phi-4가 이 영역에서 88.2점을 기록한 것은 Phi-Ground 같은 GUI 특화 데이터를 적극 활용한 결과입니다.
이 모델이 실제로 맞는 상황과 맞지 않는 상황
공식 문서를 바탕으로 솔직하게 정리합니다. Phi-4-reasoning-vision-15B는 영문 수학·과학 문제 풀이, 영문 UI 화면 분석, 차트·그래프 해석, 수식이 포함된 문서 분석에서 파라미터 대비 뛰어난 성능을 냅니다. GPU 메모리가 제한적인 환경에서 로컬로 실행하거나, 추론 속도가 중요한 실시간 애플리케이션에서도 이 모델의 효율이 빛납니다. MIT 라이선스이므로 상업적 용도로 활용하는 데도 제약이 없습니다.
반면 한국어·일본어·중국어 등 비영어권 언어가 포함된 이미지나 문서, 한글 UI 화면을 다루는 상황이라면 OCRBench 기준 76점이라는 수치가 현실적인 한계로 작동합니다. MMMU에서도 54.3점으로 Qwen3-VL-8B의 60.7점에 미치지 못합니다. 종합적인 멀티모달 이해력이 핵심인 작업에서는 파라미터가 더 큰 모델을 선택하는 편이 현실적입니다. 또한 모델이 언제 thinking을 할지를 데이터 분포로 암묵적으로 학습했기 때문에, 경계 케이스에서 어떤 모드로 동작할지 정확히 예측하기 어렵습니다. 공식 문서는 이 부분을 “열린 문제(open problem)”라고 직접 표현합니다.
✅ 잘 맞는 상황
- 영어 기반 수학·과학 시각 문제 풀이 (MathVista 75.2)
- 영문 GUI 화면 요소 인식 및 에이전트 구동 (ScreenSpot-v2 88.2)
- 차트·다이어그램 해석 (ChartQA 83.3)
- 저지연·저자원 환경의 온디바이스 배포
- 상업적 오픈소스 활용 (MIT 라이선스)
⚠️ 신중해야 할 상황
- 한국어·일본어·중국어 이미지 OCR (다국어 미지원 공식 명시)
- 범용 멀티모달 이해가 핵심인 작업 (MMMU 54.3 — Qwen 8B 60.7 대비 낮음)
- 고난도 수학 추론 최고 성능이 필요한 경우 (MathVerse에서 Qwen3-VL-32B 대비 약 25점 차이)
자주 묻는 것들
마치며 — 크기보다 설계가 먼저입니다
Phi-4-reasoning-vision-15B는 “더 크게, 더 많이”라는 흐름과 반대 방향에서 나온 모델입니다. 240대 B200 GPU를 4일 사용해 훈련을 마쳤고, 경쟁사가 1조 토큰 이상 쓸 때 이 모델은 200B 토큰으로 비슷한 수준을 달성했습니다. 데이터 정제와 훈련 설계가 데이터 양을 어느 정도까지 대체할 수 있다는 걸 수치로 보여준 사례입니다.
다만 OCR 76점, MMMU 54.3점, 다국어 미지원이라는 한계는 실사용에서 분명히 걸리는 지점입니다. 수학·과학 추론이나 영문 GUI 에이전트 용도라면 이 모델의 효율 대비 성능은 매력적입니다. 한국어 환경이나 범용 멀티모달이 핵심이라면 다른 선택지를 먼저 검토해봐야 합니다. 어떤 모델이든 결국은 내가 풀어야 할 문제와의 궁합이 가장 중요합니다.
본 포스팅 참고 자료
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 본문의 모든 벤치마크 수치는 2026년 3월 4일 기준 Microsoft가 직접 측정·공개한 값이며, 이후 업데이트된 평가 결과와 다를 수 있습니다. 공식 최신 정보는 Microsoft Research 블로그 및 HuggingFace 모델 카드에서 확인하세요.
댓글 남기기