Split View: DeepSeek V4 Flash가 실제로 바꾸는 것 — 리더보드가 아니라 능력당 단가의 문제
DeepSeek V4 Flash가 실제로 바꾸는 것 — 리더보드가 아니라 능력당 단가의 문제
- 들어가며 — 프리뷰가 공개 베타가 된 날, 정작 모델은 그대로였다
- 스펙 — 284B 중 13B만 켜지는 모델
- 공개된 점수는 누가, 어떤 하네스로 쟀나
- 가격표의 진짜 항목은 헤드라인이 아니라 캐시 적중 단가
- 능력당 단가로 다시 계산하면
- Flash는 지연 시간 이야기가 아니라 티어 이름이다
- 라우팅 결정 규칙 — 그리고 아직 모르는 것
- 마치며 — 순위표는 한 달이면 뒤집히지만, 가격표의 모양은 오래 간다
들어가며 — 프리뷰가 공개 베타가 된 날, 정작 모델은 그대로였다
2026년 7월 31일, DeepSeek이 V4-Flash API를 공개 베타로 전환했습니다. 공식 체인지로그의 문장이 정확한데, 이번 릴리스는 "DeepSeek-V4-Flash-Preview와 모델 아키텍처와 크기를 그대로 유지하고 사후학습만 다시 했다"고 밝히고 있습니다. 파라미터도, 컨텍스트도, 가격도 그대로입니다. 바뀐 것은 post-training 한 겹과 Responses API · Codex 프레임워크 네이티브 지원뿐입니다.
그런데 공개된 점수는 꽤 크게 움직였습니다. Terminal Bench 2.1에서 82.7, Toolathlon verified에서 70.3입니다. Hacker News 스레드에서 프리뷰 시절 수치와 나란히 놓은 사람들은 각각 56.9에서 82.7로, 51.8에서 70.3으로 올랐다고 지적했습니다. 같은 가중치 크기에서 사후학습만으로 에이전트 벤치마크가 20점 이상 움직였다는 주장입니다.
이 글은 그 점수의 순위를 따지지 않습니다. 순위표는 한 달이면 뒤집히고, 대부분의 팀에게 실제로 걸린 질문은 "이게 몇 등이냐"가 아니라 "내 트래픽 중 어느 부분을 여기로 옮기면 청구서가 얼마나 줄고 품질은 얼마나 나빠지느냐"입니다. 그래서 여기서는 능력당 단가로 계산하고, 어떤 숫자가 벤더 자체 측정인지 매번 명시합니다.
스펙 — 284B 중 13B만 켜지는 모델
먼저 물리적 사실부터 정리합니다. DeepSeek V4 Flash는 총 284B 파라미터 중 토큰당 13B만 활성화되는 sparse MoE입니다. 컨텍스트는 1,048,576 토큰, 최대 출력은 384K 토큰입니다. 텍스트 전용이고 비전이나 오디오는 없습니다. 이 스펙은 OpenRouter의 모델 페이지와 DeepSeek 공식 가격 문서에서 교차 확인됩니다.
같은 계열의 상위 모델인 V4 Pro는 1.6T 총 파라미터에 토큰당 약 49B 활성으로 알려져 있습니다. 두 모델의 관계를 이해하는 데 이 숫자 쌍이 핵심입니다 — Flash는 Pro를 증류하거나 잘라 낸 모델이라기보다, 활성 파라미터를 4분의 1 수준으로 낮춰 서빙 단가를 구조적으로 떨어뜨린 별도 아키텍처에 가깝습니다. 그래서 가격도 정확히 그 비율을 따라갑니다. 출력 기준으로 Flash는 100만 토큰당 0.28달러, Pro는 0.87달러로 약 3.1배 차이입니다.
여기서 자주 오해가 생깁니다. 활성 13B라는 숫자는 연산량을 말하는 것이지 메모리 요구량이 아닙니다. 자체 호스팅을 고려한다면 284B 전체를 어딘가에 올려 두어야 하고, 4비트로 눌러도 140GB대가 필요합니다. 활성 파라미터가 작다는 것은 "작은 GPU에서 돌아간다"가 아니라 "같은 GPU에서 훨씬 많은 토큰을 뽑는다"는 뜻입니다. 이 구분이 흐려지면 자체 호스팅 견적이 통째로 틀어집니다. 로컬 실행 쪽 산수는 로컬에서 LLM 돌리려면 VRAM이 얼마나 필요한가 편에서 공식으로 다뤘습니다.
공개된 점수는 누가, 어떤 하네스로 쟀나
체인지로그가 공개한 0731 점수는 다음과 같습니다. Terminal Bench 2.1 82.7, NL2Repo 54.2, Cybergym 76.7, DeepSWE 54.4, Toolathlon verified 70.3, Agent Last Exam 25.2, Automation Bench(Public) 25.1, DSBench-FullStack 68.7, DSBench-Hard 59.6.
이 숫자들에는 조건이 붙어 있고, 그 조건이 중요합니다. 체인지로그는 측정 방식을 "DeepSeek Harness minimal 모드, max effort 레벨, top_p 0.95, temperature 1.0"이라고 명시합니다. 즉 자사 하네스로, 최대 추론 강도에서 잰 벤더 자체 측정치입니다. HN 스레드에서 나온 지적도 정확히 이 지점이었습니다. 에이전트 벤치마크는 스캐폴딩에 극도로 민감해서, 같은 모델도 하네스를 바꾸면 두 자릿수로 움직입니다. 다른 벤더가 자기 하네스로 발표한 숫자와 나란히 놓고 순위를 매기는 순간 그 표는 의미를 잃습니다.
독립 측정 쪽은 어떨까요. Artificial Analysis는 V4 Flash 0731을 최대 추론 강도에서 Intelligence Index 50으로 집계합니다. 같은 지수에서 GPT-5.6 Sol은 59, Terra 55, Luna 51입니다. 그러니까 종합 지능 지표만 보면 Flash는 OpenAI의 가장 싼 티어와 비슷한 자리에 있습니다. 코딩 쪽 3자 집계로는 SWE-bench Verified에서 Flash가 79.0%, Pro가 80.6%라는 수치가 돌아다니는데, 이건 llm-stats 계열 집계를 인용한 2차 자료라 원 측정 조건을 제가 확인하지 못했습니다. 그대로 믿지 말고 자기 과제로 재는 편이 낫습니다.
한 가지 독립 측정이 특히 실무적입니다. Artificial Analysis는 이 모델이 지수를 완주하는 데 210M 토큰을 썼다고 기록하는데, 전체 모델 중앙값이 62M입니다. 답을 내기까지 사고 토큰을 매우 많이 씁니다. 벤치마크 점수에는 이게 장점으로 잡히지만 청구서에는 출력 토큰으로 잡힙니다. 뒤에서 다시 계산합니다.
가격표의 진짜 항목은 헤드라인이 아니라 캐시 적중 단가
공식 가격 문서 기준으로 각 모델의 100만 토큰당 단가를 정리하면 이렇습니다. OpenAI 쪽은 7월 30일 인하가 반영된 값이고, 캐시 적중 단가는 공표된 90% 할인율을 입력가에 적용한 값입니다.
| 모델 | 캐시 적중 입력 | 캐시 미스 입력 | 출력 | 출력 대 입력 배수 |
|---|---|---|---|---|
| DeepSeek V4 Flash | 0.0028달러 | 0.14달러 | 0.28달러 | 2배 |
| DeepSeek V4 Pro | 0.003625달러 | 0.435달러 | 0.87달러 | 2배 |
| GPT-5.6 Luna | 0.02달러 | 0.20달러 | 1.20달러 | 6배 |
| GPT-5.6 Terra | 0.20달러 | 2달러 | 12달러 | 6배 |
| GPT-5.6 Sol | 0.50달러 | 5달러 | 30달러 | 6배 |
이 표에서 헤드라인 숫자보다 오래 봐야 할 열은 맨 오른쪽입니다. DeepSeek은 출력이 입력의 2배인데 OpenAI 계열은 6배입니다. 가격표의 모양 자체가 다릅니다.
그리고 맨 왼쪽 열이 더 극적입니다. Flash의 캐시 적중 입력은 100만 토큰당 0.0028달러로, 캐시 미스 대비 50분의 1입니다. GPT-5.6 Luna의 캐시 적중 단가와 비교하면 약 7배 저렴합니다. HN 스레드에서 어느 사용자가 30일 동안 3,467건의 API 요청으로 323M 토큰을 쓰고 4.55달러를 냈다고 보고했는데, 이 정도 숫자는 캐시 적중률이 매우 높은 워크로드가 아니면 나오지 않습니다. 긴 시스템 프롬프트와 고정된 코드베이스 컨텍스트를 반복해서 보내는 코딩 에이전트가 정확히 그런 모양입니다.
주의할 함정이 두 개 있습니다. 첫째, 캐시 할인율이 곧 청구서 절감률이 아닙니다 — 출력이 이미 비용의 큰 부분을 먹고 있으면 입력 쪽 90% 할인은 총액을 90% 깎지 못합니다. 이 계산은 LLM API 비용을 실제로 줄이는 법 편에서 자세히 다뤘습니다. 둘째, DeepSeek 가격 문서에는 피크·오프피크 차등 요금 계획이 예고돼 있습니다. 베이징 시간 기준 오전 9시부터 정오, 오후 2시부터 6시 구간에 요금이 2배가 되는 정책인데, 문서는 발효일을 아직 공식 발표하지 않았다고 적고 있습니다. 한국 시간대와 겹치는 구간이라 견적을 낼 때 반드시 계산에 넣어야 합니다.
능력당 단가로 다시 계산하면
같은 워크로드를 두 모델에 태워 실제 산수를 해 봅니다. 인하 후 GPT-5.6 Luna와 DeepSeek V4 Flash는 Intelligence Index에서 51 대 50으로 사실상 같은 자리에 있으니, 능력을 고정하고 가격만 비교하기에 좋은 쌍입니다.
워크로드 A — 입력 편중 (긴 문서 요약, RAG 응답)
요청당 입력 50,000 토큰 / 출력 500 토큰
Luna : 50,000 x 0.20 / 1e6 = 0.01000
+ 500 x 1.20 / 1e6 = 0.00060 -> 0.01060 달러
V4 Flash : 50,000 x 0.14 / 1e6 = 0.00700
+ 500 x 0.28 / 1e6 = 0.00014 -> 0.00714 달러
Flash가 약 1.5배 저렴
워크로드 B — 출력 편중 (추론, 코딩 에이전트)
요청당 입력 2,000 토큰 / 출력 10,000 토큰 (사고 토큰 포함)
Luna : 2,000 x 0.20 / 1e6 = 0.00040
+ 10,000 x 1.20 / 1e6 = 0.01200 -> 0.01240 달러
V4 Flash : 2,000 x 0.14 / 1e6 = 0.00028
+ 10,000 x 0.28 / 1e6 = 0.00280 -> 0.00308 달러
Flash가 약 4.0배 저렴
같은 두 모델인데 격차가 1.5배에서 4배로 벌어집니다. 헤드라인 입력 가격만 보면 0.14 대 0.20으로 30% 차이인데, 실제 청구서 차이는 워크로드의 입출력 믹스가 결정합니다. 출력 대 입력 배수가 2배인 가격표는 출력이 길어질수록 유리해지고, 6배인 가격표는 그 반대입니다.
여기서 앞의 관측이 되돌아옵니다. Flash는 사고 토큰을 많이 쓰는 모델입니다. 즉 워크로드 B 쪽으로 자연히 밀립니다. 출력 단가가 낮은 가격표와 출력을 많이 쓰는 모델이 만나면 둘이 상쇄되므로, "출력이 싸니까 마음껏 생각시켜도 된다"는 결론은 실측 없이는 위험합니다. 추론 강도를 max로 두고 잰 벤치마크 점수와, 실제 서비스에서 쓸 강도에서의 비용은 다른 이야기입니다. 강도를 낮췄을 때 점수가 얼마나 떨어지는지는 벤더가 공개하지 않았고, 저도 확인하지 못했습니다.
Flash는 지연 시간 이야기가 아니라 티어 이름이다
이름 때문에 생기는 오해를 하나 짚고 갑니다. 다른 벤더의 Flash 티어는 대체로 "빠른 응답"을 뜻하지만, DeepSeek의 Flash는 지연 시간 등급이 아니라 활성 파라미터가 작은 모델 계열의 이름입니다. 실제로 응답이 빠르냐는 완전히 별개의, 그리고 제공자에 따라 크게 갈리는 문제입니다.
Artificial Analysis의 제공자별 집계를 보면 같은 가중치를 서빙하는데도 출력 속도가 초당 100토큰대에서 200토큰대 후반까지 흩어지고, 첫 토큰까지의 시간도 제공자 간 편차가 매우 큽니다. 별도 벤치마크에서는 중앙값 처리량 초당 164.7토큰, 중앙값 TTFT 1,924밀리초라는 수치가 보고됩니다. 추론 모드에서는 "첫 토큰"과 "첫 답변 토큰"이 다르다는 점도 중요합니다 — 사고 토큰이 먼저 흐르므로, 사용자가 실제 답을 보기까지의 체감 지연은 TTFT보다 훨씬 깁니다. 실시간 대화형 UI에 이 모델을 붙일 계획이라면 TTFT가 아니라 첫 답변 토큰까지의 시간을 재야 합니다.
또 하나. 공식 API의 동시 요청 한도는 Flash가 2500, Pro가 500으로 문서에 적혀 있습니다. 배치성 작업을 몰아넣을 때 실질적인 상한이 되는 숫자이니 용량 계획에 넣어 두는 편이 좋습니다.
라우팅 결정 규칙 — 그리고 아직 모르는 것
지금까지의 숫자를 결정 규칙으로 압축하면 이렇습니다.
- 출력이 길고 반복 프리픽스가 큰 트래픽은 여기로 보낼 명확한 이유가 있습니다. 코드 리뷰, 대량 분류, 로그 요약, 내부 도구용 에이전트가 여기 해당합니다. 캐시 적중 단가와 출력 단가가 동시에 유리하게 작동하는 유일한 구간입니다.
- 입력만 길고 출력이 짧은 트래픽은 차이가 1.5배 수준으로 줄어듭니다. 이미 다른 벤더에 물려 있고 마이그레이션 비용이 있다면 옮길 이유가 약합니다.
- 품질 상한이 결과를 지배하는 트래픽은 옮기지 마세요. SWE-bench Pro나 장기 에이전트 과제에서 최상위 모델과의 격차는 여전히 실재하고, 실패 한 번의 비용이 토큰 값보다 훨씬 큰 워크로드에서는 단가 비교 자체가 잘못된 프레임입니다.
- 데이터 거버넌스 제약이 있는 트래픽은 가격과 무관하게 별도 판단이 필요합니다. HN 스레드에서도 코드베이스가 어디로 흘러가는지에 대한 우려와, 개인 구독자에게는 무보존 정책이 제공되지 않는다는 지적이 반복해서 나왔습니다. 가중치가 MIT 라이선스로 공개돼 있으므로 자체 호스팅이라는 선택지가 있다는 점이 이 모델의 실질적인 차별점입니다. 다만 284B를 올릴 하드웨어 비용이 곧바로 되돌아옵니다.
확인하지 못한 것도 분명히 적어 둡니다. 프리뷰 대비 점수 상승폭(Terminal Bench 56.9에서 82.7 등)은 공식 체인지로그의 한 표가 아니라 커뮤니티가 두 시점의 발표치를 이어 붙인 것이고, 저는 두 값이 같은 하네스에서 나왔는지 확인하지 못했습니다. 추론 강도를 낮췄을 때의 점수·비용 곡선, 1M 컨텍스트의 실제 유효 길이(맨 뒤 토큰까지 성능이 유지되는지), 피크 요금제의 발효일도 모두 미공개입니다. 그리고 자체 하네스로 잰 에이전트 점수는, 그 하네스가 공개되기 전까지는 비교 가능한 숫자가 아니라 벤더의 주장입니다.
마치며 — 순위표는 한 달이면 뒤집히지만, 가격표의 모양은 오래 간다
이번 릴리스에서 오래 남을 정보는 82.7이라는 점수가 아니라 가격표의 구조입니다. 출력 대 입력 배수가 2배인 가격표와 6배인 가격표는 같은 능력이라도 다른 워크로드를 끌어당깁니다. 그리고 캐시 적중 단가가 캐시 미스의 50분의 1이라는 항목은, 프리픽스를 고정할 수 있는 팀과 못 하는 팀 사이의 청구서를 한 자릿수 배로 갈라놓습니다.
그러니 순위표를 다시 읽는 대신 자기 로그를 여세요. 요청당 입력 토큰과 출력 토큰의 중앙값, 프리픽스 재사용률, 실패 한 번의 비용 — 이 세 숫자만 있으면 어느 모델로 보낼지는 계산으로 나옵니다. 벤치마크는 그 계산의 입력 중 하나일 뿐이고, 그마저도 누가 어떤 하네스로 쟀는지 확인한 뒤에야 쓸 수 있습니다.
What DeepSeek V4 Flash Actually Changes — A Cost-per-Capability Question, Not a Leaderboard One
- Introduction — The Day the Preview Became a Public Beta, While the Model Itself Stayed Put
- The Specs — A Model Where Only 13B of 284B Lights Up
- Who Measured the Published Scores, and on What Harness
- The Real Line Item on the Price Sheet Is Not the Headline, It Is the Cache-Hit Price
- Recomputing in Cost per Capability
- Flash Is a Tier Name, Not a Latency Story
- Routing Rules — And What We Still Do Not Know
- Closing — Leaderboards Flip in a Month, but the Shape of a Price Sheet Lasts
Introduction — The Day the Preview Became a Public Beta, While the Model Itself Stayed Put
On July 31, 2026, DeepSeek moved its V4-Flash API into public beta. The official changelog puts it precisely: this release "keeps the model architecture and size of DeepSeek-V4-Flash-Preview and only redoes post-training." Parameters, context, and price are all unchanged. What changed is one layer of post-training, plus native support for the Responses API and the Codex framework.
The published scores, however, moved quite a lot. 82.7 on Terminal Bench 2.1, and 70.3 on Toolathlon verified. People in the Hacker News thread who lined these up against the preview-era figures pointed out that they went from 56.9 to 82.7 and from 51.8 to 70.3 respectively. The claim is that at the same weight count, post-training alone moved agentic benchmarks by more than 20 points.
This post is not going to argue about where those scores rank. Leaderboards flip within a month, and for most teams the question actually on the table is not "what place did it come in" but "which slice of my traffic can I move here, how much smaller does the invoice get, and how much worse does quality get." So here we compute in cost per capability, and we state every single time which numbers are vendor self-measured.
The Specs — A Model Where Only 13B of 284B Lights Up
Start with the physical facts. DeepSeek V4 Flash is a sparse MoE with 284B total parameters, of which only 13B activate per token. Context is 1,048,576 tokens and maximum output is 384K tokens. It is text-only, with no vision and no audio. These specs cross-check between OpenRouter's model page and DeepSeek's official pricing doc.
V4 Pro, the higher model in the same family, is reported to have 1.6T total parameters with roughly 49B active per token. That pair of numbers is the key to understanding how the two models relate — Flash is less a distilled or trimmed-down Pro than a separate architecture that cut active parameters to about a quarter in order to drive serving cost down structurally. The price follows exactly that ratio. On output, Flash is $0.28 per 1M tokens and Pro is $0.87, a gap of about 3.1x.
This is where a misunderstanding often creeps in. The 13B active figure describes compute, not memory footprint. If you are considering self-hosting, all 284B parameters still have to sit somewhere, and even squeezed to 4-bit that is in the 140GB range. Small active parameters do not mean "it runs on a small GPU"; they mean "it produces far more tokens on the same GPU." Blur that distinction and your self-hosting estimate comes apart entirely. The arithmetic on the local side is worked through as formulas in How Much VRAM to Run an LLM Locally.
Who Measured the Published Scores, and on What Harness
Here are the 0731 scores the changelog published. Terminal Bench 2.1 82.7, NL2Repo 54.2, Cybergym 76.7, DeepSWE 54.4, Toolathlon verified 70.3, Agent Last Exam 25.2, Automation Bench (Public) 25.1, DSBench-FullStack 68.7, DSBench-Hard 59.6.
These numbers come with conditions attached, and those conditions matter. The changelog spells out the measurement setup as "DeepSeek Harness minimal mode, max effort level, top_p 0.95, temperature 1.0." In other words, they are vendor self-measurements taken on the vendor's own harness at maximum reasoning effort. That is exactly the point people raised in the HN thread. Agentic benchmarks are extremely sensitive to scaffolding, and the same model moves by double digits when the harness changes. The moment you line these up against numbers another vendor published on its own harness and start assigning ranks, that table stops meaning anything.
What about independent measurement? Artificial Analysis scores V4 Flash 0731 at an Intelligence Index of 50 at maximum reasoning effort. On the same index, GPT-5.6 Sol is 59, Terra 55, and Luna 51. So on a composite intelligence indicator alone, Flash sits in roughly the same place as OpenAI's cheapest tier. On the coding side, third-party aggregations put Flash at 79.0% and Pro at 80.6% on SWE-bench Verified — but that is secondary material citing llm-stats-style aggregations, and I could not verify the original measurement conditions. Better not to take it at face value; measure it on your own tasks.
One independent measurement is especially practical. Artificial Analysis records that this model burned 210M tokens to complete the index, against a median of 62M across all models. It spends a great many thinking tokens before it produces an answer. That registers as a strength in benchmark scores and as output tokens on the invoice. We come back to it below.
The Real Line Item on the Price Sheet Is Not the Headline, It Is the Cache-Hit Price
Here is the per-1M-token price for each model according to the official pricing docs. The OpenAI side reflects the July 30 cut, and the cache-hit price is the published 90% discount applied to the input price.
| Model | Cache-hit input | Cache-miss input | Output | Output-to-input multiple |
|---|---|---|---|---|
| DeepSeek V4 Flash | $0.0028 | $0.14 | $0.28 | 2x |
| DeepSeek V4 Pro | $0.003625 | $0.435 | $0.87 | 2x |
| GPT-5.6 Luna | $0.02 | $0.20 | $1.20 | 6x |
| GPT-5.6 Terra | $0.20 | $2 | $12 | 6x |
| GPT-5.6 Sol | $0.50 | $5 | $30 | 6x |
The column worth staring at in this table is not the headline number, it is the rightmost one. DeepSeek charges 2x input for output, while the OpenAI family charges 6x. The shape of the price sheet itself is different.
And the leftmost column is more dramatic still. Flash's cache-hit input is $0.0028 per 1M tokens, one fiftieth of the cache-miss price. Compared with GPT-5.6 Luna's cache-hit price it is roughly 7x cheaper. One user in the HN thread reported spending 323M tokens across 3,467 API requests over 30 days and paying $4.55 — a number like that does not appear unless the workload has a very high cache-hit rate. A coding agent that repeatedly sends a long system prompt and a fixed codebase context is exactly that shape.
Two traps to watch. First, a cache discount rate is not an invoice reduction rate — if output already eats a large share of the cost, a 90% discount on the input side will not take 90% off the total. That calculation is worked through in detail in How to Actually Cut Your LLM API Bill. Second, DeepSeek's pricing doc pre-announces a peak and off-peak differential plan. The policy doubles the rate between 9am and noon and between 2pm and 6pm Beijing time, and the doc states that the effective date has not yet been officially announced. Those windows overlap the Korean business day, so you must build them into any estimate.
Recomputing in Cost per Capability
Let us run the actual arithmetic by putting the same workload on both models. After the cut, GPT-5.6 Luna and DeepSeek V4 Flash sit at essentially the same place on the Intelligence Index — 51 against 50 — which makes them a good pair for holding capability fixed and comparing only price.
Workload A — input-heavy (long-document summarization, RAG answers)
50,000 input tokens / 500 output tokens per request
Luna : 50,000 x 0.20 / 1e6 = 0.01000
+ 500 x 1.20 / 1e6 = 0.00060 -> 0.01060 dollars
V4 Flash : 50,000 x 0.14 / 1e6 = 0.00700
+ 500 x 0.28 / 1e6 = 0.00014 -> 0.00714 dollars
Flash is about 1.5x cheaper
Workload B — output-heavy (reasoning, coding agents)
2,000 input tokens / 10,000 output tokens per request (thinking tokens included)
Luna : 2,000 x 0.20 / 1e6 = 0.00040
+ 10,000 x 1.20 / 1e6 = 0.01200 -> 0.01240 dollars
V4 Flash : 2,000 x 0.14 / 1e6 = 0.00028
+ 10,000 x 0.28 / 1e6 = 0.00280 -> 0.00308 dollars
Flash is about 4.0x cheaper
Same two models, and the gap widens from 1.5x to 4x. Looking at headline input price alone gives you 0.14 against 0.20, a 30% difference, but the actual invoice difference is decided by the workload's input-output mix. A price sheet with a 2x output-to-input multiple gets more favorable as output grows longer, and one with a 6x multiple does the opposite.
Here the earlier observation comes back around. Flash is a model that spends a lot of thinking tokens, which means it naturally drifts toward workload B. When a price sheet with cheap output meets a model that produces a lot of output, the two offset each other, so the conclusion that cheap output means you can let it think as much as it likes is dangerous without your own measurements. Benchmark scores measured with reasoning effort pinned at max and the cost at the effort level you would actually run in production are two different stories. How far the scores drop when you lower the effort is something the vendor has not published, and I could not verify it either.
Flash Is a Tier Name, Not a Latency Story
One misunderstanding the name creates is worth heading off. Other vendors' Flash tiers generally mean "fast response," but DeepSeek's Flash is not a latency grade — it is the name of a model family with small active parameters. Whether responses are actually fast is a completely separate question, and one that varies enormously by provider.
Look at Artificial Analysis's per-provider aggregation and you find output speeds scattered from the low 100s of tokens per second into the high 200s even though the same weights are being served, with very large provider-to-provider variance in time to first token as well. A separate benchmark reports a median throughput of 164.7 tokens per second and a median TTFT of 1,924 milliseconds. In reasoning mode, another point matters: "first token" and "first answer token" are not the same thing — thinking tokens stream first, so the delay the user actually feels before seeing an answer is far longer than TTFT. If you plan to put this model behind a real-time conversational UI, measure the time to the first answer token, not TTFT.
One more item. The official API documents a concurrent request limit of 2500 for Flash and 500 for Pro. That is the practical ceiling when you push batch-style work through it, so it belongs in your capacity planning.
Routing Rules — And What We Still Do Not Know
Compressing the numbers so far into decision rules gives this.
- Traffic with long outputs and a large repeated prefix has a clear reason to come here. Code review, bulk classification, log summarization, and agents for internal tooling all fall in this bucket. It is the one regime where the cache-hit price and the output price work in your favor at the same time.
- Traffic with long inputs and short outputs narrows the gap to around 1.5x. If you are already locked in with another vendor and migration has a cost, the case for moving is weak.
- Traffic where the quality ceiling dominates the outcome should not be moved. On SWE-bench Pro and long-horizon agent tasks the gap to the top-tier models is still real, and in workloads where the cost of a single failure vastly exceeds the token bill, comparing unit prices is the wrong frame to begin with.
- Traffic under data governance constraints needs a separate judgment regardless of price. The HN thread returned repeatedly to concerns about where the codebase ends up, and to the point that a zero-retention policy is not offered to individual subscribers. Because the weights are published under the MIT license, self-hosting is an available option, and that is this model's real differentiator. The hardware cost of standing up 284B, however, comes right back at you.
Let me also write down clearly what I could not verify. The score deltas relative to the preview (Terminal Bench 56.9 to 82.7 and so on) do not come from a single table in the official changelog; the community stitched together announced figures from two points in time, and I could not confirm that both values came from the same harness. The score and cost curve at lower reasoning effort, the real effective length of the 1M context (whether performance holds all the way to the last token), and the effective date of the peak pricing plan are all unpublished as well. And an agent score measured on a vendor's own harness is, until that harness is published, not a comparable number but a vendor claim.
Closing — Leaderboards Flip in a Month, but the Shape of a Price Sheet Lasts
The information from this release that will still matter later is not the score 82.7, it is the structure of the price sheet. A price sheet with a 2x output-to-input multiple and one with a 6x multiple pull in different workloads even at identical capability. And the line item where the cache-hit price is one fiftieth of the cache-miss price splits the invoices of teams that can pin a prefix and teams that cannot by nearly an order of magnitude.
So instead of rereading the leaderboard, open your own logs. The median input and output tokens per request, the prefix reuse rate, and the cost of a single failure — with those three numbers, which model to route to falls out of the arithmetic. A benchmark is just one of the inputs to that calculation, and even then it is usable only after you have confirmed who measured it and on what harness.