MIT 라이선스 오픈 웨이트
15B 파라미터
Phi-4 reasoning vision, 공식 수치 5가지로 직접 확인했습니다
마이크로소프트가 2026년 3월 4일 공개한 Phi-4-reasoning-vision-15B는 “작은 모델도 충분히 강하다”는 주장을 다시 꺼내 들었습니다. 학습에 쓴 데이터는 Qwen3-VL이나 Gemma3의 5분의 1 수준. 그런데 벤치마크 숫자를 보면 얘기가 달라집니다. 공식 발표문과 기술 보고서를 직접 읽고 수치를 추렸습니다.
Phi-4 reasoning vision이 뭔가요? 30초 요약
Phi-4-reasoning-vision-15B는 마이크로소프트가 2026년 3월 4일 공식 공개한 멀티모달 추론 모델입니다. 이미지와 텍스트를 동시에 처리하고, 수학·과학 문제처럼 단계별 사고가 필요한 작업과 OCR·캡션처럼 빠른 응답이 필요한 작업을 한 모델 안에서 자동으로 구분해 처리합니다. (출처: Microsoft Research 공식 블로그, 2026.03.04)
파라미터 수는 15B. GPT-4 클래스나 Qwen3-VL-32B처럼 수백억 파라미터 모델과 비교하면 훨씬 작습니다. 그런데 이 모델이 화제가 된 건 단순히 작아서가 아닙니다. 작은데 속도 대비 정확도 곡선(Pareto frontier)에서 경쟁자들 사이를 뚫고 들어갔다는 점 때문입니다.
라이선스는 MIT. 모델 가중치, 파인튜닝 코드, 벤치마크 로그를 모두 공개했습니다. Microsoft Foundry, HuggingFace, GitHub 세 곳에서 바로 받을 수 있습니다. (출처: HuggingFace Model Card — microsoft/Phi-4-reasoning-vision-15B)
💡 공식 발표문과 기술 보고서를 나란히 읽어보니, 이 모델의 핵심은 파라미터 수보다 언제 생각하고 언제 바로 답할지를 스스로 결정하는 설계 방식에 있었습니다.
학습 데이터 200B 토큰 — 숫자가 의미하는 것
멀티모달 AI를 학습시키려면 어마어마한 데이터가 필요하다는 게 그간의 상식이었습니다. Qwen3-VL, Kimi-VL, Gemma3는 모두 1조 토큰(1T tokens) 이상을 학습에 썼습니다. (출처: Phi-4-reasoning-vision-15B Technical Report, arXiv:2603.03975, 2026.03.04)
Phi-4-reasoning-vision-15B가 쓴 멀티모달 학습 데이터는 200B 토큰. 경쟁사 대비 5분의 1 수준입니다. 그렇다고 기반 모델 자체가 빈약한 게 아닙니다. Phi-4-Reasoning(16B 토큰 학습)과 Phi-4 원본 모델(고유 토큰 400B) 위에 쌓아 올린 구조라, 실제로는 누적 데이터가 훨씬 많습니다. 단순 비교는 오해를 낳습니다.
| 모델 | 파라미터 | 멀티모달 학습 토큰 | 훈련 컴퓨팅 |
|---|---|---|---|
| Phi-4-r-v-15B | 15B | 약 200B | B200 × 240 × 4일 |
| Qwen3-VL-32B | 32B | 1T+ | 미공개 |
| Kimi-VL-A3B | 3B (MoE) | 1T+ | 미공개 |
| Gemma3-12B | 12B | 1T+ | 미공개 |
※ 수치는 공식 기술 보고서 기준. Qwen3/Kimi/Gemma3 훈련 세부 컴퓨팅은 각 사 보고서에서 공개하지 않았습니다.
비결은 데이터 규모가 아닌 품질 관리였습니다. 연구팀은 오픈소스 데이터를 그대로 쓰지 않고, 팀원이 데이터셋별로 5~10분씩 직접 검토해 품질을 4단계로 분류했습니다. 오답이 섞인 데이터는 GPT-4o와 o4-mini로 재생성했고, 이미지는 쓸 만하지만 질문이 형편없으면 이미지를 씨앗 삼아 새로운 캡션·VQA 데이터를 만들었습니다. 이 과정에서 “널리 쓰이는 오픈소스 데이터셋에서 놀랄 만큼 많은 포맷·논리 오류를 발견했다”고 보고서에 직접 적혀 있습니다. (출처: Technical Report 3.1절)
‘생각’을 켜면 오히려 점수가 떨어지는 경우가 있습니다
2026년 AI 트렌드에서 “생각하는 모델(thinking model)”은 거의 모든 곳에서 더 낫다는 인식이 굳어졌습니다. 그런데 Phi-4-reasoning-vision-15B의 공식 벤치마크 수치는 그걸 정면으로 반박합니다.
📊 thinking 강제 vs. 기본값 — ChartQA_TEST 수치
- 기본값(혼합 모드): 83.3점
- thinking 강제(force thinking): 82.9점 — 오히려 하락
- nothink 강제(직접 응답): 76.5점
(출처: HuggingFace Model Card, Phi-4-reasoning-vision-15B, Table 2 — Microsoft, 2026.03.04)
차트 이해 같은 작업에서는 thinking을 강제하면 오히려 불필요한 토큰이 늘어나고 정확도가 미세하게 떨어집니다. 반면 수학 문제인 MathVerse_MINI에서는 기본값 44.9점 → thinking 강제 시 53.1점으로 올라갑니다. 작업 유형에 따라 생각이 도움이 되기도 하고 방해가 되기도 한다는 뜻입니다.
모델은 이 판단을 자동으로 합니다. 학습 데이터 중 추론 샘플이 약 20%, 직접 응답 샘플이 80%로 구성됐고, 모델은 시스템 프롬프트 지침에 따라 복잡도와 모호성을 기준으로 모드를 자동 선택합니다. (출처: Microsoft Research Blog, 2026.03.04) 원한다면 <think> 또는 <nothink> 토큰으로 수동 오버라이드도 가능합니다.
💡 “더 많이 생각할수록 더 정확하다”는 전제가 멀티모달 환경에서는 그대로 성립하지 않습니다. 마이크로소프트 팀도 이 경계를 “아직 열린 문제”라고 명시했습니다. (출처: Technical Report 4절)
수학 데이터 늘렸더니 UI 성능이 올라간 이유
💡 공식 발표문의 ablation 실험 표를 보면서 수학 데이터와 UI 데이터의 관계를 따로 정리해 봤는데, 두 영역이 서로 독립적이지 않다는 사실이 수치로 드러났습니다.
마이크로소프트 연구팀은 5B 규모 프록시 모델로 수학·과학 데이터와 컴퓨터 UI 데이터 비율을 바꿔가며 실험했습니다. 그 결과가 꽤 뜻밖이었습니다.
| 일반 | 수학·과학 | UI(CUA) | MMMU | MathVista | ScreenSpot-V2 |
|---|---|---|---|---|---|
| 1M | 150K | 450K | 44.0 | 37.4 | 48.2 |
| 1M | 450K (3×) | 450K | 45.3 | 36.0 | 48.3 |
| 1M | 450K (3×) | 850K | 43.4 | 38.9 | 63.1 |
수학 데이터를 150K에서 450K(3배)로 늘렸을 때 UI 성능(ScreenSpot-V2)이 48.2 → 48.3으로 거의 그대로입니다. 그런데 수학 3배에 UI 데이터도 850K로 함께 늘리자 ScreenSpot-V2가 48.2 → 63.1로 급등합니다. 수학 훈련으로 생긴 구조화 추론 능력이 UI 요소 파악에도 전이된다는 게 연구팀의 해석입니다. 도메인 간 경계가 우리 생각보다 낮습니다.
수학을 많이 가르치면 수학만 잘하게 된다는 통념과 다릅니다. 단계별로 생각하는 힘 자체가 다른 시각적 과제에도 쓰이는 겁니다.
경쟁 모델과 직접 비교한 벤치마크 수치
마이크로소프트는 리더보드 숫자를 인용하지 않고 직접 동일 조건에서 평가를 실행했습니다. temperature=0.0, greedy decoding, 최대 출력 토큰 4,096 기준입니다. (출처: HuggingFace Model Card 3절, 2026.03.04)
비추론 모드 모델들과 비교
| 벤치마크 | Phi-4-r-v-15B | Gemma3-12B | Qwen3-VL-8B | Qwen3-VL-32B |
|---|---|---|---|---|
| AI2D_TEST | 84.8 | 80.4 | 82.7~83.0 | 84.8~85.0 |
| ChartQA_TEST | 83.3 | 39.0 | 83.1~83.2 | 84.0~84.3 |
| MathVista_MINI | 75.2 | 57.4 | 76.4~77.1 | 81.8~82.5 |
| ScreenSpot_v2 | 88.2 | 3.5 | 91.5 | 93.7~93.9 |
| MMMU_VAL | 54.3 | 50.0 | 60.7~64.6 | 68.6~70.6 |
※ 표 안 수치는 공식 기술 보고서 기준. Qwen3-VL은 4K/32K 맥락 길이 조건 범위로 표기. (출처: HuggingFace Model Card, Table 1, 2026.03.04)
Gemma3-12B의 ScreenSpot_v2 점수 3.5는 단순 오타가 아닙니다. UI 요소 인식에 완전히 취약하다는 뜻입니다. 같은 12B 파라미터 근처 모델인데 88.2 vs 3.5로 25배 차이가 납니다. 컴퓨터 UI 자동화 에이전트를 만들 때 모델 선택이 얼마나 중요한지 직접 보여주는 수치입니다.
한계도 분명합니다. MMMU_VAL(다분야 멀티모달 이해)에서 Qwen3-VL-32B(68.6~70.6) 대비 Phi-4는 54.3으로 차이가 있습니다. 파라미터 두 배 이상 차이가 결국 복잡한 멀티 도메인 이해력에서 드러납니다.
알고 쓰면 좋은 한계와 주의사항
공식 Model Card와 기술 보고서에 명시된 제한 사항들입니다. 이 부분은 다른 리뷰 글에서 다루지 않는 경우가 많아서 따로 정리했습니다.
① 영어 중심 모델입니다
학습 데이터가 영어 텍스트 위주입니다. 공식 Model Card는 “다국어 사용을 지원하도록 설계되지 않았으며, 영어 외 언어에서 성능이 저하될 수 있다”고 직접 명시합니다. 한국어 문서나 UI에 적용할 때는 성능 차이가 있을 수 있습니다. (출처: HuggingFace Model Card 2.6절)
② 의료·법률·금융 판단에는 쓰지 말 것
공식 문서에 “의료 진단, 법률 자문, 재무 계획에는 적합하지 않다”고 나와 있습니다. 고위험 의사결정 시나리오에서는 추가 평가와 안전장치가 필요합니다. (출처: HuggingFace Model Card 2.2절)
③ 컨텍스트 길이 16,384 토큰
최대 컨텍스트 길이는 16,384 토큰입니다. 고해상도 이미지를 최대 3,600 시각 토큰으로 처리하므로, 이미지 하나에 많은 토큰을 소비합니다. 긴 문서에 여러 이미지를 동시 처리할 때 컨텍스트 초과 여부를 반드시 확인해야 합니다. (출처: HuggingFace Model Card 1절)
④ Image-to-Text 안전 결함률 4.5%
자동 레드팀 평가에서 텍스트→텍스트 안전 결함률은 1.4%였지만, 이미지→텍스트 안전 결함률은 4.5%로 높습니다. 시각 입력 처리에 안전 취약점이 상대적으로 더 남아있다는 뜻입니다. (출처: HuggingFace Model Card 3.1절)
⑤ 추론 모드 전환 경계는 아직 불완전합니다
언제 thinking을 쓰고 언제 직접 응답할지의 경계는 데이터 분포에서 암묵적으로 학습된 것이라 정확하지 않을 수 있습니다. 20/80 학습 비율이 모든 도메인에 최적인지도 아직 검증되지 않았습니다. 이 부분은 마이크로소프트 연구팀도 “열린 문제”라고 명시했습니다. (출처: Microsoft Research Blog, 2026.03.04)
Q&A 5가지
Q1. Phi-4-reasoning-vision-15B는 무료로 쓸 수 있나요?
모델 가중치와 코드는 MIT 라이선스로 공개돼 있어서 상업적 사용도 가능합니다. HuggingFace와 GitHub에서 무료로 다운로드할 수 있고, Microsoft AI Foundry에서도 체험할 수 있습니다. 단, 직접 서버에 띄워서 쓰려면 NVIDIA A100/H100/B200급 GPU가 필요합니다. (출처: HuggingFace Model Card 2.5절)
Q2. 기존 Phi-4-multimodal과 어떻게 다른가요?
2025년 2월 나온 Phi-4-multimodal(5.6B)은 텍스트·이미지·오디오를 처리하는 멀티모달 모델이었습니다. 이번 Phi-4-reasoning-vision-15B(15B)는 오디오 입력 없이 이미지+텍스트에 특화했지만, 추론(reasoning) 능력을 새롭게 붙였습니다. 벤치마크에서 기존 Phi-4-mm-instruct 대비 ChartQA 23.5 → 83.3으로 큰 격차가 납니다. (출처: HuggingFace Model Card Table 1)
Q3. 한국어 이미지나 문서에 써도 되나요?
공식 문서상 다국어를 목적으로 설계하지 않았습니다. 영어 기반 문서나 UI 인식에서는 강력하지만, 한국어 텍스트가 포함된 이미지 처리 시 OCR 정확도가 떨어질 수 있습니다. 직접 테스트 후 판단하는 게 맞습니다. (출처: HuggingFace Model Card 2.6절 — Quality of Service 항목)
Q4. 컴퓨터 UI 자동화 에이전트로 바로 쓸 수 있나요?
기반 모델로는 탁월한 선택입니다. ScreenSpot_v2에서 88.2점이고, 버튼·메뉴·입력창 위치를 정규화 좌표(0.0~1.0)로 출력합니다. 다만 “바로” 에이전트가 되진 않습니다. 실제 클릭·스크롤 같은 액션은 이 모델이 생성한 좌표를 받아서 다른 제어 레이어가 실행해야 합니다. (출처: Microsoft Research Blog 2026.03.04)
Q5. Qwen3-VL-32B와 비교하면 어느 쪽이 낫나요?
순수 정확도만 보면 Qwen3-VL-32B가 더 높습니다. MathVerse_MINI 기준 thinking 강제 시 78.2 vs 53.1로 차이가 있습니다. 그런데 Phi-4-reasoning-vision-15B의 파라미터는 절반 이하이고, 응답 속도와 출력 토큰 효율성에서 확실히 앞섭니다. 응답 속도와 비용이 중요한 인터랙티브 환경에서는 Phi-4가 유리합니다. (출처: HuggingFace Model Card Table 2)
마치며
솔직히 처음에는 “어차피 큰 모델이 다 이기는 거 아닌가”라는 생각이었습니다. 그런데 수치를 직접 들여다보니 그 공식이 생각보다 빨리 흔들리고 있습니다. 특히 Gemma3-12B의 ScreenSpot_v2 3.5점은 꽤 충격적이었습니다. 파라미터 수가 비슷해도 어떤 목적으로 어떻게 훈련했느냐에 따라 특정 영역에서 결과가 이렇게 갈릴 수 있다는 게 직접 확인됐습니다.
thinking이 항상 도움이 된다는 통념도 다시 봐야 할 것 같습니다. 차트 이해처럼 빠른 지각이 핵심인 작업에서는 더 생각할수록 오히려 점수가 내려갑니다. 이 부분은 멀티모달 AI를 실무에 적용할 때 구체적으로 체감할 수 있는 차이입니다.
가장 인상 깊었던 건 벤치마크 로그를 전부 공개하겠다는 약속입니다. 리더보드 숫자를 자기 방식으로 뽑아 발표하는 게 업계 관행인데, 그 기준을 투명하게 공개하는 건 여전히 흔한 일이 아닙니다. 공개된 로그를 보고 직접 검증하는 연구자가 많아질수록 이 모델의 신뢰도는 더 올라갈 겁니다.
📚 본 포스팅 참고 자료
- Microsoft Research Blog — Phi-4-reasoning-vision and the lessons of training a multimodal reasoning model (2026.03.04)
https://www.microsoft.com/en-us/research/blog/phi-4-reasoning-vision-and-the-lessons-of-training-a-multimodal-reasoning-model/ - HuggingFace Model Card — microsoft/Phi-4-reasoning-vision-15B (2026.03.04)
https://huggingface.co/microsoft/Phi-4-reasoning-vision-15B - arXiv — Phi-4-reasoning-vision-15B Technical Report (arXiv:2603.03975, 2026.03.04)
https://arxiv.org/html/2603.03975v1 - VentureBeat — Microsoft built Phi-4-reasoning-vision-15B to know when to think (2026.03.04)
https://venturebeat.com/technology/microsoft-built-phi-4-reasoning-vision-15b-to-know-when-to-think-and-when - Microsoft AI Foundry — Phi-4-Reasoning-Vision-15B 모델 카탈로그
https://ai.azure.com/catalog/models/Phi-4-Reasoning-Vision-15B
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 모든 수치는 2026.03.04 기준 공식 발표 자료를 근거로 합니다. 벤치마크 결과는 평가 환경과 방법에 따라 달라질 수 있으므로, 실제 사용 환경에서 직접 검증하는 것을 권장합니다.
댓글 남기기