AI 학습 프레임워크는 가속기 64장이 체크포인트 하나를 저장한다는 사실을 압니다. 일반적인 클라우드 스토리지는 클라이언트 64개가 파일을 쓴다고만 봅니다. 상하이교통대와 Huawei Cloud가 FAST 2026에서 발표한 AITURBO는 이 의미 차이에서 출발합니다[1]. 애플리케이션이 서로 관계없는 파일 요청 대신 하나의 I/O 그룹을 알려주면 스토리지 계층이 무엇을 최적화할 수 있는지를 검증한 시스템입니다.

결과는 체크포인트 가속보다 넓습니다. AITURBO는 호스트 DRAM을 임시 저장 계층으로 사용하고, 가속기 사이의 연산 패브릭을 추가 데이터 경로로 활용하며, 작업 제어기가 읽기와 쓰기 계획을 만듭니다. 평가한 학습 구성에서 체크포인트 쓰기는 Huawei Cloud의 범용 SFSTURBO보다 3.9~58.8배 빨랐습니다. 중복된 체크포인트 상태를 제거할 수 있는 조건에서는 논문이 구현한 Gemini 기준선보다 최대 5.9배 빨랐습니다. 모델과 병렬화 구성이 다른 시험에서 나온 최댓값이므로 하나의 고정 배수로 읽으면 안 됩니다. 핵심 기여는 각 프레임워크 안에 수천 줄의 스토리지 코드를 넣지 않고도 이런 계획을 만들 수 있게 한 인터페이스입니다.

스토리지 병목에는 서로 다른 링크가 있습니다

평가 환경은 연산 서버와 스토리지 서버를 분리했습니다. 연산 노드 하나에는 가속기 8개, CPU 코어 192개, 호스트 DRAM 1.5 TB가 있습니다. 가속기는 장치당 200 Gb/s 연산 패브릭으로 통신하지만, 장치 8개가 스토리지용 100 Gb/s NIC 하나를 공유합니다. 백엔드 스토리지에는 최대 30 GB/s를 할당했습니다. 백엔드 대역폭을 더 구매해도 노드 앞단의 공유 NIC 한계는 없어지지 않습니다. Huawei의 한 스토리지 상품에서 대역폭을 1.6 GB/s에서 80 GB/s로 높이면 GB당 가격은 16배가 됩니다.

이 구조에는 두 가지 최적화 여지가 있습니다. 첫째, 학습 작업이 스토리지 I/O를 수행하는 동안 호스트 DRAM과 연산 패브릭의 일부가 비어 있을 수 있습니다. 둘째, 여러 가속기가 같은 상태를 읽거나 씁니다. 데이터 병렬 랭크는 같은 파라미터를 저장할 수 있고, 추론 복제본 여러 개가 같은 모델을 읽으며, 동시에 시작한 에이전트 요청들이 같은 KV 캐시 접두부를 요구할 수 있습니다. 개별 파일 API만으로는 사용 가능한 경로와 중복 패턴이 모두 가려집니다.

AITURBO는 앞단과 뒷단 스토리지 경로 중 더 느린 쪽을 실제 대역폭으로 본 뒤 세 번째 경로를 추가합니다. 데이터 한 부를 스토리지 패브릭으로 호스트 DRAM에 가져오고, 연산 패브릭으로 가속기에 배포합니다. 쓰기에서는 원격 스토리지 반영이 끝나기 전에 DRAM 버퍼 단계에서 체크포인트 완료를 알려줄 수 있습니다. 지연시간을 줄이는 대신 즉시 원격 영속성을 포기하는 선택입니다. 복제본이나 직전 주기 체크포인트로 데이터를 복구할 수 있을 때만 허용할 수 있습니다.

AITURBO 연산 노드 한 대를 물리 계층에서 개념적으로 나타냈습니다. XPU 8개는 스토리지 방향 100 Gb/s NIC 하나를 공유하고, 192코어 호스트와 1.5 TB DRAM은 데이터 한 부를 저장한 뒤 XPU당 200 Gb/s 연산 패브릭으로 그룹 데이터를 배포하거나 수집합니다. 서버 렌더링은 공개된 제품 사진이나 보드 배치가 아닌 일반적인 재질 원판이며, 토폴로지와 라벨, 수치는 논문이 보고한 구성을 바탕으로 코드로 정확히 그렸습니다. 이 글을 위해 새로 만든 도판.

AITURBO는 관계를 알 수 없는 파일 호출 묶음을 계획 가능한 그룹 작업으로 바꿉니다. a, 일반 스토리지는 공유 스토리지 NIC를 지나는 중복 읽기·쓰기를 받지만 어느 가속기가 같은 작업에 속하는지 알지 못합니다. b, 그룹 I/O API가 참여 장치와 작업 의도를 제어기에 전달합니다. c, 제어기는 중복 청크를 제거하고 한 부를 호스트 DRAM에 저장한 뒤 연산 패브릭으로 전파하거나 스토리지 쓰기를 분산합니다. 이 글을 위해 새로 만든 도판.

그룹 정보가 최적화 위치를 스토리지로 옮깁니다

그룹 호출은 파일 작업뿐 아니라 함께 참여하는 클라이언트를 표시합니다. 쓰기 전에 각 클라이언트는 파일 전체 또는 4 MB 청크 단위로 BLAKE3 체크섬을 계산해 메타데이터와 함께 작업 제어기에 보냅니다. 제어기는 중복 데이터를 찾고, 고유 청크를 어느 노드의 DRAM에 둘지 정하며, 스토리지로 내보낼 경로의 부하를 분산합니다. 전체 배치 문제는 스토리지 시스템에서 사용하는 휴리스틱으로 풀고, 반복되는 체크포인트에는 계산한 계획을 재사용합니다.

읽기는 반대 방향으로 움직입니다. 스토리지에서 한 부만 호스트 DRAM으로 가져온 뒤 연산 패브릭으로 요청한 가속기에 전파합니다. 모델 복제본을 한 개에서 여러 개로 늘릴 때 효과가 큽니다. 캐시된 사본이 있으면 135 GB Qwen-72B 체크포인트를 XPU 64개에 2.25초 만에 적재했습니다. SFSTURBO를 사용한 ServerlessLLM 기준선은 각 복제본이 느린 스토리지 경로를 계속 사용하므로 1,384초가 필요했습니다. 반면 처음 읽는 데이터는 구매한 스토리지 대역폭의 제약을 그대로 받습니다. 1 GB/s만 할당한 조건에서 같은 체크포인트를 XPU 8개로 읽는 시간은 모든 시스템이 173초였습니다.

이 결과가 AITURBO의 적용 범위를 정확히 보여줍니다. 백엔드에 없는 대역폭을 만들어내는 시스템은 아닙니다. 첫 사본이 도착한 뒤 중복 전송과 비어 있는 로컬 자원을 유효 대역폭으로 바꿉니다. 다른 작업에 적용하려면 전체 I/O 중 그룹으로 묶이고, 중복되며, 재사용할 수 있는 비율부터 측정해야 합니다.

체크포인트 최고 배수와 실제 비용 절감은 다릅니다

학습 평가는 1.5B, 13B, 38B 모델을 각각 ZeRO 사용·미사용 구성으로 나누고 최대 64개의 Ascend 910B NPU 또는 NVIDIA A800 GPU에서 수행했습니다. 메모리 임시 저장, 중복 데이터, 부하 분산 계획을 모두 활용할 수 있을 때 체크포인트 시간이 가장 많이 줄었습니다. 데이터 병렬 구성에서 중복 제거만으로 체크포인트 시간이 4.3~47.2% 줄었고, 중복 파일을 여러 경로로 재배치할 수 있는 조건에서는 쓰기 계획이 최대 76%를 더 줄였습니다.

논문은 XPU 한 개가 시간당 한 번 고장난다고 가정하고 최적 체크포인트 주기를 계산해 낭비되는 XPU 시간도 구했습니다. 이 분모에서는 SFSTURBO 대비 절감폭이 최대 6%입니다. 58.8배가 아닙니다. 체크포인트가 빨라지면 더 자주 보호할 수 있지만, 체크포인트 시간은 긴 학습 작업의 일부이기 때문입니다. 스토리지 지연을 실제 가속기 비용과 연결한다는 점에서 6%가 운영 계획에 더 유용한 숫자입니다.

추론에서는 조건이 달라집니다. Qwen-14B를 XPU 8개에서 실행하며 30분 분량의 Qwen-Bailian KV 캐시 트레이스를 재생했습니다. Mooncake의 스토리지 폴백을 AITURBO로 바꾸자 평균 첫 토큰 시간이 0.85초에서 0.65초로 23% 줄었습니다. 실행 중인 추론 인스턴스를 함께 동기화하기 어려워 그룹 API는 사용하지 않았습니다. 그래도 캐시에서 밀려난 블록을 다시 읽을 때 연산 패브릭 경로가 유효 스토리지 처리량을 높였습니다.

보고된 성능 향상은 분모가 서로 다릅니다. 여섯 가지 학습 구성의 체크포인트 완료 시간은 SFSTURBO보다 3.9~58.8배 짧았고, 중복을 활용할 수 있는 조건에서는 Gemini보다 최대 5.9배 빨랐습니다. 모델로 계산한 낭비 XPU 시간은 최대 6% 줄었고, 30분 Qwen-Bailian 재생의 평균 첫 토큰 시간은 23% 줄었습니다. 이 값을 서로 곱하거나 하나의 벤치마크처럼 사용하면 안 됩니다. 이 글을 위해 새로 만든 도판.

프레임워크 코드는 줄지만 조정 비용은 남습니다

평가한 Megatron 체크포인트 구현에는 조정과 파일 시스템 최적화 코드 2,228줄이 있습니다. AITURBO 통합에는 286줄을 추가했고 계획 책임은 스토리지로 옮겼습니다. Mooncake의 폴백 경로는 44줄을 바꿨습니다. 클라우드 사업자는 하나의 스토리지 구현으로 여러 프레임워크와 병렬 구성을 지원할 수 있으므로 이 차이가 중요합니다.

그룹 제어기는 장벽과 메타데이터 교환을 추가합니다. XPU 64개에서 조정 비용은 최대 45 ms였습니다. 이번 평가의 수초 단위 대용량 I/O와 비교하면 작지만, 작은 작업에는 이득이 없을 수 있습니다. 또한 AITURBO 트래픽을 최저 우선순위로 두는 기존 연산 패브릭 QoS에 의존합니다. 하나의 XPU를 여러 작업이 공유하는 복잡한 격리는 향후 과제입니다. 체크포인트 중에도 연산 패브릭을 계속 포화시키는 환경에서는 병목을 없애지 못하고 다른 링크로 옮길 수 있습니다.

구매 기준은 대역폭에서 작업 의도로 넓어져야 합니다

AITURBO는 일반 스토리지 처리량 사양에 없는 요구사항을 제시합니다. 스토리지가 집합 작업을 받을 수 있는지, 프레임워크별 코드를 넣지 않고 중복 상태를 찾는지, 어느 단계의 완료 응답이 영속성을 보장하는지, 학습 통신과 스토리지 트래픽을 어떻게 격리하는지를 확인해야 합니다. 최대 GB/s만으로는 어느 질문에도 답할 수 없습니다.

이 설계는 크고 반복되며 여러 장치가 함께 수행하는 전송에서 강합니다. 작은 I/O, 중복되지 않는 데이터, 계속 포화된 연산 패브릭, 모든 완료 응답에 즉시 원격 영속성이 필요한 작업에는 약합니다. 더 비싼 스토리지 상품을 선택하기 전에 이 조건을 측정해야 합니다. 조건이 맞는다면 새 스토리지 서버보다 API가 더 많은 가속기 시간을 되찾을 수 있습니다. 애플리케이션은 이미 어떤 데이터가 함께 움직이는지 알고 있고, 이제 인프라가 그 정보를 사용할 수 있기 때문입니다.

출처와 저작권 안내

이 글은 Silicon & Systems가 작성한 편집 요약입니다. 논문의 작동 원리, 평가 조건, 한계를 우리 표현으로 다시 썼습니다. 원문의 문장, 표, 도판은 옮기지 않았으며, 본문의 도판 3개와 카드 이미지는 보고된 사실을 바탕으로 이 글을 위해 새로 만들었습니다. 저작권 (c) 2026 원저자. 원문은 USENIX FAST 2026 페이지에서 공개되어 있습니다.