TraceSpec은 에이전트 궤적 단위로 추측 디코딩 드래프트를 다시 학습한다

무엇인가

LLM 에이전트는 하나의 과업을 끝낼 때까지 추론, 행동, 도구 피드백이 누적된 히스토리 위에서 모델을 수십 번 다시 호출한다. 추측 디코딩(speculative decoding)은 작은 드래프트 모델이 토큰을 미리 제안하고 타깃이 병렬 검증하는 방식으로 이 호출들을 가속하지만, 기존 벤치마크는 전체 수용 토큰 수를 하나의 평균으로 압축해 버린다. 이 논문이 지적하는 핵심은 그 평균이 서로 다른 성격의 결정들을 섞어 놓기 때문에, 드래프트를 어디에 더 감독해야 하는지에 대해서는 거의 알려주지 않는다는 점이다.

어떻게 동작하나

저자들은 먼저 이 혼합을 실제로 분해한다. BrowseComp-Plus와 SWE-bench Verified에서의 동적 실행과, 저장된 히스토리를 모든 드래프트에 동일하게 먹이는 고정 프리픽스 재생(fixed-prefix replay)을 결합했다. Qwen3-8B, T=0에서 DSpark의 브라우징 수용 길이는 입력 2k 토큰 미만 구간의 3.633에서 16k~32k 구간에서 5.479로 오르지만, 같은 구간의 모델 호출 처리량은 82.73토큰/s에서 22.54토큰/s로 떨어진다. 소프트웨어 엔지니어링도 73.83에서 28.19로 떨어진다. 그런데 같은 과업·같은 실행 단계·20스텝 이후 행동이라는 조건을 고정하고 비교하면 방향이 뒤집힌다. DSpark 브라우징의 늦은 행동 수용 길이는 8k~16k의 6.194에서 16k~32k의 5.322로 줄어 차이 −0.872(95% 구간 [−1.205, −0.473])이고, DFlash는 −1.336, EAGLE-3는 −1.110이었다. 워크로드에 따라서도 추세가 갈린다. 재생 실험에서 웹 리서치는 5.242에서 3.442로 감소하지만 소프트웨어 엔지니어링은 3.073에서 4.321로 증가한다. 실행 단계별로도 최고 수용 구간이 웹에서는 행동(4.966 대 기획 3.488), 소프트웨어 엔지니어링에서는 성찰(4.447 대 답변 3.232)로 바뀐다.

무엇과 다른가

이 관찰이 학습 설계로 이어진다. TraceSpec은 타깃 모델이 생성한 궤적에서 각 어시스턴트 생성 하나를 세그먼트로 자르고, 그 세그먼트에 프리픽스 길이·실행 단계·워크로드·직전 도구 상태를 묶은 상태 z를 부여한다. 난이도 신호는 타깃 분포 p와 드래프트 분포 q의 겹침 a=Σ min(p,q)=1−TV로 정의하고, 블록 안의 누적 곱을 써서 D=1−(Σ_b Σ_k Π_{j≤k} a_{b,j})/(Σ_b m_b)로 정규화한다. 누적 곱을 쓰는 이유는 앞쪽에서 한 번 어긋나면 뒤따르는 연속 수용이 무너지기 때문이다. 이 값은 세그먼트 이동평균과 같은 상태 그룹 평균을 κ로 축소 추정해 안정화하고, r=clip(D̂/Σb_jD̂_j, r_min, r_max)로 상대 난이도를 구한 뒤 w=(1−λ)b_s+λ·(b_s r_s/Σb_j r_j)로 감독 비중을 정한다. λ=0이면 기존 고정 배분과 같아진다. 마지막으로 세그먼트 한 번 방문이 만들어내는 유효 예측 이벤트 수 ĉ로 나눠 샘플링 확률 π=(w_s/ĉ_s)/Σ(w_j/ĉ_j)를 만든다. 짧은 도구 호출과 긴 추론 응답은 같은 횟수로 뽑혀도 예측 대상 수가 다르므로, 이 정규화가 있어야 예산이 실제로 의도한 비율대로 배분된다. 첫 에폭은 기존 배분으로 통계를 모으고 이후 에폭에서 샘플링 표를 갱신하며, DSpark의 아키텍처와 증류 목적함수는 그대로 유지한다.

어떻게 쓰나

실험은 BrowseComp-Plus와 SWE-bench Verified 각 100개 과업의 동적 실행, 그리고 1만 개 학습 상태와 2,500개 테스트 상태로 구성된 TraceSpec-Traj 재생으로 이뤄졌다. 두 도메인, 5개 컨텍스트 구간, 4개 실행 단계의 40개 조합을 모두 덮는다. 베이스라인은 DFlash, EAGLE-3, DSpark, LongSpark, DLite 다섯 개이고 타깃은 Qwen3-4B/8B/14B, 온도는 0과 1로 총 108개 구성이다. 결과적으로 TraceSpec은 72개 수용률 비교 중 68개에서 앞섰고(재생 24개 전부, 동적 48개 중 44개), 재생에서 DSpark 대비 기획·행동·성찰·답변 전 단계에 걸쳐 12.1%~25.3% 향상됐다. 처리량은 네이티브 PyTorch로 비교한 18개 설정 중 15개에서 1위였고, DSpark 대비 재생 처리량 개선은 12.5%~22.6%다. Qwen3-4B에서는 재생 검증 수율이 T=0에서 50.0%→61.2%, T=1에서 46.0%→57.1%로 올랐고 처리량은 44.25→53.44, 40.28→49.37토큰/s가 됐다.

전제와 한계

학습 방식 자체를 뜯어본 소거 실험도 Qwen3-4B에서 이뤄졌다. 마지막 어시스턴트 응답만 고정 배분으로 감독하는 A에서 중간 턴까지 넓힌 B로 가면 수용 길이가 3.9%~10.2% 올라가고, B에서 적응적 배분을 적용한 TraceSpec은 3.3%~10.0%를 더 얻는다. 최대 개선은 SWE-bench Verified, T=1에서 4.417→4.859였다. 상태 그룹 사전분포를 전역 사전분포로 바꾼 C1 대비 3.6%~9.2%, 누적 곱을 예측 격차 평균으로 바꾼 C2 대비 2.2%~9.5% 앞선다. 온도 민감도도 함께 보고된다. T=1에서 45개 매칭 비교 전부 수용 길이가 낮아지는데, DSpark는 6.5%~8.7% 감소에 그친 반면 DFlash는 11.0%~18.2%, EAGLE-3는 13.5%~15.4% 줄었다.

개발자 관점에서 이 논문의 실용적 메시지는 두 가지다. 첫째, 에이전트 서빙에서 평균 수용률 하나로 드래프트 품질을 판단하면 착각할 수 있다. 컨텍스트가 길어질수록 평균은 올라가는데 정작 같은 종류의 늦은 행동에서는 떨어지는 역전이 실제로 관측된다. 둘째, 드래프트 증류에 쓸 데이터를 고를 때 마지막 응답만 쓰지 말고 중간 행동·성찰 턴까지 후보로 넣되, 방문 횟수가 아니라 유효 예측 이벤트 수 기준으로 예산을 나눠야 한다. 다만 이득은 처리량 기준이며 과업 완료 시간과 같지 않다. 논문의 식 (1)처럼 에피소드 지연은 프리필, 드래프트·검증, 도구 실행, 기타 비용의 합이라서, DSpark가 DFlash보다 수용 길이를 10.1%~13.8% 높여도 평균 에피소드 지연 감소는 2.7%~7.1%에 그쳤다.

저자가 본문에서 명시한 전제와 한계도 짚어둘 만하다. 온라인 측정값은 각 온도에서 실제로 생성된 워크로드를 반영하는 반면 재생은 입력 히스토리를 고정하므로 두 결과를 같은 축으로 읽으면 안 된다. LongSpark는 SGLang으로 구동돼 처리량 비교에서 제외되고 수용률 비교에만 참여한다. 적응 배분은 상태 그룹 추정과 이벤트 수 추정 ĉ에 의존하며 스케줄링 하이퍼파라미터는 개발 과업으로 정해졌다. 실험 범위도 Qwen3 계열 세 가지 크기, 두 워크로드, 사고 모드 비활성화, 50 행동 스텝과 32,768 컨텍스트 토큰이라는 설정 안에 있다. 별도의 한계 절이 제시된 것은 아니며, 드래프트 적응에는 타깃이 생성한 학습 궤적이 필요하다는 비용도 전제로 깔려 있다.