DeepSeek V4 Flash API 비용: thinking이 strict JSON을 망가뜨린다

DeepSeek V4 Flash 요금은 input token 100만 개당 $0.14, output token 100만 개당 $0.28이며, cache hit은 $0.0028이다. 현재 이 이름으로 제공되는 재학습된 0731 build에는 우회가 필요한 결함이 있다. thinking을 기본값인 활성 상태로 두고 strict json_schema를 사용하면, 서로 독립적인 요청 경로 2개에서 실행한 13회의 기본 thinking 테스트 중 8회에서 integer field가 손상됐다. thinking을 끄자 모든 실행이 정상화됐고, 추출에 사용한 token은 7분의 1로 줄었다. 출시 첫날 deepseek-v4-flash-0731을 측정해 이 손상 문제, 재학습 후 더 가팔라진 thinking 비활성화 성능 절벽, 이를 복구하는 최소 budget, 1,024-token cache page, 그리고 preview build 및 V4 Pro와 여전히 다른 점을 확인했다.

TL;DR

• 기본 thinking과 strict json_schema를 함께 사용하면 deepseek-v4-flash-0731은 요청 경로 2개에서 13회 중 8회 integer field를 손상시켰다. V4 Pro는 4회 중 2회 손상됐고, preview만 모두 정상적이었다.
• 0731 재학습으로 thinking을 껐을 때의 성능 절벽이 더 가팔라졌다. 2-hop 수학 문제 정확도가 6/6에서 0/6으로 떨어졌다.
• cache는 약 1.1K-token부터 1,024-token page 단위로 동작한다. priming 후 0.3초 만에 hit했고, entry는 45분이 지나도 유지됐다.
• enable_thinking: false는 모든 structured 실행을 정상화하면서 token 사용량을 7분의 1로 줄였다. 2-hop 수학 문제에 안전한 thinking budget은 256이다.

세 가지 V4 build의 명세와 실제 측정치는 어떻게 다른가?

tokenizer, cache, thinking 구조는 같다. 가격과 failure mode는 다르다. 아래 결과는 세 모델에 동일한 probe를 실행해 측정했다. 대시는 해당 항목을 측정하지 않았다는 뜻이다. 출시 첫날 분석 스레드는 benchmark에 초점을 맞추므로, 여기서는 운영 측면을 비교한다.

thinking mode가 V4 Flash의 구조화 출력을 손상시키는가?

0731 build에서는 그렇다. 문제는 눈에 띄지 않아 production까지 그대로 흘러갈 수 있다. 네 개 field로 구성된 invoice 추출 작업에서 strict json_schema를 사용해 vendor, date, total, line-item count를 추출했다. 기본 thinking이 반환한 JSON은 schema 검증을 통과했지만 숫자는 틀렸다. 항목이 명백히 3개인 문서에서 line_items가 -1, 1, -1, -19로 반환됐고, gateway를 통한 기본 thinking 실행 5회 중 정답은 없었다. budget을 제한해도 피할 수 없다. 64-token budget에서도 같은 방식으로 손상됐으며, 256-token budget에서도 3회 중 1회가 line-item count를 670으로 반환했다. 손상 여부는 thinking의 크기가 아니라 thinking의 존재 자체를 따라간다. 별도의 독립적인 요청 경로에서 같은 probe를 실행했을 때도 batch 2개, 총 8회 중 3회가 손상됐다. 한 번은 문서의 $520.00 대신 total을 519.95로 반환했고, 다른 한 번은 line-item count를 22로 반환했다. 이 경로는 thinking을 끄라는 요청에도 reasoning을 계속 사용했으므로, 아래의 정상화 방법은 primary 경로에서 검증했다. JSON은 항상 parsing되고 schema도 매번 통과한다. 값만 틀린다. validation 결과를 신뢰하는 pipeline에서 발생할 수 있는 최악의 failure mode다.

해결 방법은 한 줄이다. enable_thinking: false를 사용하자 모든 실행에서 정확하고 유효한 JSON이 생성됐다. completion token은 약 44개로, 기본값의 328개보다 훨씬 적었다. 모델별 차이도 분명하다. 동일한 조건에서 thinking을 켜고 측정한 preview build는 4/4 모두 정상이었지만, V4 Pro는 4회 중 2회 손상됐다. 이 문제는 V4 thinking 계열 전반에 걸쳐 있으며, 재학습된 flash에서 가장 심하다. 이미 알려진 thinking과 schema 조합의 bug와도 다르다. vLLM은 지난 4월 DeepSeek JSON이 content를 비운 채 reasoning field에 들어가던 연결 계층 문제를 수정했다. 이번에는 연결 계층이 정상이고 값 자체가 틀린다. 훨씬 더 심각한 문제다. DeepSeek가 수정하기 전까지 이 모델에서는 thinking과 strict structured output을 함께 사용하지 않는 편이 안전하다. 추가 비용도 없다. single-step 추출은 thinking을 꺼도 안전한 workload이며, 비용도 7배 낮다.

API는 어떤 thinking control을 지원하는가?

비활성화 방법은 2개이고, 정확한 budget과 off 옵션이 없는 effort dial도 있다. 측정한 API surface는 reasoning_effort 값으로 low, medium, high, xhigh, max를 지원한다. Qwen 3.8 Max와 달리 none과 minimal은 거부되므로, 이 dial만으로는 모델의 thinking을 멈출 수 없다. thinking을 끄려면 enable_thinking: false 또는 thinking: {"type": "disabled"}를 사용해야 한다. 두 방식은 동일하게 동작했고, 간단한 질문에 9-token 답변을 생성했다. thinking_budget은 Qwen 3.8에서 측정한 결과와 마찬가지로 token 단위까지 정확히 적용된다. 16을 요청하면 meter에도 16으로 표시된다. 전체 chain of thought는 reasoning_content로 반환되며, 고정 prompt overhead는 호출당 5 tokens에 불과하다.

반면 effort dial에서는 측정 가능한 차이가 없었다. 큰 소수 개수 세기 문제에서 low와 high는 각각 31,374개와 31,370개의 reasoning token을 사용했다. 기본값은 26,897개였고 세 설정 모두 정답이었다. 일반적인 분산일 뿐, cap이 적용된 흔적은 없었다. Qwen 3.8의 level은 숨겨진 budget cap이라 복잡한 작업에서 실제로 제한이 걸리지만, V4 Flash의 level은 측정한 모든 깊이에서 아무 변화도 만들지 않았다. 이 모델에서 의미 있는 control은 비활성화 switch와 thinking_budget뿐이다. dial은 장식에 가깝다. DeepSeek 자체 model card는 agent benchmark에 “max reasoning effort”를 고정했지만, 측정한 API surface에서는 기본값과 구분되는 결과가 나오지 않았다.

2-hop 수학에는 실제로 thinking이 얼마나 필요한가?

재학습 전보다 더 많이 필요하다. 다른 모델에서 권장했던 저비용 mode 전략과 반대다. 2-hop 산술 batch는 상자 1850개에 부품 24개씩, 그중 75%를 배송하고 3,120개가 도착하는 문제다. 세 V4 build는 서로 다른 모델처럼 동작했다.

두 가지를 알 수 있다. 첫째, agent 재학습으로 산술 처리가 thinking channel로 이동했다. preview build는 thinking을 꺼도 간신히 답하지만, 0731은 완전히 무너진다. Pro는 영향을 전혀 받지 않는다. 둘째, 최소 budget은 모델마다 다르다. 같은 batch에서 Qwen 3.8 Max는 thinking token 16개만으로 완전히 복구되지만, 0731은 256개가 필요하다. 256에서는 모두 정답이면서 기본값보다 저렴했다. completion 총량은 53-188개로, 기본값의 100-200개보다 적었다. thinking-budget 설정을 다른 모델로 옮길 때는 정확도를 다시 확인해야 한다. control 자체는 공통이지만 threshold는 공통이 아니다.

implicit cache의 성능은 어떤가?

낮은 최소 길이부터 1,024-token page 단위로 동작하며, 빠르게 제공되고 오래 유지된다. salt를 추가한 prefix pair로 측정한 결과, prompt가 길어질수록 정확히 1,024, 2,048, 4,096, 7,168 tokens가 hit했다. 1,024 단위로 page 정렬된 quantization이다. 최소 길이는 page 하나를 약간 넘는 수준이다. 704-token prompt는 한 번도 hit하지 않았지만, 1,166 tokens에서는 1,024개가 hit했다. priming 후 0.3초 만에 hit했으므로 별도의 build lag을 고려해 설계할 필요가 없다. entry는 +45분에도 계속 제공됐다. 이 가격대에서 측정한 implicit cache 중 가장 오래 유지됐다. Qwen 3.8 Max의 entry는 15분과 45분 사이에 사라졌고, 최소 길이는 약 4.3K tokens다. DeepSeek의 cache-hit input 정가는 100만 개당 $0.0028로 miss 가격의 2%이며, write premium은 없다. 일반적인 계층화 원칙대로 안정적인 prefix를 앞에 두고 변동되는 content를 뒤에 배치하면 된다.

1M context와 384K output 한도는 실제로 적용되는가?

측정한 모든 범위에서 context window는 유지됐다. prompt token 137,638개, 465,238개, 838,198개 지점에 삽입한 override code를 7초에서 20초 안에 그대로 반환했다. 이 가격대에서 측정한 long-context recall 중 가장 빨랐다. output 쪽 제한은 문서보다 느슨하다. DeepSeek가 공개한 최대 output은 384K tokens지만, max_tokens를 393,217이나 524,288로 지정한 요청도 thinking mode와 non-thinking mode 모두에서 승인됐다. 요청 시점에는 cap을 강제하지 않으므로, 과도한 budget을 설정해도 명확한 오류가 발생하지 않는다. 상한이 필요하다면 직접 설정해야 한다.

Preview, 0731, Pro 중 실제 호출에 응답하는 build는 무엇인가?

DeepSeek 가격 페이지에는 이제 deepseek-v4-flash SKU 하나만 표시된다. model version은 DeepSeek-V4-Flash-0731이며 가격은 그대로다. 실제로는 일부 route에서 preview build가 여전히 별도 이름으로 제공된다. 두 build는 tokenizer를 공유하지만 외부에서도 쉽게 구분할 수 있다. 영어, 중국어, code corpus에서 token count가 동일하므로 budget은 그대로 옮길 수 있다. 가장 확실한 fingerprint는 thinking 비활성화 probe다. batch 기준으로 thinking을 끈 2-hop 수학 정확도는 preview에서 약 2/6, 0731에서 0/6이다. structured-output probe를 모두 통과한 build도 preview뿐이었다. preview는 4/4 정상이었고, 0731은 5/5 손상, Pro는 2/4 손상이었다. traffic이 이 동작 중 하나에 의존한다면 이름을 믿지 말고 실제 호출하는 endpoint를 probe해야 한다. V4 Pro ($0.435/$0.87)는 수학 성능 절벽은 피했지만 structured-output 문제는 피하지 못했다.

계획 단계에서 고려할 점이 하나 있다. 세 모델이 공유하는 tokenizer는 동일한 corpus에서 Qwen 3.8보다 약 6-9% 많은 token을 사용한다. vendor 간 budget을 비교할 때는 요금표만 보지 말고 언어별 token 밀도를 확인해야 한다.

FAQ

DeepSeek V4 Flash에서 구조화 출력은 안전한가?

thinking을 끄면 안전하다. strict json_schema가 적용됐고 batch의 모든 추출 결과가 정확했다. 0731 build에서 기본 thinking을 켜면 요청 경로 2개, 총 13회 중 8회에서 integer field가 손상됐지만 schema validation은 그대로 통과했다. V4 Pro도 같은 probe에서 4회 중 2회 손상됐고, preview build만 모두 정상이었다. 결함이 수정될 때까지 structured-output route에는 enable_thinking: false를 고정해야 한다.

DeepSeek V4 Flash에서 thinking을 끌 수 있는가?

가능하다. enable_thinking: false 또는 thinking: {"type": "disabled"}를 사용하면 된다. 다만 0731 재학습 이후 thinking 비활성 상태는 multi-step 작업에 취약해졌다. 2-hop 수학에서 0/6이었다. single-hop lookup보다 복잡한 작업에는 최소 thinking_budget 256을 사용해야 한다. 측정 결과 모두 정답이었고 기본값보다 저렴했다.

V4 Flash cache에 필요한 최소 prompt 크기는 얼마인가?

1,024 tokens를 약간 넘는 수준이다. 704-token prompt는 한 번도 cache되지 않았고, 1,166-token prompt는 정확히 1,024개가 hit했다. hit은 1,024-token page 단위로 quantize되고, priming 후 0.3초 만에 발생하며, 45분이 지나도 유지됐다. cache-hit input 정가는 100만 개당 $0.0028로 miss 가격의 2%다.

0731 release에서 가격이 바뀌었는가?

아니다. DeepSeek는 input 100만 개당 $0.14 (cache miss), $0.0028 (cache hit), output 100만 개당 $0.28를 유지했다. 0731은 현재 model version으로 기존 deepseek-v4-flash 이름에 통합됐다. 바뀐 것은 가격이 아니라 동작이다. thinking 의존성이 더 커졌고 위에서 설명한 structured-output 결함이 생겼다.

2026-08-04에 Synthorai gateway를 통해 deepseek-v4-flash-0731을 측정했다. 비교군은 deepseek-v4-flash preview와 deepseek-v4-pro다. 실행별 payload를 기록한 strict-schema 추출 batch를 별도의 독립적인 요청 경로에서 재검증했다. dial 허용 범위 및 비정상 값 probe, 설정별 n=4-6이며 salt를 적용한 2-hop 정확도 batch와 thinking-budget 단계별 복구 테스트, 2.5초 간격의 salted cache pair로 최소 길이, page, lag, gap을 측정했다. 두 mode에서 max_tokens 경계를 probe했고, 세 모델과 Qwen 3.8 Max를 대상으로 동일한 corpus 3개의 tokenizer count를 비교했다. 금액은 발행 시점에 DeepSeek가 공개한 정가다. 실제 provider의 meter를 별도로 확인해야 한다. DeepSeek가 0731 build를 계속 수정하면 동작이 바뀔 수 있다.

← 블로그로 돌아가기