기술 요약: 장시간 LLM 에이전트 서빙을 위한 병렬 컨텍스트 압축

1. 문제 제기

장시간 (Long-horizon) 대규모 언어 모델 (LLM) 에이전트는 대화 기록이 지속적으로 성장하여 결국 모델 컨텍스트 창을 초과하는 세션에서 작동합니다. LLM 기반 요약화를 통한 컨텍스트 압축이 표준적인 해결책이지만, 저자들은 현재 순차적 동기식 (sequential synchronous) 접근법에서 세 가지 치명적인 한계를 확인했습니다.

1. 손실적이고 예측 불가능한 출력: 요약화는 본질적으로 손실적입니다. 특히 요약의 양은 입력 길이와 프롬프트 지시사항과 거의 무관합니다. 입력 컨텍스트가 2k 에서 96k 토큰으로 증가함에 따라 모델은 출력을 스스로 제한하여 원래 정보의 극히 일부 (토큰의 약 48% 에서 약 3% 로 감소) 만 유지합니다.
2. 실행 간 불안정성: 동일한 입력과 프롬프트를 사용하더라도 요약의 길이와 의미적 내용은 실행마다 크게 변동합니다. 이러한 불안정성은 에이전트 행동의 재현성을 어렵게 만들고 메모리 예산 편성을 복잡하게 합니다.
3. 지연 시간 병목 현상: 순차적 압축은 에이전트 추론을 멈추게 하는 차단 호출 (blocking call) 을 필요로 합니다. 장시간 흐름에서는 이 오버헤드가 특히 낮은 임계값에서 압축이 자주 발생할 때 전체 종단 간 (E2E) 월 시간의 최대 62% 를 소모할 수 있습니다.

또한, 이 논문은 "간결한" 대 "상세한" 요약과 같은 프롬프트 엔지니어링이 요약 양에 대한 세밀한 제어를 제공하지 못한다고 지적합니다. 모델들은 훈련 데이터에서 유래된 요약 길이에 대한 내재화된 사전 확률로 돌아가는 경향이 있기 때문입니다.

2. 방법론

실험 설정

저자들은 다양한 규모와 아키텍처를 아우르는 **네 가지 백본 (backbones)**에 걸쳐 접근법을 평가했습니다.

• Llama-3.1-8B (소형, 밀집형)
• gpt-oss-20B (중형, MoE, 추론)
• Llama-3.3-70B (대형, 밀집형)
• gpt-oss-120B (대형, MoE, 추론)

평가는 두 가지 벤치마크에서 수행되었습니다.

• HotpotQA: 누적 증거에 대한 다중 홉 질문 응답.
• LoCoMo: 세션당 여러 개의 QA 를 포함하는 장컨텍스트 다중 세션 대화.

제안된 솔루션: 병렬 압축

이 논문은 단일 차단 요약 호출을 동시 처리로 대체하는 블록 기반 설계인 **병렬 압축 (Parallel Compaction)**을 소개합니다. 워크플로우는 세 단계로 구성됩니다.

1. 스냅샷 및 파티셔닝: 대화 기록이 복사되어 $N$개의 연속된 블록으로 분할되며, 각 블록의 크기는 $B$ 토큰입니다.
2. 전송 (Dispatch): 각 블록 $k$는 별도의 워커에 의해 처리됩니다. 중요한 점은 워커 $k$의 프롬프트에는 블록 $k$까지의 전체 대화 기록이 포함되며, 블록 $k$ 자체는 <TARGET_BLOCK> 마커로 감싸진다는 것입니다.
   • 접두사 인식 타겟-엔드 레이아웃: 이 설계는 각 워커가 대상 블록 앞에 있는 인과적 기록 (블록 간 컨텍스트 보존) 을 보면서도, 대상 블록이 주의가 가장 강한 프롬프트의 끝에 위치하도록 보장합니다. 이 레이아웃은 vLLM 서버 내 워커 간 접두사 캐시 재사용을 가능하게 합니다.
3. 병합 (Merge): 모든 워커가 완료되면, $N$개의 블록별 요약이 연결되어 압축된 기록을 형성합니다.

3. 주요 기여 및 특성 분석

순차적 압축의 특성 분석

저자들은 순차적 압축이 다음과 같은 고통을 겪음을 실증적으로 증명했습니다.

• 입력/프롬프트 불변성: 입력 길이가 48 배 증가함에도 불구하고 출력 토큰 수는 거의 평평하게 유지됩니다 (약 3 배만 증가). 길이에 대한 프롬프트 지시사항의 영향은 미미합니다.
• 불안정성: 컨텍스트 길이가 증가함에 따라 출력 길이의 변동 계수 (CV) 와 코사인 유사도 (의미적 일관성) 의 감소가 증가하여 결과가 예측 불가능해집니다.
• 최적 블록 크기: 분석 결과, 4k 토큰이 컨텍스트 보존과 출력 일관성 사이의 최선의 균형을 제공하는 요약화를 위한 가장 안정적인 입력 크기임을 밝혔습니다.

병렬 압축의 특성 분석

병렬 압축은 다음과 같은 방식을 통해 순차적 베이스라인의 한계를 해결합니다.

• 세밀한 제어: 연산자는 **블록 크기 ($B$)**를 통해 요약 양을 직접 제어할 수 있습니다. 더 작은 블록은 더 많은 병렬 워커와 더 높은 총 출력 토큰 수를 초래하여 더 많은 컨텍스트를 보존합니다.
• 복원된 프롬프트 민감성: 순차적 베이스라인과 달리, 병렬 압축은 프롬프트 지시사항 (예: "매우 상세한") 이 각 블록 내에서 출력 양을 효과적으로 조정할 수 있게 하여, 블록 크기 + 프롬프트 상세도라는 이축 제어 메커니즘을 제공합니다.
• 처리량 개선: 워크로드를 병렬화하고 접두사 캐싱을 활용함으로써 시스템은 더 높은 압축 처리량을 달성합니다.

4. 결과

정확도 및 정보 보존

• 정확도 향상: HotpotQA 와 LoCoMo 모두에서 블록 크기를 줄임 (병렬화 증가) 에 따라 하류 QA 정확도가 단조 증가했습니다. 16k 블록 크기 (가장 적은 워커) 는 가장 적은 토큰과 가장 낮은 정확도를 생성한 반면, 더 작은 블록 (예: 2k) 은 더 많은 컨텍스트를 보존하고 정확도를 향상시켰습니다.
• 컨텍스트 보존: 병렬 압축은 시스템이 순차적 베이스라인 (~3%) 에 비해 원래 컨텍스트의 훨씬 더 높은 비율 (작은 블록과 상세한 프롬프트로 최대 약 50%) 을 보존할 수 있게 합니다.

시스템 성능 (월 시간 및 처리량)

• 종단 간 속도 향상: 병렬 압축은 대부분의 구성에서 E2E 월 시간을 단축했습니다. 예를 들어, HotpotQA 를 사용하는 120B 모델에서 병렬 압축 (2k 블록) 은 순차적 방식 대비 1.28 배의 속도 향상을 달성했습니다.
• 처리량: 일치된 압축 디코드 볼륨에서 병렬 압축은 일관되게 순차적 베이스라인을 능가했습니다. 예를 들어, 70B 모델은 일치된 토큰 수에서 2.13 배의 처리량 개선을 보였습니다.
• 프리필 (Prefill) 오버헤드: 논문은 매우 큰 블록 크기 (예: 16k) 는 워커당 프롬프트의 고유 부분이 크고 캐시되지 않아 프리필 오버헤드로 고통받을 수 있으며, 이로 인해 일부 병렬화 이득이 상쇄될 수 있다고 지적합니다. 더 작은 블록 (2k–4k) 은 이 균형을 최적화합니다.

5. 중요성 및 주장

이 논문은 병렬 압축이 오프라인 훈련, 검색 인프라, 또는 화이트박스 모델 접근이 필요 없이 장시간 에이전트 서빙을 위한 실용적이고 인프라에 구애받지 않는 솔루션을 제공한다고 주장합니다.

• 예측 가능성: 컨텍스트 압축을 예측 불가능하고 손실적인 프로세스에서, 연산자가 블록 수와 프롬프트 엔지니어링을 통해 컨텍스트 보존과 요약 양 사이의 균형을 정밀하게 제어할 수 있는 조정 가능한 시스템으로 변환합니다.
• 효율성: 동기식 압축의 지연 시간 병목 현상을 완화하여 더 높은 처리량과 빠른 에이전트 추론 사이클을 가능하게 합니다.
• 안정성: 작고 안정적인 4k 블록에서 작동함으로써 거대한 컨텍스트를 요약할 때 내재된 실행 간 변동을 줄여 더 재현 가능한 에이전트 행동을 유도합니다.

저자들은 최적의 작동 지점이 반드시 최대 컨텍스트 보존이 아니라, 작업에 필요한 고신호 토큰의 "최소 충분" 집합이라고 결론지으며, 병렬 압축은 연산자가 이 목표를 정밀하게 달성할 수 있게 해준다고 말합니다.