DeepSeek V4.1 flash 고고학

DeepSeek를 분석하면서 아래 궁금증들을 해소해보겠습니다

• V4-Lite, V4-Pro, V4-Flash-0731, V4-Pro-0813 등 많은데 뭐가 살아있지
• 이름이 flash인데 전 세대 플래그십인 pro를 이긴다는 뜻은?
• CED, CSA2, Engram, DSpark, SWA Bounded Replay가 머지
• 552B인데 활성 파라미터가 8B, 16B 두 개로 적혀있는 이유가 머지
• kv캐시 890바이트가 왜 헤드라인?
• 같은 모델인데 하네스 바꾸면 점수가 9점이 갈린다 그럼 벤치마크를 어떻게 읽어야하지
• 채팅 탬플릿이 없다는데 그러면 어떻게 부르지

이런 질문들을 알아보자

DeepSeek 가문 #

정체성 - 비용 구조를 아키텍처로 푸는 가문 #

딥시키는 중국 항저우 하이플라이어 계열에서 출발한 연구소다

2024년에 V2 MLA, 2024년 말 V3 대규모 MoE, 2025년 R1의 추론 공개, V3.2의 DSA로 이어지며 오픈웨이트 진영의 아키텍처 레퍼런스 역할을 해왔다

다른 가문과 구분되는 지점은 문제를 정의하는 방식이다.

Qwen이 라인업의 폭으로 GLM이 남의 하네스를 얹히는 배포 전략으로 승부한다면, DeepSeek는 매 세대마다 지금 추론 비용의 병목이 정확히 어디인가 하나 특정하고 그것만 집요하게 깎는다.

V2   : KV 캐시가 크다        → MLA (저차원 잠재 공간으로 KV 압축)
V3   : 파라미터당 비용이 높다 → 대규모 세분화 MoE + 보조손실 없는 로드밸런싱
V3.2 : 어텐션이 제곱으로 커짐     → DSA (Lightning Indexer로 top-k 선택)
V4   : 1M 컨텍스트가 비싸다  → CSA + HCA (V3.2 대비 FLOPs 27%, KV 10%)
V4.1 : 에이전트는 입력 헤비다 → CED + CSA2 + FP4 KV (KV 890 bytes/token)

이번 V4.1-Flash 기술 보고서 제목은 Pushing the Limits of KV Cache Compression - 지능이 아니라 캐시를 제목에 걸었다.

이것이 딥시크 기술의 성격을 보여주는 것이다

KV 캐시를 최적화하는 이유 #

장기 지평 에이전트가 서빙 워크로드의 성격을 바꿔놨기 때문이다.

일반적인 챗봇같은 서비스들은 짧게 묻고 길게 답하는 성향이 강하다 그런데 코딩에이전트는 저장소를 전체 탐색하고 도구도 호출하고 결과를 다시 읽고 또 호출한다 매 턴마다 지금까지의 전체 궤적을 다시 프리필하게 된다

출력은 몇백 토큰이고 입력이 수십만 토큰인 상태가 수백 턴 반복되는 것이다

이런 워크로드에서 실제 비용은 새 군데에 몰린다

① 프리필 계산       매 턴 전체 컨텍스트를 다시 밀어넣는 비용
② HBM (GPU 메모리)  KV 캐시가 크면 동시 사용자 수가 줄어든다
③ SSD 스토리지      캐시 히트를 위해 KV를 디스크에 얹어두는 비용

DeepSeek이 X 발표에서 직접 말한 문장이 있는데 "캐시히트 과금이 에이전트 비용의 큰 부분을 차지하는 경우가 많다, 캐시를 압축하면 그 비용이 크게 줄어든다" V4.1-Flash의 모든 아키텍처 선택이 이 세 항목을 겨냥한것이다

오픈 정책 - MIT #

Qwen은 Apache 2.0, Kimi는 Modified MIT, GLM은 플래그십에 자체 라이센스를 붙이기 시작했지만 딥시크는 아직 순수 MIT로 베이스 모델까지 열고 매출 게이트도 없고 ui표기 의무도없고 허용 사용 조항도 없다

V4.1-Flash 공개 시점기준 공개와 동시에 api 모델 목록이 정리됐다 api안바꿔도됨

공식 모델 ID  →  deepseek-flash        ← 앞으로 이 이름을 쓴다

폐지 (별칭만 남음, V4.1-Flash로 라우팅)
  deepseek-v4-flash
  deepseek-v4-flash-vision-exp

유예 후 라우팅
  deepseek-v4-pro
  → 2026년 9월 14일 베이징 시간 12:00 (UTC 04:00, 한국시간 13:00) 까지만 유지
  → 이후 전 트래픽이 V4.1-Flash 가격으로 V4.1-Flash에 라우팅
  → V4.1-Pro가 나올 때까지의 임시 다리

v4 pro를 쓰고있었다면 가격은 크게 내려간다 오프피크 기준 pro의 $0.022 /$0.66 / $1.98이 Flash의$0.003 / $0.15 /$0.60이 되므로 각각 약 86% / 77% / 70% 인하다.

근데 이건 할인이 아니라 마이그레이션이다 베이스가 새로 학습된 다른 아키텍처의 모델이므로 프롬프트 반응이나 도구 호출 패턴, 출력 스타일등이 달라질 수 있다 순수 능력이 올라가더라도 좋다 9월 14일 전에 프로덕션 트래픽을 테스트해보는게 맞다

라인업 #

파라미터 수, 메모리 #

552B  ← 모델 카드 본문의 "backbone parameters"
196B  ← Engram 조건부 메모리 모듈 (별도 계상)
485B  ← 허깅페이스 safetensors 집계 표시
475GiB ← 실제 체크포인트 용량 (FP8 + FP4 전문가 혼합, 48개 샤드)

백본, Engram, 비전 인코더를 각각 세느냐 마느냐와 따라 저장 정밀도가 섞여서 나는 차이가 있음을 알고있자

하드웨어를 사이징할때는 어느 논문 숫자도 아니고 체크포인트할 파일용량을 봐야한다.

Flash인데 Pro보다 세다고? #

이름 때문에 오해하기 쉬운지점인데 V4.1-Flash는 V4.1 계열의 저비용 티어이면서 동시에 전 세대 플래그십 V4-Pro를 넘어선다

베이스 모델을 비교해보면

세계지식과 코딩에서 V4-Pro-Base를 따라잡거나 총 파라미터는 1/3 활성은 1/4

다만 정직하게 갈리는 측은 암기형 사실 지식 SimpleQA 42.3 vs 55.2, 장문 이해 LongBench-V2 45.2 vs 51.5 에서는 여전히 1.6T Pro가 앞선다 파라미터를 줄이면 먼저 깎이는게 이쪽이라는 익숙한 패턴

V4.1-Pro가 아직 안나왔다는 점도 같이 봐야하는데 DeepSeek 스스로 V4.1-Flash를 새 아키텍처 패밀리의 가장 작은 모델이자 더 큰 모델로 스케일하도록 설계된것이라고 표현했다 지금 보는건 새 아키텍처의 최소 사이즈다.

Architecture #

CED (Casual Encoder-Decoder) 프리필을 반으로 #

일반 디코더 트랜스포머는 모든 레이어가 자기 kv를 계산한다, 40개인 레이어면 프롬프트 토큰 하나가 40번 처리되고 40개의 레이어분의 kv가 쌓이게 된다

그런데 에이전트 워크로드에서 프롬프트는 주로 읽히기만 한다 저장소 코드 30만 토큰을 넣었을때 그 토큰이 나중에 생성될 토큰만큼의 깊은 처리를 필요로 하는가?

해법 #

40개의 레이어를 20층의 인과 인코더 20층의 디코더로 쪼갠다 그리고 디코더는 자기 전역 kv를 계산하지 않는다 대신 레이어별로 프로젝션 가중치와 인코더의 최종 은닉 상태 하나로부터 디코더 20개 레이어분의 전역 kv를 전부 뽑아낸다

                    ┌─ 프롬프트 토큰은 여기서 멈춘다
                    ↓
입력 → [ 인코더 20층 ] ─ 최종 은닉 상태
                              │
                              ├→ 디코더 1층의 전역 KV (프로젝션)
                              ├→ 디코더 2층의 전역 KV (프로젝션)
                              ├→ ...
                              └→ 디코더 20층의 전역 KV (프로젝션)

              [ 디코더 20층 ] → 출력 생성

비유하면 두꺼운 자료를 스무명이 각자 처음부터 정독하는 대신 앞의 스무명이 한번읽어서 만든 정리본 하나로 뒤의 스무명이 각자 방식으로 해석하여 쓰는것, 원본을 스무번 더 읽는대신 정리본을 스무가지로 변환한다

이 발상의 출처는 YOCO(You Only Cache Once)계열의 연구로 딥시크가 처음 만든건아니고 이걸 프론티어급 MoE에 실제로 태운 사례인것이다.

효과 - 활성 파리머터가 두개인 이유 #

프리필 (입력 처리)  : 인코더 20층만 통과  → 토큰당 활성 8B
디코드 (출력 생성)  : 인코더 + 디코더 전체 → 토큰당 활성 16B

모델 카드에 활성 파라미터가 8B / 16B로 두개 적힌게 이 구조 때문이다 프리필 계산이 사실상 절반이고 이게 입력 헤비 워크로드에서 그대로 비용 절감으로 이어진다.

SWA Bounder Replay - SSD를 안쓴다 #

CED로 전역 kv는 인코더에서 뽑아냈는데 슬라이딩 윈도우 어텐션 SWA는 여전히 모든 레이어에서 돌아간다. 윈도우는 128토큰이다

문제는 캐시미스가 났을땐데, 디코더의 swa상태를 복원하려면 원래는 그걸 어딘가에 저장해뒀어야한다 그래서 기존에는 SSD에 얹었었다.

SWA (Sliding Window Attention): 전체 문맥 대신 최근 N개 토큰만 보는 어텐션이다. 전역 어텐션이 먼 곳을 담당하고 SWA가 바로 앞의 지역 문맥을 담당하는 분업 구조에서 쓰인다. 여기서는 윈도우가 128토큰이다.

해법 #

저장하지 않고 다시 계산하는 것이다 윈도우가 128토큰이므로 마지막 128개 토큰만 리플레이하면 SWA 상태가 정확히 복원된다

기존:  SWA KV를 SSD에 영속 저장  →  스토리지 비용 + 전송 지연
V4.1:  캐시 미스 시 마지막 128 토큰만 재연산
       → 재연산량이 "레이어 수 × 윈도우 크기"가 아니라 128 토큰으로 고정

배포 레벨에서는 이렇게 나뉜다

SWA KV   : 호스트 DRAM의 10%를 떼서 만든 분산 풀, TTL 수 분
전역 KV  : 72시간 보장 수명

결과적으로 SSD에 영속시키는 kv용량이 V4-Flash의 약 1/8이 되는것이다 앞서 말한 세 병목중 SSD스토리지 병목에 대한 해법인 것

CSA2 - 레이어 축이 캐시를 공유한다. #

V4는 CSA, HCA를 섞어서 사용했다 V4.1-Flash는 순수 CSA2 하나로 가면서 압축 방향 시퀀스 축이 아니라 레이어 축으로 돌린것이다

CSA: Compressed Sparse Attention으로 kv 캐시를 먼저 압축후 질문이나현재 상황에 필요한 핵심 토큰만 선택(sparse)해서 본다 중요한 장기 기억이나 관련성 높은 특정 부위를 골라내어 집중하는 구조로 불필요한 연산 비용을 줄이며 정확도가 유지된다

HCA: Heavily Compressed Attention으로 일정 간격(ex. 128 tokens)마다 하나의 kv만 만드는 식으로 매우 강하게 압축한다. 상위 k개를 골라내지 않고 압축된 전체 history 데이터에 대해 dense 어텐션을 수행한다. 세부적인 지점보다는 거시적인 전체흐름이나 문맥의 대의를 넓고 저렴하게 훑어본다

각 어텐션 레이어에 세 가지 모드중 하나가 정적으로 배정된다, 학스뺃정해지고 추론때는 바뀌지 않는다.

모든 레이어는 자기 main Q와 자기 SWA KV는 그대로 갖게 된다. 공유되는 것은 kv와 인덱스 선택 뿐

비유 하면 조사팀이 자료 더미에서 후보 20건을 추렸을때

• Full: 자료 더미를 새로 만들고 후보도 새로 추린다
• Reindex: 자료 더미는 그대로 쓰되 내 관심사 기준으로는 이 20건이다 라고 다시 추린다
• Reuse: 자료 더미도 후보 20건도 그대로 받아서 각자 해석만 한다.

실제 배치

인코더 CSA2 레이어 18개
  압축비 2, 6개씩 3개 그룹
  각 그룹 = Full 1 + Reuse 5

디코더 레이어 20개
  압축비 1, 4개씩 5개 그룹
  1번 그룹 = Full 1 + Reuse 3
  2~5번 그룹 = Reindex 1 + Reuse 3

인덱서를 실제로 새로 돌리는 레이어는 인코더 3개, 디코더 5개뿐이다 나머지는 남이 고른걸 쓴다

GLM-5.2의 IndexShare와 비교해보면 발상이 같고 정교함이 다른데 IndexShare는 full, shared, shared, shared 두 종류였다, CSA2는 여기에 reindex라는 중간 단계를 넣은거고 메모리는 공유하되 무엇을 주목할지는 각자 정한다 라는 선택지가 생긴것이다. 이게 공유의 품질 손실을 줄인다.

TOP-512 #

희소 어텐션이 고르는 개수는 상위 512개로 GLM/DeepSeek V3.2 계열의 2,048 보다 훨신 공격적이다 그만큼 인덱서의 선별 품질이 중요하다.

Hierarchical Sparse Indexer - 인덱서의 제곱항을 끊기 #

남아있던 문제 #

희소 어텐션에서 본 어텐션은 O(Lxk)로 선형이 된다, 근데 인덱서는 여전히 전체를 훑어야하므로 O(L²)이다. 컨텍스트가 1M이 되면 이게 다시 문제가 되는데

해법 #

디코더에서 첫 full 레이어가 후보 풀을 만들어주고 이후 reindex 레이어들이 그 풀 안에서만 점수를 매긴다

첫 Full 레이어
  인과적으로 볼 수 있는 전 구간을 채점 (여기만 O(L²))
  → 후보 풀 구성: 8개 위치씩 묶은 블록 2,048개 = 최대 16,384개 위치

이후 Reindex 레이어들
  16,384개 안에서만 채점 (컨텍스트 길이와 무관하게 고정)
  → 여기서 Top-512를 고른다

깊은 레이어의 인덱싱 비용이 컨텍스트 길이와 독립적으로 상한이 걸린다 1M이든 100K든 Reindex layer가 보이는 후보는 16,384개이다

이 구조가 만들어내는 수치가 이거다, 컨텍스트가 4K에서 1M으로 250배 늘어날 때 단일 토큰 디코드는 FLOPs는 1/4가 증가한다.

FP4 KV 캐시 #

main KV 캐시를 **E2M1 포맷(4비트)**로 양자화하고 16채널마다 E4M3 스케일을 하나 붙인다 NVIDIA의 NVFP4 방식을 따르되 전역 스케일은 뺀 방식

E2M1 / E4M3: 부동소수점을 지수 Exponent, 가수 Mantissa 비트로 표기한것 E2M1은 지수 2비트 가수 1비트 부호 1비트해서 총 4비트다. 값의 정밀도가 매우낮으므로 16개 채널을 묶어 그 그룹의 배율(스케일)을 별도로 8비트값 E4M3으로 지정해 표현범위를 보완한다.

중요한점은 이걸 사후학습 단계의 양자화 인지 학습 QAT로 도입했다는 것이다 다 학습한 모델을 나중에 4비트로 눌러버리는게 아니라 학습중에 모델이 4비트 캐시에 적응하게 만들었다 V4의 FP8 캐시 대비 저장량의 절반이 된다.

종합 - 890 bytes/token #

앞의 것들이 다 합쳐져 이런 결과가 나온것

전역 KV 캐시: 토큰당 890 바이트

  vs DeepSeek-V4-Flash  약 1/4
  vs DeepSeek-V1        약 1/437

그리고 배포 레벨의 두 축이 이렇게 정리된다

HBM (GPU 메모리) 소요  : 전 세대의 1/4
SSD 영속 스토리지 소요 : 전 세대의 1/8

1M tokens를 전부 채워도 전역 kv가 890MB수준이라는거임 미친 레전드다.

이게 왜 쩌냐면 하면 같이 gpu로 받을 수 있는 동시 세션수가 4배가 되기 때문이고 그건 토큰당 원가로 직결된다

Single-Pass mHC #

**mHC(Manifold-Constrainted Hyper-Connections)**는 v4에 이미 들어간건데

잔차 연결을 여러 갈래로 확장하되 매니폴드 제약으로 안정성을 유지하는 기법이다.

신호 증폭을 2배 이하로 묶어서 1.6T MoE를 6.7% 오버헤드로 안정 학습시킨 물건이다

V4.1-Flash의 Single-Pass mHC는 여기서 입력 혼합 계수를 한 블록 앞으로 시프트한다. 이렇게 하면ㅇ 여러 연산을 하나로 합친 Mega-mHC 커널로 처리할 수 있게 되고 활성화 메모리 트래픽이 절반이 된다

계산 결과를 바꾸는 최적화가 아니라 같은 계산 커널을 하나로 묶을 수 있게 순서를 재배열한 것이다.

Engram - 196B짜리 조건부 메모리 #

레이어 1과 14에 붙는 별도 모듈로 파라미터 196B를 갖고있고 토큰 기반 룩업으로 희소하게 접근하는 방식이다.

MoE의 라우팅이 "어느 전문가에게 계산시킬까" 라면 Engram은 "이토큰에 대해 어떤 저장된 지식을 꺼낼까" 캐시같은 거다. 계산이 아니라 조회

주의할점: Engram은 원래 별도 연구 논문이였고 V4시점에는 실제로 탑재되지 않은 채 온라인에 V4에 붙여 얘기되던 항목이다 V4.1-Flash에서 실제로 탑재되었다 V4 관련 자료를 읽을 때는 이구분을 해야한다

파라미터 회계상으로도 이게 552B백본과 별개로 계산되기 때문에, 앞서 본 숫자 혼선의 주요 원인이 된다.

Dspark - 투기적 디코딩 #

반자기회귀(semi-autogressive) 드래프트 생성 + 신뢰도 스케줄 검증구조다 사전학습 이후에 백본을 동결한 채로 따로 학습시킨다

• 투기적 디코딩: 가벼운 드랲터가 여러 토큰을 미리 제안하고 본 모델이 한 번의 포워드 패스로 그것들을 검증하는 방식으로 가중치를 한 번 읽는 비용을 토큰 1개를 만들때나다 여러개를 검증할때나 거의 같으므로 남는 계산 자원으로 여러 토큰을 확정하는 기법
• 반자기회귀 드래프트: 드래프터가 토큰을 하나씩 순차생성하는 대신 여러개를 한 번에 내놓는다 드래프트 자체의 지연시간이 줄어든다
• 신뢰도 스케줄 검증: 드래프터가 자신 있는 구간은 길게, 자신 없는 구간은 짧게 제안하도록 조절한다 무조건 n개를 제안하고 대부분 거절 당하는 낭비를 줄인다

? 커뮤니티는 GGUF 저장소 표기 기준으로 공개 체크포인트는 Dspark n = 3

MoE 구성 #

MoE 레이어당
  공유 전문가 1개
  라우팅 전문가 384개
  토큰당 활성 라우팅 전문가 6개

공유 전문가 1개 + 세분화된 라우팅 전문가 다수라는 딥시크 v3이후에 일관된 패턴으로 384개중 6개라면 1.6%수준의 매우 희소한 라우팅이다

Qwen3.5가 512개중 10 + 공유 1, GLM-5.2가 256개중 8 + 공유 1 이다. 전문가를 잘개 쪼개고 공유전문가를 하나로 둔다는 지점은 같다.

멀티모달 얼리퓨전 #

DeepSeek-ViT (밑바닥부터 학습)
  2D-RoPE
  3×3 픽셀 언셔플 다운샘플링
      ↓
2층 MLP 프로젝터
      ↓
시각 임베딩 → 텍스트 임베딩과 함께 처리

핵심은 언어모델이 사전학습의 시작부터 이미지 모델을 함께 처리한다 이고 텍스트 모델을 다 만들어놓고 나중이 비전 어댑터를 붙이는 방식인 레이트 퓨전이 아닌 처음부터 같은 표현 공간에서 둘을 배우는 방식이다

이 덕분에 별도 vision모델이 필요없고 실제로 이번 릴리즈에서 deepseek-v4-flash-vision-exp가 폐지됏다

베이스 모델의 멀티모달 수치는 이렇다.

MMMU-Pro (4-shot)     56.5
CVBench (4-shot)      77.9
DocVQA (LLM-Judge)    95.6
RefCOCO-avg (0-shot)  86.0

문서 이해 DocVQA 95.6, 공간 지시 (RefCOCO 86.0)이 특히 높다 스크린샷을 읽고 좌표를 짚는 능력이므로 컴퓨터 사용 에이전트의 전제 조건에 해당한다.

사전 학습 #

코퍼스     45T 멀티모달 토큰 (텍스트:멀티모달 = 7:1)
희소 어텐션 시퀀스 길이 64K에서 밑바닥부터 학습
           ★ 밀집 워밍업 없음
컨텍스트 확장 34T 토큰 지점에서 1M으로

밀집 워밍업 없음이 눈여겨볼 지점 glm-5는 dsa를 도입할때 밀집 베이스에서 계속 사전학습하는 2단계 전략을 썼는데

처음부터 희소로 학습하는 비용이 천문학적이라는 이유였다 딥시크는 이번에 그걸 처음부터 희소로 했다.

사후학습 #

알고리즘 변경은 없었다 모델 카드에 사후학습 레시피는 표준적인 SFT >> RL >> OPD(온폴리시 증류) 패러다임을 알고리즘 수정없이 따르고 실질적인 변화는 전부 데이터 파이프라인 이라고 햇다

바뀐거 세 가지:

1. 검증 가능한 에이전트 과제 환경의 대규모 자동합성과 데이터 과제 롤아웃을 점진적으로 스케일링
2. 이중 스캐폴드 변환에서의 RL, Claude Code, Codex, OpenCode, Pi, mini-SWE, DeepSeek Hanress -> 한 하네스에 맞추지 않고 여러 하네스에서 동시 학습
3. 40개 이상의 교사 모델로부터 온폴리시 증류

OPD: 학생 모델이 스스로 생성한 궤적 위에서 교사 모델이 확률 분포를 맞춰가는 방식 교사가 만든 데이터를 그냥 흉내내는 오프폴리시 증류와 달리 학생이 실제로 도달하는 상태 분포에서 교정이 일어나는 분포 이동 문제가 작다.

GLM5.3은 코딩에이전트 벤치마크 전부 클로드코드 하네스 하나에서 측정했고 딥시크는 여러 하네스에서 rl을 돌렸다.

하네스 #

딥시크가 이 같은 모델을 8개의 스캐폴드에서 돌린 결과를 통째로 귱개했다.

조건: DeepSWE v1.1은 과제당 N=8, Terminal Bench 2.1은 N = 3, 리눅스 컨테이터, tempature=1.0, top_p=0.95, 1M context, agent당 max step 500, Terminal-Bench 2.1은 네트워크 접근 차단

1. 최고 점수는 가벼운 하네스에서 나왔다. #

DeepSWE 74.2는 mini-SWE, Terminal-Bench 90.7은 DSH Minimal로 둘다 도구가 적은 미니멀 계열이다

DSH Minimal은 딥시크 하네스 dsh의 프리셋으로 영속 bash셸 하나와 str_replace 에디터 하나만 주고 시스템 프롬프트는 문장 하나 You are a helpful software engineer assistant. 에이전트는 자기가 dsh안에서 돌고잇다는 것조차 모름
Standard는 파일 편집, 셸, 파일 웹 검색, 스킬, 플랜, 목표, 서브에이전트, 워크플로 전부 갖춘 풀세트로 PTC, Creator는 다른 과제프로파일에만 맞춘 추가 프리셋이다.

2. 도구를 많이 주면 오히려 안좋아진다. #

DSH Minimal 72.6 -> Standard 70.5 -> PTC 67.6으로 내려간다. 도구가 늘수록 첫 턴에 노출되는 스키마와 프롬프트가 길어지고 선택지가 늘어나면서 능력선택이 덜 예측가능해진다는게 커뮤니티의 관찰

ㅓ뮤니티에션 이걸 GA DeepSeek V4가 Minimal에 과적합됐다라고 요약하는데 더 정확한 서술은 v4계열의 첫 턴의 도구 프롬프트 환경이 유난히 민감하다는 쪽 그리고 공개된 코드에이전트평가가 DSH Minimal에서측정됐다는 사실이 이 관찰과 맞물림

3. 그래도 남의 하네스에서도 잘나옴 #

claude code에서 69.8/88.0 이면 최고치와 그렇게 차이나는건 아니라 이중 스캐폴드 rl을 돌린 효과로 볼만한 지점

실무 원칙: 모델 이름만 보고 비교하는 벤치마크는 의미가 없으니 모델과 하네스 설정을 함게 기록하자 도구 접근, 권한, 컨테긋트 구성, 에이전트 루프가 전부 모델이 과제를 통과하는 경로를 바꾼다

벤치마크 #

최대 사고 예산 기준 프론티어 비교 #

resoning_effor=100, temperature=1.0, top_p=0.95 기준으로 굵은값이 그 행의 1위