Skip to content
AI-Daily-Builder

arXiv 2606.09659·2026-06-09 — 회 조회

Latent Context Language Models: 350B 토큰으로 훈련한 encoder-decoder 압축이 KV-cache 프루닝을 제압——16배 압축에서도 GSM8K 81%, 베이스라인은 0%로 추락

Ang Li, Sean McLeish, Haozhe Chen, Nimit Kalra, Zaiqian Chen, Artem Gazizov, Venkata Anoop Suhas Kumar Morisetty, Bhavya Kailkhura, Harshitha Menon, Zhuang Liu, Brian R. Bartoldson, Tom Goldstein, Sanae Lotfi, Micah Goldblum, Pavel Izmailov

Goldstein, Goldblum, Izmailov 그룹을 아우르는 15인 저자 팀이 encoder-decoder 방식의 컨텍스트 압축을 본격적인 스케일로 부활시켰다. 0.6B 인코더와 4B 디코더를 약 350B 토큰으로 훈련해 속도·메모리·정확도의 새로운 파레토 프런티어를 달성했고, 모델과 코드를 모두 공개했다.

arxiv.org/abs/2606.09659 ↗

무엇이 발표되었나

「End-to-End Context Compression at Scale」(arXiv:2606.09659, cs.CL, 2026년 6월 8일 제출)라는 제목의 논문은, 연구 커뮤니티 대부분이 “해봤는데 손실이 너무 크다”며 서랍에 넣어두었던 아이디어——encoder-decoder 방식의 컨텍스트 압축——를 다시 꺼내 이렇게 묻는다. 이것을 덧붙이는 트릭으로 취급하지 않고, 사전학습급 스케일로 제대로 훈련하면 무슨 일이 벌어지는가? 15인의 저자 팀은 Tom Goldstein, Micah Goldblum, Pavel Izmailov의 연구 그룹에 걸쳐 있으며, 공저자로 Zhuang Liu, Sanae Lotfi, Brian Bartoldson, Bhavya Kailkhura, Sean McLeish 등이 참여했다.

동기가 된 문제는 모든 롱컨텍스트 배포가 부딪히는 바로 그것이다. KV 캐시는 컨텍스트 길이에 비례해 선형으로 증가하고, 수십만 토큰 규모가 되면 병목은 가중치가 아니라 캐시 자체가 된다. 기존 KV-cache 압축 기법은 품질을 크게 떨어뜨리거나, 긴 프롬프트 하나를 압축하는 데만 상당한 시간과 연산을 소모한다. 저자들의 답은 **Latent Context Language Models(LCLMs)**다. 작은 인코더가 긴 토큰 시퀀스를 훨씬 짧은 잠재 임베딩 시퀀스로 사상하고, 디코더는 원시 토큰 대신 그 잠재 벡터를 읽는다.

작동 방식

아키텍처는 의도적으로 단순하다. 0.6B 파라미터 인코더(Qwen3-Embedding에서 초기화)가 고정 1024토큰 윈도우로 컨텍스트를 읽고, N개 토큰씩 평균 풀링해 하나의 잠재 벡터로 만든다. MLP 어댑터가 이 잠재 벡터를 4B 파라미터 디코더(Qwen3-4B-Instruct에서 초기화)의 임베딩 공간으로 투영한다. 팀은 1:4, 1:8, 1:16 세 가지 압축률의 변형을 훈련했다.

진짜 하중을 떠받치는 부분은 훈련 예산이다. 각 모델은 4단계 파이프라인——어댑터 워밍업, 인코더 훈련, 지속 사전학습, 그리고 지도 미세조정——을 거쳐 총 약 3,500억 토큰을 소화한다. 훈련 데이터에는 압축 블록과 비압축 블록이 교차로 배치되고 보조 재구성 과제도 더해진다. 기존 압축기 논문들은 기껏해야 수십억 토큰의 미세조정에 그쳤다. 이 레시피가 진짜 지속 사전학습 스케일까지 밀어붙여진 것은 처음이며, 저자들이 기여를 새로운 메커니즘이 아니라 “at scale”로 규정한 이유도 거기에 있다.

숫자들

SnapKV, KVzip, FastKVzip, Expected Attention, Attention Matching이라는 강력한 KV-cache 압축 베이스라인들을 상대로, 논문은 범용 과제 성능·압축 속도·피크 메모리 세 축에서 새로운 파레토 프런티어를 보고한다.

미래를 내다본 에이전트 실험도 있다. 디코더가 압축된 컨텍스트를 훑어본 뒤 EXPAND 도구를 호출해 원문이 그대로 필요한 청크의 원래 텍스트를 가져오는 방식으로, 건초더미에서 바늘 찾기 과제의 정확한 문자열 일치 정확도를 크게 끌어올렸다. 모든 것이 공개되어 있다——모델은 Hugging Face(latent-context), 코드는 GitHub(LeonLixyz/LCLM)에 있다.

빌더가 주목해야 하는 이유

이 논문의 실무적 주장은, 컨텍스트 압축은 사후 캐시 수술이 아니라 훈련된 능력일 때 비로소 작동한다는 것이다. 이 구분은 세 부류의 독자 모두에게 중요하다. 롱컨텍스트 워크로드를 서빙하고 있다면, TTFT와 메모리 수치는 가장 아픈 두 개의 비용 곡선을 동시에 공격한다. 인코더가 작아서 배치 처리가 저렴하기 때문이다. 에이전트를 만들고 있다면, “훑어본 뒤 EXPAND” 패턴은 진짜 새로운 메모리 계층이다. 원시 히스토리를 다시 읽는 것보다 싸고, 텍스트 요약보다 충실하며, 필요할 때 무손실로 복원할 수 있다. 모델을 훈련하고 있다면, 이 결과는 350B 토큰의 투자가 프루닝 기법으로는 어떤 비용을 치러도 살 수 없는 16배 컨텍스트 할인을 살 수 있다는 증거로 읽힌다——평균 컨텍스트 길이가 두 배가 될 때마다 이 거래는 더 매력적이 된다.

솔직한 단서도 달아두자. 공개된 디코더는 4B 파라미터로, 이 레시피가 프런티어급 모델에서 성립한다는 것은 아직 아무도 보여주지 않았다. 훈련 비용은 실재하며 압축기를 만드는 쪽이 부담한다. 16배 압축에서의 GSM8K 수치는 인상적이지만 하나의 과제군일 뿐이다. 0% 베이스라인과의 비교도 이 설정에 유리하게 작용한다. 캐시 프루닝 기법은 애초에 94% 축출률을 위해 설계된 것이 아니기 때문이다.

실무자 노트

내가 오늘 롱컨텍스트 서빙 스택을 운영하고 있다면, 이 결과가 내 환경으로 이전된다고 믿기 전에 공개된 1:4 모델을 내 실제 트레이스에서 기존 SnapKV류 파이프라인과 맞붙여 볼 것이다——이 실험은 저렴하다. 가중치와 코드가 공개되어 있고 디코더는 겨우 4B이기 때문이다. 내가 지켜볼 지표는 평균 정확도가 아니라 실패 모드다. 프루닝은 사실을 조용히 떨어뜨리는 방식으로 실패하고, 훈련된 압축기는 사실을 흐릿하게 만드는 방식으로 실패한다. 그리고 EXPAND 도구 패턴은 두 번째 실패에는 복구 경로를 주지만 첫 번째 실패에는 존재하지 않는다. 에이전트 빌더라면 원시 로그를 정답 소스로 남겨두더라도 지금 당장 압축 메모리를 프로토타이핑하기를 권한다. 오래된 턴을 잠재 벡터로 저장하고, 필요할 때 펼치고, 에이전트가 실제로 펼침을 필요로 하는 빈도를 측정하라. 그 비율이 당신의 진짜 압축 예산을 알려준다.

과소평가된 관점

이 논문의 조용한 함의는 아키텍처가 아니라 경제에 있다. KV-cache 프루닝은 압축을 서빙 계층에 가둬두었고, 모든 제공자가 요청마다, 영원히 비용을 지불한다. LCLMs는 그 비용을 훈련 쪽으로 옮겨 한 번만 지불하고 미래의 모든 요청에 상각한다——인스트럭션 튜닝이 프롬프트 엔지니어링을 이긴 것과 같은 종류의 전환이다. 이 레시피가 디코더 크기와 함께 스케일된다면, “컨텍스트 압축”은 추론 최적화이기를 멈추고 출하하고 버전 관리하고 미세조정할 수 있는 모델 능력이 된다. 추적할 가치가 있는 열린 질문은 프런티어 랩들이 encoder-decoder 분리를 채택할지, 아니면 압축기를 모델 본체에 접어 넣을지다. 어느 길이든, 이 논문이 공표한 350B 토큰이라는 가격표는 이 능력을 구축하는 비용에 대한 첫 번째 신뢰할 만한 견적이다.

커피