한 줄 요약: 동결된(frozen) LLM/VLM의 은닉 상태(hidden state) 궤적에서 가벼운 제어 신호를 읽어내면, 모델 자체를 미세조정하지 않고도 “이걸 내가 풀 수 있을까?”, “도구를 써야 할까?”, “더 큰 모델에게 넘길까?”를 판단할 수 있다. AndroidWorld에서 대형 모델 호출을 최대 90.7% 줄이면서 성능은 유지하거나 향상시키는 결과를 보여준다.
왜 “동결된 모델”인가?
에이전트 시스템을 실제로 배포해본 사람이라면 누구가 이 딜레마를 안다. GPT-5.5나 Claude 4.8 같은 프론티어 모델은 똑똑하지만 비싸다. 작은 모델은 저렴하지만 복잡한 작업에서 실패한다. 그래서 “작은 모델이 처리하다가 막히면 큰 모델에게 넘기자”는 라우팅(routing) 전략이 자연스럽게 떠오른다.
문제는 “언제 넘길 것인가?” 이다.
기존 접근법들은 대체로 세 가지 한계가 있다:
- 프롬프트 수준 라우팅: 입력 텍스트의 특징만 보고 라우팅한다. 모델이 실제로 해당 인스턴스를 풀 수 있는지는 평가하지 않는다.
- 외부 오케스트레이터: 별도의 판별 모델을 두거나 다수 모델 투표를 한다. 비용과 지연이 추가된다. 3 모델 미세조정: 백본 모델 자체를 도구 호출이나 자기 평가에 더 능하도록 파인튜닝한다. 새 모델이 나올 때마다 반복해야 한다.
Huawei Technologies Canada와 University of Alberta가 제안한 Multi-Head Latent Control은 네 번째 길을 제시한다: 동결된 모델의 은닉 상태 궤적에서 제어 신호를 직접 읽어내자.
핵심 구조: 두 개의 가벼운 헤드
Capability Head — “내가 이걸 풀 수 있을까?”
Capability Head는 동결된 백본 모델의 최종층(final layer) 은닉 상태 궤적을 읽어서, 현재 모델이 해당 인스턴스를 해결할 수 있는지를 나타내는 스칼라 점수 를 출력한다.
- 이 높으면 → 현재 모델로 계속 진행
- 이 낮으면 → 더 강력한 폴백 모델에게 제어권 이양
훈련 데이터는 120K 샘플의 의도적으로 다양한 혼합(mixture)으로 구성된다: 시각적 질문응답(VQAv2, ScienceQA), 차트 이해(CharXiv, ChartQA), 수학 추론(MathVerse, MathVista), 화면 이해(ScreenSpot-Pro), 개방형 QA(TriviaQA), 멀티턴 도구 사용(APIGen-MT-5k) 등.
핵심 통찰은 이것이다: 좁은 도메인(예: 시각-수학만)으로 학습한 헤드는 다른 도메인으로 전이되지 않는다. 논문의 부록 실험에서 시각-수학 데이터만으로 학습한 Capability Head를 ScreenSpot-Pro에서 평가하면 ROC-AUC가 0.62로 급락하지만, 전체 혼합 데이터로 학습하면 0.84까지 올라간다. 즉, “모델이 충분한가?”라는 질문에 답하려면 광범위한 훈련 분포가 필수적이다.
Resolution Head — “그렇다면 어떤 개입이 필요한가?”
Resolution Head는 모델이 해당 인스턴스를 유지하기로 했을 때, 어떤 종류의 개입이 필요한지를 판단한다. 세 가지 행동 중 하나를 선택한다:
- info: 추가 정보 요청 (사용자에게 명확화 질문)
- tool: 외부 도구 호출 (검색, 계산기 등)
- cant: 현재 설정으로는 답할 수 없음 (정중한 포기)
직접 답하는 경우는 암묵적으로 “개입 불필요”로 처리된다 (모든 점수가 임계값 이하).
흥미로운 점은 Resolution Head가 중간층(middle layer) 은닉 상태에서 가장 잘 작동한다는 것이다. 최종층이 아닌 중간층에서 해상도 결정 신호가 더 강하다—이는 모델의 “표면 행동”과 “내부 표현”이 일치하지 않을 수 있음을 시사한다.
추론 시점 정책
전체 추론 파이프라인은 다음과 같다:
- 작은 모델 이 입력을 받아 생성을 시작
- 생성된 토큰들의 은닉 상태 궤적이 수집됨
- Capability Head가 계산
- (기본 0.8) → 큰 모델 에게 이양
- 이 유지되면, Resolution Head가 계산
- (기본 0.5) → 해당 행동 실행
- 그렇지 않으면 직접 답변
백본은 동결되어 있다. 두 헤드의 훈련은 가벼워서 16GB GPU 메모리 내에서 가능하며, 9B 규모 백본 기준 데이터 생성과 헤드 훈련 전체가 하루 이내에 완료된다.
실험 결과: 비용을 줄이면서 성능은 유지한다
AndroidWorld — 롱호라이즌 에이전트 환경
| 시스템 | 점수 | 대형 모델 API 비용 |
|---|---|---|
| Qwen3-VL-4B 단독 | 0.47 | $0.00 |
| Qwen3-VL-32B 단독 | 0.58 | $2.70 |
| 라우팅 (4B → 32B) | 0.60 | $0.25 (↓90.7%) |
작은 모델만 쓰는 것보다 점수가 오히려 더 높다 (0.47 → 0.60). 그러면서 대형 모델 호출 비용은 90.7% 감소한다. Capability Head가 매 스텝마다 “이건 내가 할 수 있어” 또는 “이건 큰 모델한테 넘겨”를 판단하기 때문이다.
Qwen3.5-9B → 27B 설정에서도 점수 0.51 → 0.56 향상, 비용 85.8% 감소를 기록했다.
When2Call — 도구 호출 결정의 질
Resolution Head를 When2Call 벤치마크에서 평가했다. 이 벤치마크는 “도구를 써야 할까?”, “추가 정보를 요청해야 할까?”, “포기해야 할까?”를 판단하는 능력을 측정한다.
결과: Qwen-VL-2B에서 F1이 37.3 → 49.0, 정확도가 52.7% → 65.1%로 향상되었다. 모델의 표면 행동이 틀려도 은닉 상태에는 정답이 인코딩되어 있다는 것이 핵심 발견이다.
TriviaQA — 웹 검색 도구 결정
| 백본 | 점수 (네이티브) | 점수 (Capability Head) | 도구 정밀도 | 누락된 호출 |
|---|---|---|---|---|
| Qwen3-VL-4B | 0.292 | 0.756 (+158.9%) | 91.0% → 87.1% | 708 → 244 (-464) |
| Qwen3-VL-32B | 0.672 | 0.778 (+15.8%) | 72.7% → 75.5% | 328 → 222 (-106) |
작은 모델에서 상대 점수 158.9% 향상이 특히 인상적이다. 단순히 도구를 덜 쓰는 게 아니라 더 나은 결정을 내리는 것이다—필요한 검색을 놓치는 횟수가 464건이나 줄었다.
토큰 신뢰도 vs 은닉 상태 신호: 왜 표면 확률은 충분하지 않은가
“모델의 토큰 확률(token confidence)만 봐도 되지 않을까?”라는 자연스러운 질문이 있다. 논문은 이를 직접 비교했다.
결론은 명확하다: 모델의 표면 확률은 부적절한(confident-wrong) 경우를 구분하지 못한다. 생성된 토큰들의 평균 확률이 높더라도 답이 틀릴 수 있고, 반대도 마찬가지다. 반면 은닉 상태 궤적에서 읽어낸 Capability Head 점수는 정답과 오답 사이에 훨씬 더 명확한 분리를 보여준다.
접두부(Prefix) 평가: 200 토큰만 봐도 판단할 수 있다
실제 배포에서는 작은 모델의 전체 답변을 기다렸다가 라우팅하는 것조차 비효율적일 수 있다. 논문은 200개 토큰의 접두부(prefix)만 관찰해도 모델 적절성을 판단할 수 있음을 보여준다.
| 접두부 길이 | ROC-AUC | AUPR-Correct | ECE |
|---|---|---|---|
| 50 토큰 | 0.66 | 0.61 | 0.32 |
| 200 토큰 | 0.80 | 0.82 | 0.18 |
| 1000 토큰 | 0.82 | 0.85 | 0.17 |
| 전체 | 0.86 | 0.91 | 0.14 |
200 토큰이면 전체 평가 대비 ROC-AUC 0.80 vs 0.86로, 실용적 수준의 조기 판단이 가능하다. 이는 불필요한 생성을 중간에 중단하고 더 큰 모델에게 넘기는 인터럽트 기반 라우팅의 근거가 된다.
층 선택 소거 결과: Capability Head는 최종층(final layer)에서 ROC-AUC 0.86, AUPR-I 0.75로 가장 강한 신호를 얻었고, Resolution Head는 중간층에서 F1 52.07, 정확도 70.1%로 최적이었다. 이는 모델 적절성 평가와 개입 결정이 은닉 상태의 서로 다른 깊이에서 최적화됨을 의미한다.
기존 접근법과의 비교: 왜 프롬프트만으로는 안 되는가
논문은 “프롬프트로 모델에게 ‘모르면 넘겨’라고 지시하면 되지 않을까?”라는 베이스라인을 직접 테스트했다. Qwen3.5-9B에 “확실하지 않으면 답하지 마”라고 지시한 결과:
- ScreenSpot-Pro: 1581건 중 **4건(0.25%)**만 이양 → 거의 넘기지 못함
- MMLU-Pro: 1000건 중 **28건(2.8%)**만 이양
즉, 모델은 자신의 불확실성을 텍스트로 표현하는 데 극히 서투르다. 이는 자기 인식(self-awareness)이 표면 행동이 아니라 내부 표현 깊은 곳에 인코딩되어 있음을 강력하게 시사한다.
의미: “하네스의 책임”이라는 관점
이 연구는 에이전트 하네스(harness) 설계에 대한 중요한 시사점을 던진다. 동결된 모델을 쓰면서도 **배포 시점 제어(deployment-time control)**를 가능하게 하는 방법은 세 가지 차원에서 의미가 있다:
-
비용 효율성: AndroidWorld에서 90.7% 비용 절감은 단순한 최적화가 아니라 “에이전트를 상용 배포할 수 있느냐 없느냐”의 문제일 수 있다.
-
모델 독립성: 백본이 바뀌어도 헤드만 다시 훈련하면 된다. GPT-6가 나와도, Llama 4가 나와도 같은 패러다임을 적용할 수 있다.
-
확장 가능한 제어 인터페이스: 논문은 두 개의 헤드만 다루지만, 부록 F에서 더 넑은 비전을 제시한다—안전 필터링, 에스컬레이션, 사용자 선호도 라우팅, 애플리케이션별 정책까지. 은닉 상태 궤적은 재사용 가능한 제어 기반(control substrate) 역할을 할 수 있다.
한계도 있다. 헤드의 품질이 전체 시스템 효율성을 직접적으로 결정하므로, 품질이 낮으면 잘못된 라우팅이 오히려 비용을 늘릴 수 있다. 롱호라이즌 설정에서는 작은 판단 오류가 누적될 수 있다. 그러나 16GB GPU 메모리로 하루 만에 훈련 가능한 가벼움은 이러한 위험을 상쇄한다.
더 실습해보고 싶은 분들께
에이전트의 내부 상태를 읽고 제어 신호를 만드는 이 패러다임은, 하네스 설계와 루프 엔지니어링의 실전에서 직접 실험해볼 수 있는 영역이다. 동결된 모델 위에 가벼운 제어 계층을 올리는 발상은 모델 자체를 미세조정하는 대안으로 실용적 가치가 크다.
- 『이게 되네? 오픈클로 미친 활용법 50제』 — 에이전트 루프와 도구 사용을 실습하며 체감할 수 있다.
- 「모두를 위한 루프 엔지니어링」 — 제어 신호와 하네스 정책을 직접 설계해보는 데 도움이 된다.
원문: Multi-Head Latent Control: A Unified Interface for LLM Agent Decision Making — Amirhosein Ghasemabadi, Ruichen Chen, Bahador Rashidi, Di Niu (University of Alberta / Huawei Technologies Canada), arXiv:2607.14277, 2026.