DeepSeek이 Flash 모델을 밤사이 교체했습니다. 새 설정을 가져와 캐시 계산을 했습니다.

10월 17일, DeepSeek은 deepseek-flash API 엔드포인트의 기반 모델을 교체했습니다. 이름과 가격은 동일하지만 변경 로그가 없었기 때문에 확인해야 했고 — 만약 사용자의 에이전트가 금요일에 deepseek-flash를 호출하고 토요일에 다시 호출했다면, 두 개의 다른 체크포인트를 사용한 것이며 아무도 이와 관련하여 이메일을 보내지 않았습니다.

새로운 체크포인트는 Hugging Face의 MIT 아래 DeepSeek-V4.1-Flash-1017이며, 오늘 아침 Hacker News에서 가장 큰 화제였습니다(제가 확인했을 때 903점). DeepSeek은 이를 "사소한 업데이트"라고 부릅니다. 하지만 자체 벤치마크 테이블은 이 수식어에 동의하지 않습니다: 보고된 11개 벤치마크 모두 상승했으며, Terminal-Bench는 4.0에서 11.1점으로, ProgramBench는 8.8점 상승했습니다. 이는 DeepSeek이 DeepSeek 자체 환경(harnesses)으로 측정한 수치이며, 저는 제 책상에서 DeepSWE를 재현할 수 없습니다. 하지만 제가 할 수 있는 것은 주요 아티팩트 — 실제 config.json과 실제 파일 크기 — 를 가져와 이야기의 산술적인 부분, 즉 KV 캐시 논문인 "Pushing the Limits of KV Cache Compression"을 확인하는 것입니다. 이 과정에서 토큰당 890바이트라는 캐시 수치가 회자되고 있습니다. 그래서 저는 설정(config)으로부터 계산을 수행했습니다.

설정이 실제로 말하는 것

curl -s https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash-1017/raw/main/config.json

중요한 필드는 다음과 같습니다:

num_hidden_layers      40
len(compress_ratios)   43        <- 레이어 개수보다 세 개 더 많음
compress_ratios        {0: 5 layers, 2: 18 layers, 1: 20 layers}
...

그리고 누군가의 요약이 아닌 Hugging Face의 블롭 크기에서 합산한 가중치(weights)는 다음과 같습니다:

48 safetensors shards
510,296,708,312 bytes total = 510.3 GB (475.3 GiB)
downloads at fetch time: 10,233   likes: 1,216   created: 2026-10-17T02:40Z

여기에는 세 가지 요소가 실제 작업을 수행하고 있습니다. 공유되는 KV 헤드 하나. 128 토큰의 슬라이딩 윈도우(sliding window)로, 이는 컨텍스트 길이가 아무리 길어져도 창형 레이어(windowed layer)의 캐시가 128 위치 이후로는 증가하지 않음을 의미합니다. 그리고 장거리 KV를 공급하는 네 개의 소스 레이어와 그 위에 추가된 레이어별 압축 비율입니다.

캐시 계산의 수학적 원리 (The cache math, with the assumptions on the table)

여기에 전체 실험 결과가 있습니다. 아래 모든 숫자는 명시된 가정 하에서의 상한선(bound)입니다. 왜냐하면 설정 파일이 제공하는 것은 모델의 기하학적 구조일 뿐, 실제 서비스 스택의 정확한 레이아웃을 알려주지는 않기 때문입니다:

L = 43            # config에서 가져온 len(compress_ratios)
head_dim = 512

...

[A] 모든 레이어, 512차원 잠재 공간 (latent), bf16:  44,032 bytes/token -> 1M 토큰에서 46.2 GB
[B] 일반 MHA(vanilla MHA), 동일 너비:           880,640 bytes/token -> 1M 토큰에서 923.4 GB
[C] 소스 레이어 4개만 사용, 압축됨:   2,048 bytes/token -> 1M 토큰에서 2.15 GB
...

순환하는(circulating) 890이라는 수치는 제가 가장 공격적으로 계산한 상한선보다도 낮습니다. 이는 bf16 이하의 양자화(quantization)와 희소 인덱스(index_topk: 512 — 모델이 저장된 모든 것을 보는 것이 아니라 선택된 하위 집합에만 주의를 기울임)가 나머지 부분을 담당하고 있음을 의미합니다. 좋습니다. 그럴듯합니다. 하지만 커버리지에서 아무도 언급하지 않은 부분이 있습니다. 바로 토큰당 바이트(bytes per token)가 이 아키텍처에서는 상수(constant)가 아니며, 이를 상수로 인용하는 것은 범주적 오류(category error)라는 점입니다. 윈도우 크기 128의 레이어는 프롬프트 길이가 8,000 토큰이든 백만 토큰이든 상관없이 128개의 위치(positions)를 비용으로 발생시킵니다. 상각 계산을 해보세요:

window-only effective bytes/token at ctx=8,192:     688.0
window-only effective bytes/token at ctx=131,072:    43.0
window-only effective bytes/token at ctx=1,048,576:   5.4

동일한 모델, 동일한 코드임에도 불구하고 측정하는 길이에 따라

1M uncached input: $0.15 | 1M output: $0.60 | 1M cached input: $0.003
캐시된 입력은 캐시되지 않은 입력보다 50배 저렴합니다.

캐시 읽기에 대한 50% 할인은 공급업체가 가격을 통해 자신의 캐시가 실제로 제공하기에 매우 저렴하다는 것을 말해주는 것입니다. 이는 보도 자료가 아니라, 요금표에 나타난 KV 압축 작업의 결과입니다. DeepSeek 자체의 DeepSWE 차트(The Decoder의 요약본을 통해)는 새로운 모델이 최고 설정에서 태스크당 0.20달러 미만인 반면, 같은 차트상의 경쟁사들은 2~10달러를 책정하고 있어 10배에서 50배에 달합니다. 공급업체의 차트, 공급업체의 하네스(harness)를 사용하되, 그에 맞게 대처해야 합니다. 하지만 방향성은 설정과 일치하며, 이 설정은 공개되어 있습니다.

이번 릴리스에는 또한 Search and Fetch API가 포함되었으며, 성공적인 요청 1,000건당 0.75달러입니다. 이는 DeepSeek Harness, Claude Code 및 Codex의 서버 측 도구를 통해 무료로 제공되며, 10월 31일 16:00 UTC에 청구서 발행이 시작될 때까지 유효합니다. DeepSeek은 더 이상 단순히 모델을 판매하는 것이 아니라, 에이전트의 시력을 판매하고 있습니다.

제가 실제로 마음에 들지 않는 부분

위의 어떤 것도 문제가 아닙니다. 문제는 제공 메커니즘입니다: 변경되지 않은 모델 이름 아래에서 조용히 교체되었다는 것입니다. 지난주에 deepseek-flash를 대상으로 실행했던 모든 평가는 이제 더 이상 트래픽을 처리하지 않는 체크포인트를 설명합니다. DeepSeek은 가중치와 날짜가 찍힌 체크포인트 이름(...-1017)을 저장소 이름에 명시적으로 게시했기 때문에, 고정된 자체 호스팅 경로는 완전히 재현 가능합니다. 문제가 된 것은 편리한 경로, 즉 API 별칭(alias)이 당신 아래로 이동했다는 것입니다. 데이터베이스와 기본 이미지의 버전을 고정하더라도 모델을 공급업체의 별칭에 맡겨두면, 이번 릴리스가 그 정책으로 인해 발생하는 비용입니다: 더 나쁜 모델이 아니라—모든 공개된 측정 기준에 따르면 오히려 더 좋은 모델이지만—단지 테스트했던 것과는 다른 모델일 뿐입니다.

체크포인트를 고정하세요. 설정을 읽으세요. 산술 계산이 발표입니다.