Test-Time Scaling(TTS) 조건별 정확도·지연시간 비교

그림. Test-Time Scaling은 품질·지연·토큰·비용을 같은 문제 집합에서 함께 봐야 합니다.

reader_decision: TTS 사용 여부를 정확도 하나로 결정하지 않고, 같은 문제 집합의 품질·문제당 지연·토큰·비용과 변동성을 함께 보고 정합니다.

이 글에서 말하는 TTS의 범위
추론 시점에 계산을 더 쓰는 방법은 하나가 아닙니다. 아래 결과는 Apple M4 Max에서 실행한 speculative decoding 계열의 관측이며, 모든 Test-Time Scaling 방법의 일반 법칙이 아닙니다. 속도·메모리와 정답 품질을 서로 다른 증거로 분리해 읽습니다.

더 빨리 생성됐다는 말만으로는 부족합니다

추론 계산을 늘리면 한 문제를 더 오래 생각하거나 여러 후보를 비교할 수 있습니다. 반대로 draft 모델이 다음 토큰을 제안하고 target 모델이 검증하는 speculative decoding은 같은 답을 더 적은 target 호출로 만들 가능성이 있습니다. 두 경우 모두 “빨라졌다”와 “더 정확해졌다”는 별도 주장입니다. 실제 선택에는 같은 문제 집합, 같은 입력, end-to-end 시간, 출력 토큰, 비용, 실패와 변동성이 필요합니다.

판단 축	반드시 같은 조건으로 둘 것	이번 기록에서 확인한 값
품질	같은 prompt·판정 기준·temperature	DFlash 1/2 answer accuracy는 산출하지 않음
지연	prefill부터 마지막 토큰까지의 end-to-end 경계	DFlash 1 TTFT와 post-prefill throughput을 분리 기록
사용량	입력·출력 토큰과 가격 단위	tokens/cycle·피크 메모리 기록
정확성 안전망	baseline과 출력 또는 answer parity	DFlash 2는 greedy 3/8 일치, 5/8 불일치
변동성	반복 단위와 집계 단위	prompt별 5회 반복, 독립 n=50으로 해석하지 않음

DFlash 1에서 무엇이 달라졌나

M4 Max 64GB에서 dflash-mlx==0.1.8, MLX 0.32.1, mlx-lm 0.31.3을 사용했습니다. Qwen3.5 4B·9B·27B int4 target, GSM8K 첫 10문항, max_tokens=256, block 16, adaptive verification, prompt별 5회 반복을 같은 순서로 실행했습니다. 각 모델의 50개 행은 같은 10문항을 반복한 paired 관측이므로 독립 표본 50개가 아닙니다.

모델	Baseline	DFlash 1	속도 배수	수락 비율	피크 메모리
Qwen3.5-4B	148.58 tok/s	192.80 tok/s	1.29×	0.8242	2.65 → 3.88GB
Qwen3.5-9B	89.57 tok/s	109.65 tok/s	1.23×	0.8125	5.15 → 7.88GB
Qwen3.5-27B	28.33 tok/s	52.84 tok/s	1.83×	0.8379	15.36 → 19.88GB

TTFT 중앙값은 4B에서 154.24ms → 129.07ms, 9B에서 317.94ms → 237.37ms, 27B에서 2,810.11ms → 1,460.25ms였습니다. 그러나 이 값은 첫 토큰까지의 시간이고, 표의 tok/s는 prefill 뒤 생성 속도입니다. 둘을 합쳐 end-to-end 지연 개선이라고 부르지 않았습니다.

27B의 1.83배를 정답률로 읽지 않습니다

DFlash 1의 수락 비율은 draft가 제안한 토큰을 target이 받아들인 비율과 관련된 지표입니다. 정답률이나 사용자 만족도와 같은 뜻이 아닙니다. 이번 실행에서는 baseline과 DFlash 1의 전체 answer accuracy 또는 greedy token parity를 저장하지 않았습니다. 따라서 “27B가 1.83배 빨라졌고 더 좋은 답을 냈다”가 아니라 “이 조건에서 post-prefill 생성 속도와 피크 메모리가 이렇게 관측됐다”라고만 씁니다.

DFlash 2는 빠르지만 parity에서 멈췄습니다

별도 실행에서는 M4 Max 64GB, dflash==0.1.0, MLX 0.32.0, mlx-lm 0.31.3, 8개 GSM8K prompt, block 5, 5회 반복을 사용했습니다. 성능 측정 조건은 temperature 1이었고 parity 확인은 temperature 0이어서 완전히 같은 실험으로 합치지 않았습니다. AR은 28.00 ± 0.52 tok/s, DFlash 2는 56.56 ± 0.53 tok/s, 표시된 로그의 기하평균 속도 배수는 2.02×였습니다. 하지만 greedy token sequence는 8개 중 3개만 일치했고 5개가 달랐습니다.

DFlash 2 결과	관측값	읽는 방법
생성 속도	28.00 → 56.56 tok/s	prefill 제외 생성 지표
표시 속도 배수	2.02×	이 실행의 로그 요약
greedy parity	3/8 일치, 5/8 불일치	출력 동일성 확인 실패
answer accuracy	산출하지 않음	token mismatch와 정답률을 동일시하지 않음
end-to-end 지연	산출하지 않음	TTS 전체 선택 기준을 닫지 않음

실무에서 켤지 말지 결정하는 표

상태	가능한 결론	다음 확인
속도만 개선, parity 없음	속도 관측만 보고	answer accuracy와 출력 비교 추가
속도 개선, parity 일치	동일 출력 경로의 후보	end-to-end·메모리·실패 확인
품질 개선, 비용 증가	특정 난도에서 선택 가능	문제당 비용과 지연의 허용선 확인
메모리 증가, 품질 근거 없음	기본값으로 켜지 않음	메모리 여유와 품질 실험부터 기록

결론

Test-Time Scaling을 선택할 때는 정확도 하나 또는 속도 하나만 보지 않습니다. 같은 문제를 같은 판정 기준으로 실행하고, 품질·end-to-end 지연·토큰·비용·변동성을 한 표에 모아야 합니다. 이번 DFlash 기록은 4B·9B·27B에서 post-prefill 속도와 메모리 변화를 보여 줬고, DFlash 2 기록은 속도 배수와 함께 5/8 greedy mismatch를 보여 줬습니다. 그래서 이 결과가 말하는 결론은 “항상 켜라”가 아니라 “속도 개선과 정답 동일성은 별도 검증하라”입니다.

참고한 자료

• DFlash 1 공개 runner
• DFlash 1 protocol
• Inco AI, DFlash 2 소개