빈 출력은 벤치 오류였습니다 — DS Vision-Exp 2×Spark 정착기 (속도 1.7배 + 유일한 JSON 통과)

왜 갈아탔나

flash-next를 반년 넘게 메인 모델로 굴려 왔습니다. 큰 불만은 없었는데, 최근 장문 작업에서 답이 어긋나는 기미가 보이고, 같은 질문을 되풀이받으면 살짝 허둥대는 모습이 눈에 띄더라고요. 그런데 8월 말, DS(DeepSeek) 정식 후속인 DeepSeek-V4-Flash-Vision-Exp(305B, MIT, 네이티브 비전)가 등장했습니다.

 

과거 DS 계열의 약점은 명확했습니다. 1M 컨텍스트는 되는데 비전이 없는 것이요. 텍스트는 강한데 이미지를 못 보니까, 제 작업의 절반쯤은 이 모델로 못 넘기는 셈이었죠. 그런데 Vision-Exp는 네이티브 비전을 내장으로 들고 나와서 그 약점이 그냥 사라졌습니다. 컨테이너도 이미 로컬에 있어서 재구축 부담이 최소였고요.

 

 

한쪽은 무료·빠른데 가끔 지어내고, 다른 쪽은 느려도 확실한. 예전에는 무조건 빠른 쪽만 고르곤 했는데, 이번에는 둘 다 누릴 수 있다는 게 포인트입니다. 밈이 이 상황을 그대로 그려주네요.

벤치 조건 — 공정성

이 시리즈의 제1원칙은 공정한 비교입니다. 그래서 조건을 단단하게 걸었습니다.

 

전부 로컬 2대(GB10 듀얼) A노드에서만 돌렸고, 온도 0에 동일 프롬프트를 썼습니다. OpenRouter 같은 외부 엔진은 환경이 다르면 공정비교가 아니니까, 비교 자체를 뺐습니다. effort는 low로 고정했는데, 이 시리즈에서 '템플릿 기본값 xhigh 세금'이라고 확정한 최적값입니다. 하니스는 quality 6 + code, 할루 10(위조) + 실화·가드 8, 비전 4, 속도 이렇게 나눠서 돌렸습니다.

결과

표가 말해주죠.

 

축	Vision-Exp	flash-next
quality (6+premise)	6/6+premise	5/7 (json 실패)
JSON 추출	통과 (2.3s)	실패
code RFC4180	pass	pass
비전 4종	4/4	4/4
할루 거절 (위조10)	10/10 (재검증)	10/10
실화+가드 8	8/8	8/8
prose 속도	38.8 tok/s	20~24

 

 

대부분의 축은 두 모델이 비슷했습니다. 그런데 세 곳에서 갈렸어요. JSON 추출은 Vision-Exp만 통과했고, quality에서도 앞섰고, prose 속도는 38.8 대 20~24로 1.7배 정도 빨랐습니다.

벤치 설계 오류 — '할루' 오판

초기 벤치에서 저는 f7(빈 출력)과 f10(가짜 플래그를 지어냄)을 '할루'라고 단정했었습니다. 그런데 재검증에서 유도형(존재 여부를 명시)으로 물으니, 둘 다 정확히 거절했습니다.

 

 

빈 출력 보고 할루라고 했는데, 사실은 max_tokens가 끝난 것입니다. finish_reason 한 줄이면 다 풀렸죠.

 

f7의 빈 출력은 reasoning이 max_tokens를 전부 소진해서 content가 0이 된 경우였습니다. 빈 출력이지 할루가 아니었어요. f10의 가짜 플래그는 free-form 질문의 모호성 때문이었고, 존재 여부를 명시하니 정확히 거절했습니다.

 

교훈으로 남긴 것은 세 가지입니다. 첫째, 빈 출력이 나오면 finish_reason을 먼저 확인하라. length라면 토큰 문제입니다. 둘째, free-form '설명하라'는 할루 측정에 부적합합니다. 존재 여부를 명시해야 합니다. 셋째, thinking이 max_tokens를 먹는 모델은 max_tokens를 넉넉히 주고 enable/budget을 통제해야 합니다.

 

여기서 이 글의 핵심 교훈이 나옵니다. 제가 '할루'로 오판한 것이 사실은 벤치 설계 결함이었습니다. 저는 틀렸습니다.

effort 재비치

effort를 low/high/max로 나눠 다시 재봤습니다. low의 품질이 high 및 max와 같았습니다. 수열이든 JSON이든 f9든 전부 맞혔습니다. max는 생각만 130~155초를 태웠죠. 그래서 low를 최적값으로 확정했습니다.

 

할루는 effort로 고칠 수 없습니다. 그것은 모델 특성이 아니라 질문·토큰 문제임을 이번에 확정했습니다.

비전 aux 통일

main과 auxiliary.vision을 모두 Vision-Exp로 맞췄습니다. 비전용 별도 모델이 필요 없어졌고, 한 노드로 통합됐습니다. 비전 재실측(문서 OCR / 개수 / 차트)도 전부 맞혔고, live 검증도 통과했습니다.

한계·후속

1일차라 하루 더 지켜봐야 합니다. 크론 실전이 관건이에요. f7/f10은 유도형에서는 정상인데, free-form 질문에서는 여전히 조심해야 합니다. V2 runner가 thinking_token_budget을 지원하지 않아서 프롬프트 유도로 회피했고요.

 

이런 세팅은 하루 굴리고 접는 것이 아니라, 크론이 며칠 돌아야 진짜인지 가짜인지가 나옵니다. 일주일 뒤에 다시 어떻게 됐는지 쓰도록 하겠습니다.