구글, TPU 간 KV 캐시를 빠르게 옮기는 오픈소스 TPU Sync 공개

KV 캐시(키-값 캐시)는 언어 모델이 프롬프트를 읽으면서 만들어 내는 작업 기억입니다. 이미 처리한 토큰마다 중간값을 저장해 두기 때문에 새 단어를 만들 때마다 다시 계산할 필요가 없습니다. 대화나 문서가 길어질수록 이 캐시는 커지며, 보통 가속기 칩의 희소하고 비싼 고대역폭 메모리(HBM)에 놓입니다.

구글은 이 캐시를 자사 AI 프로세서인 TPU(텐서 처리 장치) 사이에서 옮기고 관리하기 위한 오픈소스 네이티브 C++ 라이브러리 TPU Sync를 공개했습니다. TechBytes에 따르면 이는 엔지니어 Fenghui Zhang과 Weiren Yu가 쓴 구글 클라우드 블로그 글을 요약한 것이며, 이 라이브러리는 강화학습 워크플로에서 모델 파라미터를 동기화하는 역할도 합니다. SemiAnalysis는 TPU Sync의 이전 이름이 TPU-raiden이었다고 밝혔고, Open Source For You는 이 프로젝트를 TPU Raiden이라는 이름으로 소개하며 Apache 2.0 라이선스로 공개되었다고 설명합니다.

KV 캐시는 왜 옮겨야 할까요?

Open Source For You에 따르면 언어 모델 추론에는 두 단계가 있습니다. 모델이 프롬프트 전체를 읽는 프리필(prefill)과 답변을 토큰 단위로 생성하는 디코드(decode)입니다. 분리형 서빙은 이 두 단계를 서로 다른 하드웨어 풀에서 실행하므로, 프리필이 끝나면 KV 캐시를 디코드를 맡은 칩으로 보내야 합니다. SemiAnalysis는 전송 라이브러리가 없으면 TPU의 외부 서빙이 통합 모드로 제한된다고 지적합니다. 구글은 Gemini를 위해 내부에서 수년간 분리형 서빙을 운영해 왔습니다.

두 번째 필요는 오프로딩입니다. SemiAnalysis에 따르면 칩의 HBM이 모든 사용자의 캐시를 담지 못할 때 데이터는 HBM에서 호스트의 DRAM으로 갔다가 다시 돌아와야 합니다. The Next Platform이 2026년 11월 9일 전한 바로는, 구글의 AI 및 컴퓨팅 인프라 담당 부사장 겸 총괄 Mark Lohmeyer가 전화 회견에서 에이전트형 워크로드에서는 TPU가 상당한 시간 동안 놀고 있는 경우가 많다고 말했습니다. 그에 따르면 TPU Sync는 에이전트가 멈출 때 작업 기억을 칩 밖으로 옮기고 다시 시작할 때 복원합니다. 그러면 가속기를 다른 작업에 쓸 수 있고 에이전트형 워크로드당 비용이 내려갑니다. The Next Platform은 TPU Sync가 소프트웨어이기 때문에 구글이 이전 세대 TPU 시스템에도 이식할 수 있다고 덧붙입니다.

구글이 내세우는 성능은 어느 정도일까요?

아래 수치는 2026년 11월 9일자 TechBytes에서 나온 것이며, 이 매체는 이를 구글 클라우드 블로그의 내용으로 돌립니다. 구글의 원문은 직접 읽지 못했으므로, 이 수치는 업체가 밝힌 것을 2차 매체가 전한 것으로 봐야 합니다.

• TechBytes에 따르면 매개변수 2,350억 개에서 4,800억 개 규모의 오픈 가중치 전문가 혼합(Mixture of Experts) 모델에서 키-값 전송 지연이 90% 넘게 줄어듭니다.
• TechBytes에 따르면 첫 토큰까지의 시간(TTFT, 답변의 첫 단어가 나타나기까지의 대기 시간)은 프리픽스 캐싱과 분리형 서빙 벤치마크에서 표준 구성과 비교해 평균 90% 줄어듭니다.
• TechBytes에 따르면 raw_transfer 구성요소는 Ironwood TPU v7x 호스트에서 장치와 호스트 사이 양방향 합산 최대 223 GB/s의 처리량을 내며, 이는 PCIe Gen5의 물리적 한계인 256 GB/s에 근접합니다.
• TechBytes에 따르면 데이터센터 네트워크에서 이 소프트웨어는 200 Gbit/s 네트워크 카드 한 장으로 약 192 Gbit/s를, NUMA를 고려한 스트라이핑을 쓴 두 장으로 350 Gbit/s를 유지합니다.

TPU Sync는 내부에서 어떻게 작동할까요?

TechBytes에 따르면 TPU Sync는 데이터 배치를 유지하는 직접 메모리 접근(DMA, 프로세서를 거치지 않고 메모리를 복사하는 하드웨어 방식)과 제자리 버퍼 에일리어싱을 결합합니다. 이 라이브러리는 JAX의 PJRT 버퍼와 PyTorch 텐서를 직접 다루기 때문에 파이썬 직렬화와 중간 복사를 피하며, 전송은 XLA 컴파일 그래프 바깥에서 이뤄집니다. SemiAnalysis는 같은 개념을 PJRT 버퍼의 네이티브 하드웨어 기술자를 추출해 구현하는 제로카피 전송이라고 설명합니다.

TechBytes에 따르면 런타임은 세 개의 모듈로 구성됩니다. 전역 키-값 저장소는 프롬프트 해시를 물리적 저장 블록에 대응시키는 등록부 역할을 하며 가장 오래 쓰이지 않은 항목의 축출을 관리합니다. 클러스터 컨트롤러는 실행 계획과 임대 관리를 맡습니다. 로컬 캐시 관리자는 장치 블록의 상태를 추적하고, 고정된 호스트 메모리를 관리하며, /dev/shm 공유 메모리에 웜 부트용 사본을 유지합니다. 메모리 계층은 HBM, 고정된 호스트 DRAM, 로컬 SSD, 그리고 Google Cloud Managed Lustre에 걸쳐 있습니다.

통합과 관련해 TechBytes는 TorchTPU를 통한 PyTorch용 공식 바인딩, JAX용 공식 바인딩, vLLM·SGLang·llm-d 서빙 스택용 커넥터, 그리고 Pathways와 멀티 컨트롤러 JAX 파이프라인용 저수준 프리미티브를 꼽습니다.

한계와 성숙도는 어떨까요?

TechBytes는 HBM과 호스트 DRAM 사이의 전송은 프로덕션에 쓸 수 있는 수준이지만, Managed Lustre나 외부 POSIX 백엔드 같은 공유 스토리지로의 계층화는 아직 실험적으로 검증 중이라고 밝힙니다. 강화학습용 가중치 동기화 모듈도 실험적이며, 최대 네트워크 처리량을 얻으려면 NUMA를 고려한 스트라이핑을 제대로 설정한 200 Gbit/s 네트워크 카드 두 장이 필요합니다. 날짜가 없는 Open Source For You의 기사는 한발 더 나아가 이 프로젝트가 아직 활발히 개발 중이며 일반적인 프로덕션 용도로는 의도되지 않았다고 말해, 성숙도에 대한 그림은 출처마다 다릅니다.

SemiAnalysis는 경쟁 구도의 관점을 더합니다. 이 회사의 InferenceX 프리뷰는 통합형 TPU v7을 통합형 Nvidia B200 및 B300과 비교하며, 분리형 서빙에서는 Nvidia의 GB200과 GB300 NVL72 시스템이 곡선의 일부 구간에서 현재 앞선다고 말합니다. TPU-Sync 기반 분리형 서빙이 외부 스택에서 최적화되면 분리형 TPU v7과의 비교가 이뤄질 예정이며, SemiAnalysis는 TPU의 Mooncake Store 지원이 TPU-Sync 프리미티브 위에 만들어질 것으로 예상합니다.

기업에는 무엇이 달라질까요?

구글 클라우드에서 긴 컨텍스트의 어시스턴트와 에이전트를 운영하거나 임대하는 한국 기업에게 KV 캐시 이동은 직접 구축할 일에서 설정해 쓰는 일로 바뀝니다. 실무 단계는 자사 프롬프트로 vLLM이나 SGLang과의 커넥터를 시험하고, 도입 전후의 첫 토큰까지의 시간을 측정하며, 의존하기 전에 어떤 메모리 계층이 아직 실험적으로 표시되어 있는지 확인하는 것입니다. 강화학습으로 훈련하는 팀은 자체 트레이너와 샘플러 구성에서 가중치 동기화 모듈을 검증해야 합니다. 공개된 수치 어느 것도 자사 워크로드에 대한 벤치마크를 대신하지 못합니다.