서로 다른 회사의 AI 모델을 한 팀으로 묶어 쓰면 같은 문서를 여러 번 읽는 낭비가 생긴다. 앞 모델이 긴 자료를 읽고 정리해 넘기면, 받은 모델은 그 자료를 처음부터 다시 읽는다. HeteroFold는 이 다시 읽기를 없앤다. 앞 모델이 읽으며 내부에 만들어 둔 중간 계산을, 뒤 모델이 그대로 넘겨받아 쓴다.
성과부터. 32K 토큰 문맥에서 Llama-3.1-8B가 읽은 내용을 Ministral-3-14B로 넘길 때, 받는 쪽이 통째로 다시 읽는 방식보다 10배 넘게 빨랐다. 여러 에이전트가 소통하며 결정을 내리는 벤치마크에서는 텍스트로 주고받는 방식과 대등한 정확도를 냈다. 토크나이저(글을 토큰이라는 작은 조각으로 쪼개는 방식)도 다르고 층 수도 다른, 계열이 완전히 다른 모델들 사이에서 이게 됐다는 게 핵심이다.
그런데 이 연구에서 가장 눈여겨볼 대목은 속도가 아니다. 캐시를 원본과 더 비슷하게 복원한 방법이 오히려 더 나빴다는 결과다. 여기부터 풀어보자.
LLM은 프롬프트를 읽을 때 토큰마다 키·값(KV)이라 부르는 벡터를 계산해 저장해 둔다. 뒤이어 답을 생성할 때 앞부분을 다시 계산하지 않으려는 메모장이다. 이 메모장이 KV 캐시, 받은 글을 처음부터 끝까지 한 번 훑어 메모장을 채우는 과정이 프리필(prefill)이다.
문제는 보낸 쪽이 이미 똑같은 프리필을 끝냈다는 점이다. 그 메모장을 버리고, 받는 쪽이 같은 글을 다시 훑는다. 문맥이 길수록 이 중복은 빠르게 불어난다. 멀티에이전트 시스템이 역할마다 다른 모델을 쓰는 요즘(논문은 풀이·평가·종합에 서로 다른 계열 모델을 배치하는 X-MAS를 예로 든다), 단계를 넘길 때마다 이 비용을 다시 치른다.
같은 계열 모델끼리면 된다. 계열이 다르면 세 군데가 어긋난다. 토크나이저가 달라 같은 문장을 다른 조각으로 쪼개고, 층 수가 달라 몇 번째 층의 정보를 어디에 맞출지 모호하고, KV의 수치 분포와 구조 자체가 다르다.
번역가 둘이 같은 책을 나눠 읽는 상황을 떠올리면 된다. 한 명이 적어둔 주석을 넘겨주려 해도 표기법도, 노트 쪽수 매기는 법도, 속기 방식도 달라 그대로는 못 쓴다. 메모장을 넘기려면 받는 사람 방식으로 번역부터 해야 한다.
여기서 자연스러운 생각이 든다. 보낸 쪽 메모장을 받는 쪽 메모장과 최대한 비슷하게 바꿔주면 되지 않나. 숫자가 가까울수록 좋은 번역 아닌가.
아니었다. 기존 방법인 KV Ridge는 HeteroFold보다 캐시를 더 비슷하게 복원해 놓고도, 정작 받는 쪽의 어텐션(attention, 모델이 지금 어느 토큰에 집중할지 정하는 장치)을 망가뜨렸다. 숫자는 더 가까운데 결과는 더 나빴다.
이유는 이렇다. 메모장의 숫자 자체는 목적이 아니다. 그 숫자가 받는 쪽에서 만들어낼 이후 계산이 진짜 목적이다. 숫자를 평균적으로 가깝게 맞추는 데 집중하면, 받는 모델이 실제로 쓰는 방식과는 어긋날 수 있다. 그래서 HeteroFold는 복원 오차를 줄이는 대신, 받는 쪽이 그 캐시로 만들어낼 어텐션과 출력을 기준으로 변환을 맞춘다. 이 방향 전환이 이 논문의 중심이다.
변환은 네 단계다.
토큰 맞추기. 토크나이저가 다르면 같은 글자열도 다르게 끊긴다. 논문 예로 "unbelievable"을 한쪽은 한 토큰으로 묶지만, 다른 쪽은 "unbel / iev / able"로 쪼갠다. 그래서 토큰 번호를 1:1로 맞추지 않고, 양쪽이 공유하는 글자 경계를 기준으로 맞춘다. 받는 쪽 경계에 딱 맞는 상태가 없으면 바로 앞 공유 경계의 상태를 쓴다. 중요한 건 겹치는 조각들을 평균 내지 않는 것이다. 모델은 글을 앞에서부터 순서대로 읽으니, '여기까지 읽은 상태'를 뭉개 평균 내면 의미가 망가진다.
층 맞추기. 받는 쪽이 필요한 정보가 보낸 쪽 여러 층에 흩어져 있다. 그래서 받는 층 하나에 보낸 층 하나만 대응시키지 않고, 깊이 비율로 맞춘 지점 주변의 세 층을 함께 가져온다. 한 층만 쓸 때보다 이웃 세 층을 묶을 때 받는 쪽 예측이 더 정확했다.
색 맞추기(Recolor). 토큰별 오차만 줄이면 전체 분포가 어긋난 채 어텐션이 틀어진다. 그래서 받는 쪽 특징의 평균과 퍼짐 정도(공분산)를 맞춘다. 사진 색 보정과 같다. 톤이 다른 사진을 받는 쪽 톤에 맞춰 갈아끼운다.
출력 기준 보정. 색까지 맞춰도 어텐션 패턴과 최종 출력이 똑같아지진 않는다. 남은 오차를, 받는 쪽의 실제 질의(query, 어텐션에서 '지금 무엇을 찾는가'를 담은 벡터)·어텐션·값·출력을 기준으로 메운다. 이때 전체를 뜯어고치지 않고 중요한 방향 몇 개만 골라 더하는 가벼운 보정표를 쓴다(저계수, 수많은 숫자를 다 바꾸는 대신 핵심 방향 몇 개로만 고치는 방식). 키 보정과 값 보정을 따로 둔 게 핵심인데, 출력 차이는 '어디에 집중할지'의 변화와 '끌어온 값'의 변화로 나뉘고, 앞쪽은 키가 뒤쪽은 값이 맡는다.
마지막은 폴딩(folding)이다. 위에서 맞춘 보정들을 따로 두지 않고, 처음의 고정 변환식 하나에 미리 접어 넣는다. 그래서 실제로 쓸 때는 받는 층·역할마다 고정 변환 하나만 통과시키면 되고, 보정용 추가 신경망도 받는 쪽 재프리필도 없다.
한 가지는 분명히 하자. 이 과정에서 두 모델의 가중치는 전혀 건드리지 않는다. 새로 맞추는 건 모델이 아니라, 캐시를 바꾸는 변환표 하나뿐이다. 그 변환표는 소량의 데이터로 오프라인에서 한 번 맞춰 두고, 그다음부터는 모델을 그대로 둔 채 그 표만 통과시킨다.
층 맞추기는 특징을 평평하게 펴서 섞으므로, 어텐션을 나눠 맡는 갈래(헤드) 개수가 달라도 교차 매핑이 된다. 색 맞추기는 두 특징 공간을 화이트닝(원래 크기·상관을 제거)한 뒤 프로크루스테스 정렬(회전으로 두 집합을 겹치는 방법)로 맞추고, 받는 쪽의 공분산·평균을 다시 입힌다. 폴딩이 접어 넣는 고정 변환식은 선형변환에 이동을 더한 아핀 맵(affine map)이다.
실험은 Llama-3.1-8B, Qwen3-4B, Ministral-3-14B 셋을 얼려(가중치를 고정해) 쓰고, 셋 사이의 방향 있는 전송 여섯 가지를 모두 쟀다. 과제는 긴 문맥 QA 네 종, 짧은 문맥 QA 다섯 종, 그리고 여러 에이전트가 라운드를 거듭하며 소통하는 HiddenBench다.
먼저 토큰 맞추기가 왜 결정적인지. 토큰 번호만 억지로 맞춘 방법들은 사실상 무너졌다. 2지선다 문제에서 50% 안팎, 무작위로 찍어도 나오는 수준이고, 숫자 답을 요구하는 GSM8K에서는 전반적으로 매우 낮았다. 그런데 토큰 맞추기(앞의 1단계)를 붙이면 많은 구간이 확 산다. 교차 계열 전송의 첫 장벽이 토크나이저였다는 뜻이다.
그 위에서 HeteroFold가 한 번 더 앞선다. 긴 문맥 네 종에서 캐시 전송 방법 중 전 방향 최고였고, 짧은 문맥에서도 대부분 최고였다. 다만 긴 문맥 단일 질문 QA에서는 텍스트로 다 넘기는 기준선(TextMas)과 아직 격차가 남는다. 이건 숫자가 그대로 보여준다.
속도 이득은 문맥이 길수록 커진다. 같은 전송 방향에서 4K는 재프리필 대비 3.75배, 32K에서는 10.74배로 벌어진다. 공유 문맥이 짧으면 득이 작고, 길수록 커지는 구조다.
가장 흥미로운 반전은 HiddenBench다. 15라운드 뒤 다수결 정확도에서 HeteroFold는 29.2%, 텍스트로 주고받은 TextMas는 27.7%였다(둘 다 11.5%에서 출발). 단일 질문에서는 텍스트에 못 미치던 캐시 전송이, 정작 에이전트가 새 정보를 만들어 주고받는 실제 멀티에이전트 상황에서는 오히려 살짝 앞섰다. 앞에서 던진 '복원이 아니라 이후 계산을 맞춘다'는 방향이 여기서 보상을 받는다.
잃는 것도 분명하다. 논문이 스스로 인정한 한계가 둘. 색 맞추기의 공분산 정합은 수치 안정화 때문에 실제로는 근사이고, 짧은 문맥을 전부 이긴 것도 아니다. Ministral-3-14B에서 Qwen3-4B로 넘기는 방향의 일부 과제처럼 기존 방법이 근소하게 앞서는 칸이 남아 있다.
F1은 답이 정답과 얼마나 겹치는지를 0~100으로 매긴 점수다. Qwen3-4B에서 Llama-3.1-8B로 넘기는 방향의 Qasper에서 HeteroFold 29.12, KV Ridge+TA 16.06, 텍스트 기준선 44.64. HiddenBench 평균 정확도는 30.6%(HeteroFold) 대 29.2%(TextMas). 지연은 중간 지점 16K에서 8.11배로, 4K(3.75배)와 32K(10.74배) 사이에 놓인다.
구체적인 장면 하나로 좁히자. 어떤 고객이 프로젝트 중간에 납기를 앞당겨 달라고 요청한다. 온틀의 AI PM은 이 요청을 접수에서 검토, 진행으로 넘긴다. 이때 지금까지 쌓인 프로젝트 맥락 — 고객 명세, 첨부 자료 요약, 이전 라운드의 결정 — 이 단계를 넘을 때마다 다음 모델에게 다시 전달되고, 그 모델은 긴 맥락을 처음부터 다시 읽는다. 프로젝트가 길게 누적될수록 이 반복 읽기가 커진다. HeteroFold가 겨냥하는 바로 그 상황이다.
그렇다고 당장 꽂을 부품은 아니다. HeteroFold는 받는 모델 내부(KV·층·질의·어텐션)에 직접 손대 보정을 맞춰야 한다. 내부를 열 수 없는 상용 클로즈드 API 모델에는 못 쓴다. 지금 온틀은 상용 API를 라우팅하므로 전제가 바로 서지 않는다. 그래서 전면 도입이 아니라, 이 한 구간만 떼어 작은 PoC로 검증하는 것을 제안한다.
PoC 설계는 이렇게 잡는다.
도입 기준은 미리 못 박는다. 품질이 텍스트 방식과 사람 눈에 구분되지 않을 만큼 대등하고, 긴 맥락 구간에서 전환 지연이 뚜렷이 줄고, 변환표 준비 비용이 그 구간 호출 빈도로 감당할 만큼 회수되면 — 그 구간부터 오픈웨이트 모델과 캐시 전송으로 바꾼다. 셋 중 하나라도 어긋나면 보류하고, 오픈웨이트 운용 전략과 함께 이 기술의 성숙도만 계속 지켜본다.
에이전트들이 서로 소통하기 전, 각자 독립으로 먼저 투표한 정확도다. 그다음 15라운드 동안 사적 정보를 교환한 뒤 다시 투표해 29.2%와 27.7%로 오른다. 같은 출발점에서 비교했기에, 소통이 실제로 성과를 끌어올렸고 그 끌어올림이 캐시 전송에서도 유지됐다는 걸 보여준다.
받는 쪽이 캐시를 잘못 넘겨받으면 형식이 깨진 답, 즉 무효 응답이 는다. HeteroFold는 무효 응답이 3.2%로 텍스트 방식(4.0%)보다 낮았다. 반면 캐시를 잘못 넘긴 KV Ridge의 한 변형은 무효가 20.9%까지 치솟아 받는 모델을 불안정하게 만든 흔적이 뚜렷했다. 평균 점수만이 아니라, 받는 모델을 망가뜨리지 않았다는 신호로 본다.
전송은 방향마다 따로다. 모델 셋에 방향 있는 전송이 여섯 가지였던 것처럼, 모델 수가 늘면 조합이 늘고 각 조합의 표를 오프라인에서 따로 맞춰야 한다. 모델을 많이 섞을수록 준비 비용이 그만큼 커진다.
긴 문맥에서는 키 보정이 이득의 대부분을 낸다. 일부 과제에서는 키 보정만 넣은 쪽이 키와 값을 다 넣은 최종보다 약간 높기도 했다. 값 보정은 평균적으로는 도움이 되지만, 과제에 따라 소폭 상쇄로 작용할 수 있다는 뜻이다.