DeepSeek V4 Pro GA vs Preview 실측: 추론량 18-62% 감소

DeepSeek V4 Pro GA 버전은 동일한 작업에서 기존 Preview보다 추론 token을 18%에서 62% 적게 사용한다. 8,192-token 출력 window 전체를 소진할 수 있던 장애도 해결했다. thinking을 껐을 때 strict JSON 추출을 안정적으로 수행하는 첫 Pro 버전이기도 하다. 대신 Preview가 보여주던 “모르겠다”는 응답 능력은 사라졌다. GA 출시 4일 뒤, 한 batch에서 deepseek-v4-pro-0813과 Preview 버전을 비교했다. 측정값은 token 수로만 정리했다. 측정 전날 DeepSeek가 V4 가격을 변경하고 peak/off-peak 과금제를 추가했기 때문에, 계속 바뀌는 두 가격표를 달러로 비교하는 것보다 token 수가 더 유의미하다. DeepSeek는 GA 버전을 blog 글, changelog, 보도 자료 없이 출시했다. 무엇이 바뀌었는지 확인하려면 직접 측정해야 한다.

TL;DR

• GA는 작업당 추론 token을 18-62% 적게 사용한다. 단순 조회에서는 48개가 18개로 줄었다.
• 두 버전 모두 thinking을 켜면 strict JSON의 값이 잘못된다(정확도 2/8). 확인한 설정 중 GA에서 thinking을 끈 경우만 모든 값이 정확했다(8/8).
• GA는 Preview의 장애 하나를 해결했다. thinking_budget: 16 설정 시 Preview는 9회 중 5회 8,192-token 출력 window를 모두 채웠지만, GA는 9회 모두 정상 응답했다.
• GA에서는 명확한 답변 거부가 사라졌다. 존재하지 않는 대상을 물으면 Preview는 100-150 token 안에 답변을 거부하지만, GA는 아무것도 반환하지 않거나 답을 지어낸다.

GA 버전의 추론량은 얼마나 줄었나?

18%에서 62% 줄었으며, 단순한 작업일수록 차이가 컸다. 표준 작업 4개를 각각 3회 실행했다. 요청마다 salt를 추가했으며, 아래는 추론 token과 전체 completion token의 중앙값이다.

모든 작업에서 두 버전 모두 정확도가 3/3이었으므로, 품질을 희생하지 않고 효율만 개선됐다. 작업이 깊어질수록 절감 폭이 작아지는 패턴을 용량 계획에 반영해야 한다. 1-hop 조회에서는 62% 줄었지만, 5단계 연산에서는 18%만 줄었다. 두 버전의 실제 요금이 얼마든 차이의 형태는 이와 같다. 특히 구조화 추출은 strict json_schema에서 추론 token이 159개에서 40개로 줄어 4배 개선됐다.

전환 전후의 caching 동작은 같다. 두 버전 모두 5,000-token prefix 중 4,096 token을 cache에 저장했고, priming call 4초 뒤 cache hit을 반환했다. 현재 변하는 것은 동작 방식이 아니라 요금이다. DeepSeek는 V4 제품군 가격을 인상했고, 2026-08-16 16:00 UTC부터 off-peak에 절반 요금을 적용하는 peak/off-peak 과금제를 도입했다. 이 token 수를 비용으로 환산하기 전에 각 버전의 최신 가격표와 실행 시간을 확인해야 한다.

GA에서 측정 가능한 문제가 해결됐나?

그렇다. 이 제품군에서 비용이 가장 큰 장애가 해결됐다. Preview에 thinking_budget: 16을 보내면 정상 흐름을 잃는다. 짧게 추론한 뒤 답하는 대신 반복 loop에 빠져 “I’ll output: 168. I’ll output: 168…” 같은 내용을 max_tokens를 모두 쓸 때까지 생성한다. 같은 5단계 작업을 9회 실행한 결과, Preview는 5회 8,192-token window 전체를 채웠다. GA에서는 한 번도 발생하지 않았고, 매번 79-130 token 안에 정상 응답했다.

이 장애의 핵심은 비용이다. 추론량을 제한해 비용을 줄이려던 요청이 정상 응답의 약 130개 대신 completion token 8,193개를 과금한다. model에 덜 생각하라고 요청했지만 출력 비용은 63배가 된다. Preview에서 64-token budget도 안전하지 않았다. 3회 중 2회 오답(183, 174)을 반환했다. 아직 Preview 버전에 고정돼 있고 작은 thinking budget으로 비용을 제어한다면, 이 조합부터 제거해야 한다.

여기서는 thinking을 꺼도 안전하다. 이 제품군 전체에서 항상 안전한 것은 아니다. Flash 0731은 thinking을 끄자 2-hop 산술 정확도가 6/6에서 0/6으로 떨어졌다. 반면 두 Pro 버전은 thinking: {"type": "disabled"} 또는 enable_thinking: false를 사용해도 5단계 연산에서 3/3을 유지했다. Pro에서는 thinking을 꺼도 추론 작업의 정확도가 떨어지지 않으며, 아래에서 설명할 구조화 추출 문제도 해결된다.

두 버전 모두 dial은 여전히 실질적인 효과가 없다. reasoning_effort는 low, medium, high, xhigh, max를 허용한다. none과 minimal은 유효한 값 목록을 포함한 400 응답으로 거부한다. 5단계 작업에서 GA는 76-122개, Preview는 116-167개의 추론 token을 사용했지만 level에 따른 단조로운 증감은 없었다. 여러 vendor의 dial을 비교한 matrix 결과와 마찬가지로, DeepSeek에서는 enum이 아니라 off-switch와 budget으로 추론량을 제어한다.

thinking이 여전히 strict JSON을 망가뜨리나?

그렇다. 두 버전 모두 문제가 있으며, GA는 이를 안정적으로 피할 수 있는 첫 Pro 버전이다. DeepSeek V4 Flash 0731에서 이 결함을 확인했다. schema에는 맞지만 숫자가 틀린 JSON을 반환하는 문제다. 이 결함은 Pro에도 남아 있다. 세 줄짜리 invoice에서 필드 4개를 추출하도록 두 버전에 strict json_schema를 적용했다. 설정별로 8회 실행했고, schema뿐 아니라 값도 검사했다.

모든 실패 응답은 parsing과 schema 검증을 통과하지만, 값은 거짓이다. 항목이 명백히 3개인 문서에서 항목 수를 45, 22, 2026, -4, -35, -3864로 반환했다. 한 Preview 응답은 총액을 -139,308,173,307,904로 보고했고, 한 GA 응답은 아예 다른 회사(“MITRE”, 총액 1000)를 지어냈다. validator는 이 모든 응답을 유효한 JSON으로 판단한다.

운영 관점에서 결론은 간단하다. GA에서 구조화 추출 시 thinking을 끄면, 테스트한 모든 실행에서 결함이 사라졌다. 이 설정 하나만으로도 Preview에서 전환할 이유는 충분하다. Preview는 thinking을 꺼도 8회 중 6회 실패했다. Flash에서 측정한 제품군 패턴과도 일치한다. Flash 역시 thinking을 끄자 모든 실행이 정상화됐다. thinking control matrix에서 확인한 단일 단계 작업의 안전 구간에 해당하는 사례이기도 하다. 추출에는 숙고가 필요하지 않으며, 이 제품군에서는 숙고가 오히려 결과를 망친다.

GA에서 사라진 것은 무엇인가?

“모르겠다”고 답하는 능력이다. 존재하지 않는 대상 5개를 물었다. 회사 주가, 연구소 인원수, 마을 헌장, 합금 융점, 수상자였다. Preview는 100-150 output token 안에 명확히 답변을 거부했다. 예를 들면 “I don’t have any information about a 1987 Pan-Continental Robotics Prize.”라고 답했다. GA는 두 가지 방식으로 반응했으며, 둘 다 쓸모가 없다.

게시 전에 서로 독립된 두 번째 request path에서도 확인했다. 그 경로에서 Preview는 표본 질문 3개 모두 101-148 token 안에 답변을 거부했다. GA는 한 질문에 8,191 token을 사용하고 빈 답변을 반환했고, 다른 질문에는 불확실한 답을 내놓았다. 세 번째 질문에서는 존재하지 않는 합금의 구체적인 융점(“2,314 degrees Celsius”)을 단정했다. client가 달라도 같은 비대칭이 나타났으므로 model 자체의 동작이다.

검색 pipeline에서는 비용이 이중으로 발생한다. index로 답할 수 없는 질문이 hidden reasoning window 전체를 소모하고, 결과로 빈 응답이나 validator가 그대로 통과시킬 조작된 답변이 돌아온다. 답을 찾지 못한 query를 이 model로 route한다면 max_tokens를 충분히 낮게 설정해 장애를 명확하고 저렴하게 드러내야 한다. 빈 completion은 error가 아니라 miss로 처리해야 한다.

전환 시 그 밖에 달라지는 점이 있나?

거의 없다. 따라서 전환 여부는 integration보다 동작 차이로 결정하면 된다. 두 버전 모두 한 번의 call에서 input token 279,000개를 받아들이고, 중간에 삽입한 needle 질문에 답했다. 제품군 전체가 같은 tokenizer를 사용한다. 동일한 영어-중국어-code 혼합 corpus의 token 수가 GA, Preview, deepseek-v4-flash-0731에서 같았다. 제품군 내에서는 token budget을 그대로 이전할 수 있다. 두 버전 모두 temperature, top_p, top_k를 조용히 허용하며, DeepSeek가 문서화한 prefix-completion 기능인 사전 입력된 assistant turn도 지원한다.

Caching은 단위 크기까지 같다. 두 버전 모두 512-token prefix는 전혀 cache하지 않았다. 그보다 큰 prefix는 정확히 1,024-token page 단위(1,024, 2,048, 4,096)로 cache했고, priming call 4초 뒤 hit을 반환했다. Flash가 사용하는 page 크기와 같다. 비용과 관련해 하나 더 확인했다. 두 버전 모두 전체 chain of thought를 reasoning_content로 반환하며, 다음 turn에서 이를 replay해도 비용이 들지 않는다. 이전 turn의 reasoning을 포함하거나 제거해도 후속 turn에 GA는 동일하게 input token 134개, Preview는 56개가 과금됐다. 유지된 reasoning을 token 단위로 다시 과금하는 model과 달리, 이 제품군은 해당 내용을 단순히 버린다.

Tool loop에서는 우열이 없다. 두 function을 사용하는 agent loop에서 incident를 조회하고, 그 결과에 나온 service를 재시작하게 했다. 첫 hop에서는 GA의 추론량이 더 많았고(48 vs 34), 두 번째에서는 더 적었다(18 vs 35). 두 버전 모두 3/3으로 올바른 tool을 선택했다. DeepSeek는 이 release를 agent workload용으로 내세우고 있지만, hop별 추론량을 보면 headline의 효율 개선 수치만큼 뚜렷한 차이는 없다. 막다른 경로를 만나는 agent라면 앞서 설명한 답변 거부 동작이 더 중요하다.

FAQ

GA 버전의 실행 비용은 얼마나 낮은가?

Token 기준으로 작업당 추론량이 18-62% 적고, strict json_schema에서는 4배 적다. 달러 비용은 최신 가격표를 확인해야 한다. DeepSeek는 2026-08-16에 V4 제품군 가격을 변경하고, off-peak에 절반 요금을 적용하는 peak/off-peak 과금제를 추가했다. 같은 token 수라도 버전과 시간에 따라 비용이 달라진다.

GA 버전은 단순한 작업과 복잡한 작업 중 어디서 더 많이 절감되는가?

단순한 작업이다. 추론량은 1-hop 조회에서 62%, 2-hop 문장형 문제와 JSON 추출에서 약 48%, 5단계 산술에서는 18% 줄었다. 깊은 다단계 작업일수록 두 버전의 차이가 줄어든다. 단순하고 요청량이 많은 traffic에서 전환 효과가 크다.

DeepSeek V4 Pro에서 작은 thinking budget을 계속 사용해도 되는가?

Preview에서는 안 된다. thinking_budget: 16을 설정하면 반복 loop에 빠져 9회 중 5회 8,192-token 출력 window 전체를 소진했다. 비용을 줄이려던 요청의 출력 요금이 약 63배로 늘어난다. 64 token에서는 오답도 나왔다. GA는 같은 budget으로 9회 모두 정상 처리했다. 작은 budget으로 제어하려면 날짜가 명시된 GA 버전에서만 사용해야 한다.

DeepSeek V4 Pro의 strict JSON 출력을 신뢰할 수 있는가?

GA에서 thinking을 껐을 때만 가능하다. 설정별 8회 실행 결과, 두 버전 모두 thinking을 켜면 8회 중 6회 schema-valid 응답에 잘못된 숫자가 포함됐다. 항목이 3개인 invoice에서 항목 수를 45, 2026, -3864로 반환하기도 했다. GA에서 thinking: {"type": "disabled"}를 설정하면 8회 모두 정확한 값을 반환했다. Preview는 thinking을 꺼도 8회 중 6회 틀렸다. schema뿐 아니라 값도 검증해야 한다.

DeepSeek V4 Pro는 답할 수 없는 질문을 거부하는가?

Preview는 100-150 token 안에 답변을 거부한다. GA는 대부분 거부하지 않는다. 존재하지 않는 대상을 물으면 출력 window 전체를 thinking에 사용하고 빈 message를 반환하거나, 더 큰 window에서는 확신에 찬 거짓 답변을 내놓는다. 답변 거부가 없다고 신뢰하지 말고 자체 source로 검증해야 한다. 빈 completion은 miss로 처리해야 한다.

2026-08-17, GA 버전 공개 4일 뒤 Synthorai gateway를 통해 측정했다. 모든 비교에서 Preview 버전도 같은 batch로 다시 실행했다. dial 및 off-switch matrix(7개 effort 값, 5개 budget, 2개 off parameter, n=3), 4개 작업의 추론량 sweep, strict JSON 구조화 출력, 2-turn function-calling loop, 두 가지 window 크기에서 존재하지 않는 대상 5개를 묻는 probe, 필드 4개의 strict JSON 값 무결성 probe(설정별 n=8), reasoning replay 과금 비교, 두 가지 대기 시간의 implicit cache pair와 cache 최소 단위 bracket, needle을 포함한 279K-token context 허용 여부, V4 제품군에서 고정 corpus를 사용한 tokenizer 비교, sampling/prefill/n>1 허용 여부를 측정했다. 폭주 비율은 각 버전에서 max_tokens: 8192로 9회 실행한 결과다. 이 batch 측정 전날인 2026-08-16에 DeepSeek가 V4 제품군 가격을 변경하고 peak/off-peak 과금제를 도입했기 때문에 비용 대신 token 수를 기록했다. 답변 거부 동작과 폭주 문제는 독립된 두 번째 request path에서도 교차 확인했다. 요금과 동작은 바뀔 수 있으므로 특정 수치에 의존하기 전에 다시 측정해야 한다.

← 블로그로 돌아가기