TensorCast란 무엇이며, 대규모 AI 추론을 어떻게 바꾸나

대규모 언어 모델(LLM)을 서비스할 때 병목은 계산 능력만이 아니다. 모델 가중치를 메모리에 올리고, 여러 GPU와 노드 사이에서 KV 캐시를 옮기며, 중간 텐서 상태를 필요한 위치에 배치하는 작업도 상당한 시간을 차지한다.

베이징대학교, AI 기업 StepFun, 베이징우전대학교 연구진이 제안한 TensorCast는 이 문제를 텐서 수명주기 관리라는 별도 시스템 계층으로 분리하려는 접근이다. 연구진은 이를 **‘Tensor-as-a-Service(TaaS)’**라고 부른다. TensorCast는 텐서를 생성하거나 사용하는 계산 엔진과 독립적으로 텐서의 식별, 소유권, 위치, 이동, 변환, 공유, 메모리 구체화(materialization)를 관리한다. 1

왜 TensorCast가 필요한가

기존 LLM 인프라에서는 모델 가중치 로더, 추론 엔진, 요청 스케줄러, KV 캐시 백엔드, 네트워크 전송 계층, 저장 시스템이 각자 텐서 상태를 관리하는 경우가 많다. 가중치는 비교적 정적이지만, KV 캐시는 멀티턴 대화가 진행될수록 계속 생성되고 갱신되며 여러 워커 사이에서 재사용될 수 있다. 중간 상태 역시 작업과 자원 상황에 따라 위치가 달라진다. 1

이처럼 관리 기능이 여러 구성 요소에 나뉘면 새로운 최적화 정책을 적용할 때마다 각 시스템을 함께 수정해야 한다. 예를 들어 KV 캐시의 위치를 고려해 요청을 라우팅하거나, 이미 로드된 가중치를 다른 추론 인스턴스가 재사용하도록 만들려면 라우터·추론 엔진·캐시·스토리지 계층 사이의 조정이 필요하다.

TensorCast는 이 문제를 공통 추상화 계층으로 해결하려 한다. 애플리케이션은 텐서 상태에 대해 ‘어디에 배치할지’, ‘언제 미리 가져올지’, ‘어떤 형태로 변환할지’ 같은 정책을 작성하고, 실제 분산 실행과 데이터 이동은 런타임이 담당한다. 1 일반적인 오브젝트 스토리지가 데이터를 불투명한 블롭으로 다루는 것과 달리, TensorCast는 텐서를 위치와 수명주기를 가진 1급 객체로 취급한다.

TensorCast의 핵심 설계

1. 텐서를 1급 객체로 관리

TensorCast에서 텐서는 명시적인 식별자, 소유권, 배치 위치, 수명주기 의미를 가진다. 따라서 추론 엔진은 특정 가중치나 KV 캐시 블록을 가리킬 때 그것이 어느 노드의 GPU에 있는지, 어떤 저장 매체에 저장됐는지를 직접 알 필요가 없다. 1

2. 조합 가능한 수명주기 연산

개발자는 이동, 변환, 프리페치, 복제, 메모리 구체화 같은 기본 연산을 조합해 작업별 정책을 만들 수 있다. 새로운 최적화를 적용할 때마다 네트워크나 저장 시스템의 저수준 구현을 다시 고치는 대신, 텐서 관리 프로그램을 작성하는 방식이다. 1

3. 정책과 실행 메커니즘의 분리

TensorCast API로 작성한 정책은 ‘무엇을 할지’를 표현한다. 런타임은 ‘어떻게 분산 실행할지’를 결정한다. 이 구조를 통해 기본 실행 엔진을 대폭 수정하지 않고도 텐서 배치나 이동 정책을 바꿀 수 있다. 1

4. 제어 평면과 데이터 평면의 분리

TensorCast의 **Global Store(GS)**는 워커와 노드의 상태, 텐서 위치, 소유권, 스케줄링 정보 같은 메타데이터를 관리한다. 실제 텐서 데이터는 Worker가 이동시킨다. GS가 텐서 페이로드까지 직접 운반하지 않기 때문에 중앙 조정 계층이 데이터 전송 병목이 되는 것을 피하는 구조다. 1

메타데이터 관리 방식도 텐서 유형에 따라 나뉜다. 모델 가중치처럼 종류가 적고 비교적 정적인 객체는 GS에서 중앙 관리할 수 있다. 반면 KV 캐시처럼 수가 많고 변화가 잦은 상태는 여러 샤드로 나누며, 각 샤드의 홈 Worker가 임대(lease)와 펜싱 토큰을 활용해 소유권과 일관성을 관리한다. 1

5. 복사를 줄이는 메모리 구체화

Worker의 로컬 복제본은 GPU 메모리를 CUDA IPC 방식으로, CPU 메모리를 로컬 memfd 핸들로 노출할 수 있다. 원격 데이터에는 RDMA 기반 직접 쓰기를 지원해 불필요한 중간 복사를 줄인다. 환경이 허용되면 GPU 간 공유나 동일 노드 내 직접 공유 경로도 활용할 수 있다. 6

KV 캐시 이전이 간단해지는 이유

멀티턴 대화 세션을 기존 방식으로 다른 추론 인스턴스에 옮기려면 요청 라우터를 수정하고, 추론 엔진 내부의 KV 캐시 구현과 캐시·네트워크 백엔드를 함께 조정해야 할 수 있다.

TensorCast에서는 정책이 해당 세션의 KV 텐서 객체를 식별한 뒤 목적지 Worker에 배치하거나 구체화하도록 요청하고, 이후 요청을 목적지로 라우팅하면 된다. 텐서의 위치 검색, 전송, 메모리 연결은 수명주기 런타임이 처리한다. 1

물론 KV 캐시 이전에 드는 네트워크·메모리 비용 자체가 사라지는 것은 아니다. 핵심은 이전 정책을 여러 구성 요소에 반복 구현하지 않고 텐서 수명주기 계층에서 한 번 표현할 수 있다는 점이다. 이를 통해 캐시 지역성 기반 라우팅, 가중치 재사용, 서로 관련된 상태의 공동 배치 같은 여러 시스템을 가로지르는 최적화 정책을 비교적 쉽게 실험하고 배포할 수 있다. 1

실험에서 보고된 성능

연구진은 TensorCast를 vLLM과 SGLang에 통합하고, 가중치 구체화와 동기화, KV 캐시 관리, 프로그래머블 요청 라우팅을 평가했다. 1

• KV 캐시 성능은 전용 KV 캐시 시스템인 Mooncake과 경쟁할 수 있는 수준으로 보고됐다. 동시에 TensorCast는 여러 시스템 구성 요소를 아우르는 정책을 작성할 수 있는 유연성을 유지했다. 1
• 총 2,350억 개 파라미터와 220억 개 활성화 파라미터를 갖는 Qwen3-235B-A22B 인스턴스 시작 시간은 일반적인 분산 파일 시스템과 비교해 최대 228.6배 빨라졌다. 12
• 고동시성 멀티턴 에이전트 작업에서는 프로그래머블 TensorCast 정책을 적용했을 때 첫 토큰 생성 시간, 즉 TTFT(Time to First Token) 중앙값이 최대 93.2% 감소했다. 1

차세대 AI 인프라에서의 의미

TensorCast가 제시하는 변화는 새로운 캐시 제품을 하나 더 추가하는 데 있지 않다. 모델 가중치, KV 캐시, 체크포인트, 중간 상태처럼 서로 다른 텐서 상태를 동일한 수명주기 관점에서 관리하고, 그 위에 작업별 정책을 프로그래밍할 수 있게 하려는 것이다.

이 접근이 실용화되면 탄력적인 모델 인스턴스 구동, 캐시 위치를 고려한 요청 분배, 세션 이전, 텐서 상태 재사용을 특정 추론 프레임워크에 종속된 기능이 아니라 공통 시스템 정책으로 다룰 가능성이 열린다. 특히 대화형 에이전트처럼 상태가 많고 요청이 몰리는 환경에서, 계산 자체보다 데이터 준비와 이동이 차지하는 시간을 줄이는 기반 계층이 될 수 있다. 1

다만 제시된 228.6배와 93.2%라는 수치는 연구진이 연구 프리프린트에서 보고한 실험 결과다. 다양한 하드웨어와 운영 환경에서의 독립 재현, 그리고 실제 대규모 서비스 환경에서의 검증이 더 필요하다. 1