SpecAgent는 강한 모델을 매 단계 작성자에서 검토자로 바꾼다

무엇인가

도구 호출 에이전트는 수십에서 백여 턴에 이르는 긴 궤적으로 작업을 해결한다. 그런데 지금의 표준 설계는 강한 모델 하나가 모든 스텝을 생성하고, 그중 상당수는 주문 조회나 레코드 읽기처럼 훨씬 작은 모델로도 충분한 routine한 단계다. 기존의 분담 방식은 모두 강한 모델을 생성자로 남겨둔다. 라우터는 질의 단위로 모델을 고르고, 협업 에이전트는 스텝마다 어느 모델이 행동할지 정하며, 추측 실행(speculative) 계열은 작은 모델의 초안을 강한 모델이 자기라면 했을 행동과 일치하는지 한 스텝씩 대조한다. 그래서 강한 모델은 여전히 각 기준 스텝을 생성해야 하고, 그 작업은 제거되는 게 아니라 겹쳐질 뿐이다. 게다가 정확 일치는 에이전트에 너무 엄격하다. 다른 질의, 다른 조회 순서, 다른 인자 선택도 유효한 해답이 될 수 있는데 강한 모델의 선택과 다른 진전은 버려진다. 이 논문의 질문은 이것이다. 강한 모델이 약한 모델이 초안한 여러 스텝을 검토하고 유효한 것만 남길 수 있는가.

어떻게 동작하나

SpecAgent는 행동(acting)과 확정(committing)을 분리한다. 약한 모델이 궤적을 초안하고 강한 모델이 이를 검토한다. 설계를 규정하는 성질은 세 가지다. 첫째, 초안은 실제 관측에 근거해야 한다. 뒤 스텝이 앞 도구 호출의 반환값에 의존하기 때문이다. 그래서 약한 모델은 초안 과정에서 읽기 전용(read-only) 도구 호출을 즉시 실행한다. 둘째, 되돌릴 수 없는 행동이 있다. 약한 모델은 주문 변경처럼 상태를 바꾸는 첫 행동을 실행하지 않고 붙잡아 두고, 강한 모델이 그 구간을 실행 전에 검토한다. 셋째, 검토 비용은 생성 비용보다 작아야 한다. 강한 모델은 구간을 한 번의 병렬 프리필 패스로 읽는 반면, 생성을 했다면 토큰마다 디코딩이 필요하다. 형식화는 부분관측 마르코프 결정과정(POMDP) 위에서 이뤄진다. 행동은 상태를 바꾸지 않는 읽기와 상태를 바꾸는 행동으로 나뉘고, 히스토리에 남은 오류는 지워서 복구할 수 있지만 환경에 도달한 오류는 되돌릴 수 없다는 가역성 원리가 프로토콜의 근거다.

무엇과 다른가

구체적 절차는 초안·검증·수리 세 단계다. 약한 모델은 최대 K 스텝짜리 청크를 초안하는데, 읽기는 즉시 실행되어 실제 관측을 보고 다음 스텝을 고르고, 청크는 첫 상태 변경 행동에서 끝나며 그 행동은 실행되지 않고 보류된다. 읽기만으로 K 스텝에 도달한 청크는 검토 없이 커밋된다. 검증에서 강한 모델은 히스토리와 청크를 한 번에 읽고 (j, r, ã) = V_S(H_t, τ̂) 형태의 판정을 낸다. j는 받아들일 수 있는 최장 접두부 길이, r은 첫 거부 사유, ã는 그 스텝을 대체할 선택적 대안이다. 각 초안 스텝이 앞 스텝의 관측에 조건화되므로 한 스텝이 틀리면 뒤는 신뢰할 수 없어 판정이 접두부 형태를 띤다. 수용은 의미적(semantic)이다. 강한 모델이 자기라면 썼을 스텝인지가 아니라 과제를 향한 유효한 수인지를 묻는다. 수리는 거부된 스텝이 인자나 대상만 틀린 단일 도구 호출인 경우가 많아 판정에 대체 행동을 함께 실어 보내면 추가 강한 모델 호출이 들지 않는다. 여러 호출에 걸친 수정이거나 대체안이 어댑터 검증을 통과하지 못할 때만 강한 모델이 교정 턴을 한 번 쓴다. 수리 결과는 강한 모델 자신의 스텝이므로 재검토 없이 커밋되고, 거부된 접미부는 보류된 행동까지 버려져 다음 초안은 커밋된 스텝만의 히스토리에서 시작한다.

어떻게 쓰나

비용 모델은 두 가정 위에 선다. 강한 복제본이 메모리 대역폭에 묶이는 작은 배치로 디코딩할 때 호출의 시간과 메모리 트래픽은 가중치 패스 수에 비례한다는 것(디코딩 토큰당 한 번, 프리필 한 번), 그리고 과제마다 평균 스텝 수용률 p_u가 있고 청크의 스텝들은 독립적으로 수용된다는 것이다. 이로부터 강한 모델의 커밋 스텝당 시간·트래픽 비율 R_u = (1-p_u)/(1-p_u^n)·(v/d) + ρ(1-p_u)를 얻는다. p_u가 0이면 v/d+ρ, p_u가 1에 가까워지면 v/(nd)로 떨어져, 약한 모델의 초안이 검증자 취향에 맞는 과제에 절감이 집중된다. 지연 비율 L_u = R_u + κ·n(1-p_u)/(1-p_u^n)도 함께 제시되는데, 커밋되는 모든 스텝은 먼저 초안되어야 하므로 약한 스텝이 강한 스텝보다 충분히 싸야 전체가 빨라진다는 조건이 붙는다.

전제와 한계

실험은 τ²-Bench Airline(50개 과제)과 Retail(114개), AutomationBench(공개 600개 과제), VitaBench Delivery(100개), 그리고 실제 도구 서버를 쓰는 MCP-Atlas(공개 101개)에서 이뤄졌다. 약한 모델은 Qwen3.5-4B, 강한 모델은 Qwen3.5-397B-A17B이며, 비교 대상은 Weak-only, Strong-only, 협업 베이스라인 AgentCollab, Speculative Actions다. 청크 크기는 τ²와 VitaBench에서 K=6, AutomationBench에서 K=8이다. 품질에서 SpecAgent는 Airline에서 Strong-only와 동일한 86.0(Weak-only 80.0)을, Retail에서 87.7로 Strong-only 88.6에 0.9점 차이까지 붙어 약-강 격차의 89%를 회복했다. AutomationBench에서는 44%(10.5, Weak 6.8과 Strong 15.2 사이), VitaBench에서는 75%(44.5, 34.0과 48.0 사이)를 회복했다. 자원 측면에서 Strong-only 대비 추정 HBM 읽기는 Airline 43~45%, Retail 53~57%, AutomationBench 78~84%, VitaBench 59~65%로 줄고, wall time은 41%, 54%, 57%, 69%로 떨어졌다. 반면 추정 FLOPs는 30%, 38%, 38%, 87% 늘었다. 강한 모델 호출 수는 Airline 13.8→3.1, Retail 13.1→3.1, AutomationBench 17.4→11.8, VitaBench 21.9→8.2로 감소했다.

베이스라인 비교에서 두 협업 방식은 모두 Strong-only보다 강한 모델 호출을 더 낸다. Speculative Actions는 매 스텝 강한 모델이 행동하면서 배경 추측까지 더해 Airline에서 17.4 대 13.8 호출을 쓰고 메모리 트래픽과 시간이 늘며, 공개 구현에서는 Weak-only보다 낮은 품질(Airline 72.0, Retail 48.5)을 기록했다. AgentCollab은 τ²에서 85.3과 85.7로 강한 모델에 근접하지만 호출이 18.5 대 13.8로 많고 더 오래 걸리며, AutomationBench에서는 7.3에 Strong-only의 1.5배 HBM 읽기와 3.0배 wall time을 쓴다. VitaBench에서는 50.0으로 Strong-only 48.0을 살짝 넘지만 SpecAgent의 1.4배 자원을 쓴다. SpecAgent는 τ²에서 AgentCollab보다 같거나 높은 품질을 HBM 읽기 1.6~1.9배, wall time 2.6~3.1배 낮춰 달성했고, 표에 실린 모든 벤치마크에서 HBM 읽기와 wall time이 동시에 Strong-only보다 낮은 유일한 협업 방식이다. 엣지-클라우드 배치인 MCP-Atlas에서는 Qwen3.5-4B를 RTX 5090에서 로컬로 돌리고 강한 모델을 Qwen3.5-397B-A17B, GLM-5, DeepSeek-V4-Flash-0731 세 가지로 바꿔가며 실험했는데, 약-강 격차의 53~75%를 회복하면서 강한 모델 출력 토큰은 Strong-only의 36~50%만 디코딩했고 API 비용은 59~81%로 떨어졌다. 다만 이 배치에서는 로컬 약한 모델이 호스팅 강한 모델과 비슷한 시간(109초 대 105~151초)이 걸려 wall time은 줄지 않았고, 이득은 원격 사용량과 비용으로 나타났다.

분석은 절감의 출처를 분해한다. τ²에서 강한 모델은 커밋 스텝 약 7개당 한 번 검토하고, 디코딩 토큰은 Strong-only의 17~30%로 줄었다. 관측된 HBM 읽기 비중은 모든 벤치마크에서 예측치와 0.01 이내로 맞았다. AutomationBench에서는 약한 모델 초안이 더 자주 거부되고 거부마다 약 1.5 d̄ 토큰의 별도 수리가 필요해 수리 항이 지배하며 절감이 줄어든다. VitaBench는 검토 경계의 약 77%가 거부되지만 판정과 수리가 비슷하게 기여해 예측 비중이 0.28이다. FLOPs가 늘어도 시간이 줄어드는 이유는 디코딩이 메모리 대역폭에, 청크 전체에 대한 검증 프리필이 연산에 묶이기 때문이다. 강한 모델의 검증·수리는 SpecAgent FLOPs의 81~85%를 차지하지만 HBM 읽기 비중은 39~66%에 그치고, 약한 모델 초안은 FLOPs의 15~19%지만 HBM 읽기의 34~61%를 쓴다. 설계 선택 실험도 있다. 응답까지 보류하거나 읽기 포함 모든 청크를 검토하면 강한 모델 호출이 3배 이상 늘고 HBM 읽기 63~79%, wall time 2.5~3.0배 증가하면서 Pass@1은 오히려 떨어졌다. 융합 대체안 없이 수리하면 Pass@1이 82.5로 내려가고, 강한 모델이 쓸 스텝만 정확히 받아들이는 검증자는 Pass@1 82.5에 FLOPs 70% 증가를 낳았다. 약한 모델이 세 번 모두 푸는 과제에서는 양쪽 모두 천장 근처(94.8 대 96.9, 96.2 대 96.7)였고, 약한 모델이 불안정한 과제에서도 SpecAgent는 Strong-only에 근접했다(Airline 70.4 대 66.7, Retail 74.2 대 75.8).

저자들이 밝힌 전제와 한계는 분명하다. 첫째, 디코딩이 메모리 대역폭에 묶인다는 가정은 강한 복제본의 디코드 배치가 연산-대역폭 균형점 아래에 있을 때만 성립하며, H20 기준 약 37 시퀀스다. 배치가 커져 연산에 묶이면 30~87%의 FLOPs 증가가 시간 비용으로 돌아온다. 둘째, 지연 이득은 약한 스텝이 강한 스텝보다 빠를 때만 나오는데, MCP-Atlas 엣지-클라우드 배치에서는 성립하지 않아 wall time이 줄지 않았다. 셋째, 절감은 수용률이 떨어지면 줄어든다. AutomationBench처럼 약한 모델이 훨씬 뒤처지면 수리가 늘어 격차 회복이 44%에 그친다. 넷째, API 비용은 토큰만큼 줄지 않는다(59~81%). 검토마다 컨텍스트를 입력으로 다시 보내는 프리필 비용이 남기 때문이다.

실무 관점에서 이 논문이 주는 지침은 명확하다. 에이전트 서빙 비용이 강한 모델의 토큰 단위 디코딩에 지배되고, 배치가 메모리 대역폭 한계 안에 있으며, 궤적에 읽기 전용 단계가 많고 상태 변경 지점이 명확한 워크플로라면 검토자 역할 전환이 지연과 메모리 트래픽을 동시에 줄일 수 있다. 반대로 강한 모델이 이미 연산 포화 상태이거나, 약한 모델의 초안 수용률이 낮아 수리 턴이 잦거나, 약한 모델이 강한 모델만큼 느린 엣지-클라우드 구성이라면 이득이 사라진다. 도입 전에 확인할 것은 세 가지다. 상태 변경 행동을 안전하게 보류하고 되돌릴 수 있는 어댑터 경계가 있는지, 청크 크기 K와 수용률 p_u가 비용 모델의 절감 구간에 들어오는지, 그리고 검증자에게 정확 일치가 아닌 의미적 수용을 허용할 프롬프트와 검증 절차가 준비돼 있는지다.