Cache-to-Cache, LLM 협업이 텍스트를 건너뛴다

모델끼리 꼭 말로 대화해야 할까

Cache-to-Cache 논문은 멀티 LLM 시스템의 당연한 전제를 건드린다. 지금의 다중 모델 설계는 한 모델이 텍스트를 생성하고, 다른 모델이 그 텍스트를 다시 읽는다. 이 방식은 사람이 보기에는 자연스럽지만 모델 내부 표현에는 손실이 있다. 논문은 source model의 KV cache를 target model의 KV cache와 project and fuse하는 C2C 방식을 제안한다.

arXiv 초록에 따르면 C2C는 개별 모델보다 평균 정확도를 6.4에서 14.2퍼센트 높이고, 텍스트 통신 방식보다 3.1에서 5.4퍼센트 앞서며, 평균 latency는 2.5배 개선했다. 프로젝트 GitHub는 2026년 1월 ICLR 2026 accept 소식을 적고, Hugging Face demo와 fuser weights도 연결한다. 프로젝트 페이지, Hugging Face paper entry, arXiv DOI까지 공개되어 재현 흐름도 비교적 분명하다.

텍스트는 인터페이스이자 병목이다

텍스트는 강력한 공통 인터페이스다. 모델, 사람, 로그, 검색 시스템이 모두 읽을 수 있다. 그러나 모델 내부의 activation space를 텍스트로 바꾸는 순간 많은 정보가 압축되고 순서화된다. 다시 다른 모델이 그 텍스트를 읽으면 원래 표현과 다른 내부 상태가 생긴다. C2C는 이 왕복 번역을 줄이려는 시도다.

이 관점은 vLLM의 AMD speculative decoding, 추론비 경쟁의 다음 축, litelm, LLM 라우팅의 작은 코어를 꺼내다, Bonsai 2 27B, 로컬 AI의 6GB 기준선와 이어진다. 모델 성능 경쟁이 끝난 것이 아니라 추론 경로, 캐시, 라우팅, 압축으로 전장이 넓어졌다.

제품화의 핵심은 투명성이다

C2C가 흥미로운 이유는 속도만이 아니다. 에이전트가 여러 모델을 조합할 때 "왜 이 판단이 나왔는가"를 추적하기 더 어려워질 수 있다. 텍스트 중간 산출물은 사람이 읽을 수 있지만 KV cache 통신은 곧장 관찰하기 어렵다. 따라서 운영 제품에서는 성능 향상과 감사 가능성 사이의 균형을 새로 잡아야 한다.

한국 기업이 바로 C2C를 도입할 가능성은 제한적이다. 모델 쌍별 projector 학습, inference stack 수정, 보안 검토가 필요하다. 그러나 전략적 메시지는 분명하다. 멀티 모델 제품을 만든다면 단순히 API를 여러 개 호출하는 orchestration에서 멈추지 않고, 통신 형식 자체가 성능과 비용을 결정한다는 점을 봐야 한다.

한국 개발자에게 남는 질문

첫째, 사내 에이전트가 모델 간 대화를 모두 텍스트 로그로 남겨야 하는가. 규제 산업에서는 그렇다. 둘째, 내부 표현 통신이 도입될 때 어떤 검증 지표가 필요한가. 평균 정확도, latency, token cost만으로는 부족하다. 셋째, 모델 쌍이 바뀔 때 재학습 비용을 감당할 수 있는가. C2C는 연구적으로 매력적이지만 운영에서는 호환성이 관건이다.

자주 묻는 질문

Q1: C2C는 모델 합치기인가요?

A: 아닙니다. 여러 모델을 하나로 병합하기보다 source model의 KV cache를 target model 쪽으로 projection and fusion하는 통신 방식에 가깝습니다.

Q2: 텍스트 통신보다 왜 빠를 수 있나요?

A: 중간 텍스트를 token by token으로 생성하고 다시 읽는 과정을 줄이기 때문입니다. 논문은 평균 2.5배 latency 개선을 보고합니다.

Q3: 모든 LLM 조합에 바로 쓸 수 있나요?

A: 아닙니다. 모델 쌍에 맞는 projector와 추론 코드가 필요합니다. 실무 적용에는 엔지니어링 비용이 있습니다.

Q4: 보안상 문제는 없나요?

A: 내부 표현 통신은 사람이 읽기 어려워 감사가 까다롭습니다. 민감 업무에서는 로그와 격리 정책을 별도로 설계해야 합니다.

Q5: 지금 당장 배워야 할 점은 무엇인가요?

A: 멀티 에이전트 성능은 프롬프트뿐 아니라 모델 간 통신 매체, 캐시 재사용, 라우팅 구조에서 나온다는 점입니다.