PersonTTS가 정확도·지연·비용 요구를 함께 만족하는 추론 정책을 찾는다

무엇인가

테스트타임 스케일링(TTS)은 추론 시점에 연산을 더 투입해 LLM의 추론 성능을 끌어올리는 방식이다. 문제는 이 추가 연산이 비용과 지연을 크게 늘린다는 점이고, 기존 효율화 연구는 대부분 정확도 대비 비용, 또는 정확도 대비 지연 중 한 축만 다룬다. 즉 어느 한쪽 파레토 프런티어를 앞으로 밀어내는 데 집중해 왔다. 그런데 실제 사용자 요구는 다차원적이다. 정확도 하한, 문항당 최대 지연 상한, 문항당 평균 추론 비용 상한을 동시에 지정하는 경우가 많고, 요구 조합이 달라지면 같은 문제 집합에서도 최적 컨트롤러가 달라진다. 이 논문은 그래서 파레토가 아니라 선호(preference)로 초점을 옮긴다. 사용자별 정확도·지연·비용 요구를 동시에 만족시키는 실행 가능한 컨트롤러를 찾아내는 문제, 즉 Personalizsed Test-Time Scaling으로 정식화한다.

어떻게 동작하나

정식화는 다음과 같다. 사용자 요구는 프로필 u=(a_u, L_u, C_u)로 표현되며 각각 정확도 하한, 문항당 최대 리플레이 지연 상한, 문항당 평균 추론 비용 상한이다. 정책 π는 u와 현재 관측 이력 h_k를 행동으로 매핑하는 실행 코드다. 행동 공간은 Spawn(m,n)(모델 m으로 n개 분기 생성), Continue(I)(선택 분기 집합 진행), Refine(I)(자기 정제 시작), Prune(i)(분기 제외), Finish(y)(관측된 답으로 종료, 생략 시 다수결)로 구성된다. 컨트롤러는 모델 라우팅, 추론 폭과 깊이, 자기 정제, 가지치기, 중단 시점을 모두 제어하며, 정답이나 정오 라벨은 주어지지 않는다. 목표는 JSR(결합 만족률)로, 여러 리플레이 시드 배치 중 정확도·지연·비용 세 조건을 동시에 통과한 배치의 비율이다.

무엇과 다른가

탐색은 오프라인 리플레이 위에서 LLM 에이전트가 컨트롤러 코드를 고쳐 나가는 방식이다. 캐시된 궤적·중간 답·자원 기록이 있어 후보 평가에 추가 롤아웃이 필요 없다. 각 평가는 JSR 스칼라 값만 돌려주지 않고 F_t=(X_t, ζ_t, T_t), 즉 JSR과 제약 통과율·마진, 그리고 컨트롤러 결정과 결과를 연결한 정제된 실행 트레이스를 함께 반환한다. 이 덕분에 정확도 부족과 자원 위반을 구분해 다음 수정에 반영할 수 있다. 라운드마다 B개의 새 후보를 생성하고, 외부 정적 검증과 리플레이를 거쳐 JSR이 엄격히 개선될 때만 기존 정책을 교체한다.

어떻게 쓰나

핵심은 새 사용자마다 반복되는 탐색 비용을 줄이는 것이다. 저자들은 소스 프로필의 탐색 이력(프로필, 후보 코드, 평가 피드백, 실행 트레이스, 선정 정책)을 Policy Experience Bank에 저장하고 두 갈래로 재사용한다. 첫째는 요구 유사도 기반 초기화다. 자원 상한을 로그 변환하고 소스 프로필 좌표로 표준화한 뒤 유클리드 최근접 소스 정책을 초기 코드로 삼고, 이를 대상 프로필에서 리플레이해 초기 피드백을 얻는다. 소스 점수를 그대로 믿지 않고 대상 프로필에서 다시 채점하는 것이 요점이다. 둘째는 절차 지식 증류다. 소스 후보들을 그들의 요구 조건 아래에서 비교해, 언제 수정이 적절한지, 어떤 변경을 우선할지, 결과를 어떻게 평가할지를 담은 동결된 Guide를 만들고 이를 매 제안 단계에 투입한다. 대상 피드백은 Guide가 아니라 에이전트의 검색 증거를 갱신한다.

전제와 한계

논문은 3.4절에서 소스 정책 재사용이 판정 기준과 실행을 동시에 바꾼다는 점을 분해식으로 보인다. 대상 프로필과 소스 프로필에서의 JSR 차이는 고정된 레코드에 대상 임계값을 적용했을 때 생기는 효과와, 요구 조건에 따라 실행 자체가 달라지는 효과의 합으로 나뉜다. 따라서 소스 프로필 성능은 대상 탐색에 참고가 될 수는 있어도 일반적으로 대상 성능을 결정하지 않는다. 저자들은 실행 편차에 기반한 상·하한 명제도 제시하며, 이 논리가 후보 평가와 선택을 항상 대상 프로필에서 수행해야 하는 이유라고 설명한다.

실험은 AIME와 HMMT에서 Qwen3 6종(0.6B, 1.7B, 4B, 8B, 14B, 32B)으로 수행했다. AIME24–25 60문항을 discovery에 쓰고 AIME26 30문항을 held-out으로, HMMT24 30문항을 discovery에 쓰고 HMMT25 30문항을 held-out으로 분리했다. 문제-모델 쌍마다 128개의 사전 샘플링된 체크포인트 추론 궤적(중간 답, 사고·탐침·피드백 토큰 수, 지연 기록 포함)을 리플레이 풀에 담았다. 소스 프로필 100개, 대상 프로필 20개를 사용했고 두 집합의 임계값 조합은 겹치지 않는다. 베이스라인은 AutoTTS(β=0.5와 β=1.0), Self-Consistency 계열의 ASC와 ESC, Parallel-Probe다. 결과적으로 PersonTTS는 두 벤치마크 모두에서 JSR 기준으로 강한 베이스라인들을 크게 앞섰고 held-out 문제에서도 우위를 유지했다. 재사용을 끈 변형도 이 이득의 대부분을 유지했는데, 저자들은 이를 두고 주된 이득이 경험 재사용 자체보다 공동 요구를 직접 최적화하는 데서 나온다고 해석한다. 다만 본문에 제시된 범위에서는 표 1의 구체적 JSR 수치가 숫자로 제시되지 않아, 정량적 개선폭은 원문 표를 확인해야 한다.

절제 실험은 두 재사용 기제의 역할이 다르다는 것을 보여준다. 요구 매칭 초기화(warm-start)는 주로 탐색 시작점을 개선하고, Guide는 이후 수정을 이끌며 벤치마크 전반에 더 일관된 held-out 이득을 준다. 두 이득은 단순히 더해지지는 않는다. 효율 측면에서는 동일한 5라운드 프로토콜에서 Guide만 사용한 탐색이 재사용 없음 대비 에이전트 호출 시간을 약 46%, 비용을 약 36% 줄였다. 반면 warm-start 단독은 경과 시간을 주로 줄이고 비용은 오히려 약간 늘릴 수 있었다. 경험 뱅크 확장 실험에서는 100쌍 전체에서 20쌍·60쌍 중첩 뱅크를 5개 샘플링 시드로 구성했는데, 뱅크가 커지면 discovery 문제 품질은 일관되게 좋아졌지만 held-out에서는 AIME는 계속 좋아지고 HMMT는 역전됐다. 검색 커버리지 확대가 문제 간 일반화를 보장하지는 않는다는 뜻이다.

개발자 관점에서 이 논문의 실용적 함의는 명확하다. 지연 상한과 토큰 비용 상한, 정확도 하한을 동시에 만족하는 추론 전략을 사람이 손으로 조합하는 대신, 프로필을 입력으로 주고 실행 가능한 컨트롤러를 자동 탐색하게 만드는 발상이다. 이미 사전 샘플링된 추론 궤적 캐시가 있는 환경이라면 후보 평가에 추가 생성 비용이 들지 않아 탐색 자체가 저렴해진다. 다만 소스 프로필에서 잘 나온 정책의 점수를 그대로 신뢰하면 안 된다. 요구 조건이 바뀌면 실행 자체가 달라지므로 대상 프로필에서 반드시 재평가해야 하고, 경험 뱅크 크기를 무조건 키우는 것이 답이 아니라는 점도 함께 기억할 필요가 있다.

저자들이 밝힌 한계도 분명하다. 이 연구는 오프라인 리플레이와 시뮬레이션된 운영 요구 프로필, 수학 추론 문제만을 다루며 인간 참여자를 포함하지 않고 주관적 만족도를 측정하지 않는다. 보고된 JSR은 이 리플레이 설정에서의 정확도와 자원 제약으로 정의된 값이며, 실제 배포에는 의도한 워크로드와 자원 계상에 대한 검증이 필요하다고 명시한다. 또한 discovery 단계의 JSR은 유용한 탐색 신호일 뿐 out-of-sample 결합 만족률의 직접 추정치가 아니며, 뱅크 확장이 일률적으로 유리한 축이 아니라고 인정한다. 향후 과제로 캘리브레이션된 커버리지나 불확실성 추정을 요청 빈도 인식 배포 결정과 결합해, 경험 뱅크가 신뢰할 만할 때는 매칭된 컨트롤러를 재사용하고 커버리지가 나쁜 프로필에 대해서만 백그라운드 탐색을 트리거하는 방향을 제안한다.