Cloud Native
KubeCon China 2026: 같은 하드웨어에서 되찾은 용량
상하이에서 열린 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026의 기조연설과 브레이크아웃 세션을 정리합니다. 프로덕션 환경의 GPU 분할, prefill과 decode 오케스트레이션, 클러스터 간 재분배, 그리고 가져갈 만한 패턴을 다룹니다.
Todea Engineering
Cloud Native Practice
상하이에서 열린 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026은 두 가지 이야기를 축으로 진행되었습니다. 첫 번째는 워크로드의 이동으로, 개막 기조연설이 여기에 애널리스트 수치를 붙였습니다. AI 컴퓨팅은 이제 학습보다 추론 쪽으로 기울어 있습니다. 그 추론을 서빙하는 일이 Kubernetes가 전제로 삼아 온 추상화를 압박하고 있고, 이 마찰은 프로그램 전체를 관통했습니다. Deployment는 추론 레플리카를 표현하지 못하고, TTFT는 요청률이 아닙니다. 두 번째는 강제(enforcement)로, 첫 번째보다 한 계층 아래에 있으면서 그 결말에는 거의 영향을 받지 않습니다. HAMi는 GPU를 나눠 각 워크로드를 자기 몫 안에 묶어 두고, DRA는 그 할당 단위를 요청하고 집계하는 방법을 Kubernetes 자체에 제공합니다. 워크로드가 학습이든 추론이든 마찬가지입니다. 두 이야기가 만나는 지점은 지출입니다. 용량이 더 필요했던 팀들은 하드웨어를 사는 대신 할당 단위를 바꿔서 그것을 얻어냈습니다.
기조연설이 제시한 프레임
기조연설은 그 이동을 숫자로 보여주었습니다. 무대에서 인용된 애널리스트 수치에 따르면 AI 컴퓨팅에서 추론이 67%, 학습이 33%를 차지합니다. 그 이유로 제시된 것은 규모가 아니라 빈도였습니다. 학습은 간헐적으로 일어나지만 추론은 프롬프트마다 일어나고, 에이전트 워크로드는 추론을 많이 먹습니다. 같은 기조연설은 추론 전력 수요가 2030년까지 93.3 GW에 이를 것으로 전망했습니다. 또한 클라우드 네이티브의 각 요소를 AI 시대의 대응물에 대응시켰습니다. 격리를 위한 컨테이너와 샌드박스, 마이크로서비스와 에이전트, 서비스 메시와 MCP 같은 에이전트 프로토콜, 선언형 API와 model-as-a-service, 그리고 불변 인프라와 SLA를 인지하는 인프라입니다.
PyTorch Foundation 기조연설은 이제 최전선을 가르는 것이 팀이 얼마나 빨리 반복하느냐라고 주장했습니다. 모델을 학습시킨 다음 서빙한다는 기존의 선형 파이프라인은, 프로덕션에서의 동작이 가중치로 되돌아가는 루프로 대체되었고, 그 근거로 제시된 것이 Kimi K3, MiniMax M3, Qwen 3.8에 대한 vLLM과 SGLang의 day-zero 지원이었습니다. 기조연설이 다룬 사례는 Shopify로, 커머스 에이전트에서 그 루프를 매일 돌리고 있습니다. 프로덕션에서의 실패가 학습 데이터가 되고, 캘리브레이션된 판정 모델이 트라젝토리를 비평하고 복구하고 검증합니다. PyTorch가 그것으로 지도 미세조정에 이어 강화학습으로 재학습하고, 갱신된 가중치는 vLLM이 서빙합니다. 이 회사의 GraphQL 평가에서 증류된 모델은 학습 예제 46,000개에서 61,000개 사이 어딘가에서 프론티어 참조 기준선을 넘어섰습니다. 분당 최대 2,000 요청에서 서빙 비용 약 96% 절감이라는 대표 수치는, 학습까지 포함한 실측 총비용이 아니라 서빙 비용에 대한 모델링 비교로 제시된 것입니다.
HAMi는 이 아래쪽 계층이 자리를 잡아가고 있음을 보여주는 분명한 사례입니다. 여러 워크로드가 GPU 카드 한 장을 공유할 수 있게 해주고, 각각이 자기 메모리와 연산 쿼터를 갖습니다. 스케줄러 옆이 아니라 아래에 놓이는 개방형 GPU 리소스 계층으로 동작하며, 그 위에 Volcano, Koordinator, Kueue가 올라가고 아래에는 KAI Scheduler 연동이 놓입니다. 이제 DRA 드라이버가 같은 분할을 Kubernetes 자체의 클레임 API로 표현하는데, 기존 device-plugin 요청과 나란히 두는 것이 아니라 그것을 번역합니다. 프로젝트 자신이 두 모드를 한 클러스터에서 동시에 돌려서는 안 된다고 못박고 있습니다. HAMi는 첫날 다섯 개 세션에서 언급되었고, 아래 프로덕션 사례 중 세 곳이 실제로 운영하고 있습니다.
기업 세션이 실제로 보여준 것
China Merchants Bank는 이 문제를 가장 단순한 형태로 마주했습니다. 가속기 풀은 하나, 안정적인 용량을 원하는 학습 워크로드와 빠른 탄력을 원하는 추론 워크로드가 같은 카드를 두고 경쟁하는 상황이었습니다. 가속기를 더 사는 대신, 두 워크로드를 하나의 공유 기반 위에서 스케줄링하기로 했습니다. 학습은 어드미션과 쿼터를 위해 Kueue를 거쳐 들어오고, 추론은 vLLM 또는 SGLang으로 돌면서 Prometheus 지표에 대해 KEDA로 스케일합니다. 그 아래에는 배치를 담당하는 HAMi를 갖춘 Kubernetes 스케줄러와, 데이터셋·체크포인트·캐시된 가중치를 위한 Fluid가 있습니다. 핵심은 밀물과 썰물처럼 오가는 움직임입니다. 추론 수요가 올라가면 KEDA가 스케일 아웃하고, 학습 작업은 스스로 체크포인트를 찍고 카드를 반납했다가 수요가 내려가면 재개합니다. 이들이 보고한 바로는 가속기 평균 연산 사용률은 35%에서 60% 이상으로 올랐고, 입력과 출력을 합친 100만 토큰당 추론 비용은 60% 넘게 떨어졌으며, 멀티테넌트 학습 밀도는 5배, Fluid에 캐시된 가중치로 Qwen3-14B를 2초 미만에 로딩했습니다. 이 수치들은 모두 TTFT 5초 이하, TPOT 50밀리초 이하라는 프로덕션 목표에 대비한 것입니다. 이들 자신의 요약 문구는 가치가 어느 한 컴포넌트가 아니라 계층을 가로지르는 조율에서 나온다는 것이었습니다. 플랫폼을 사는 대신 직접 조립하는 데 드는 비용에 대해서도 똑같이 분명했는데, 지속적인 통합과 호환성 테스트가 그것입니다. 이 작업은 행사 기간 중 CNCF의 End User Case Study Contest를 수상했습니다.
CamScanner를 만드는 Intsig는 같은 문제를 플릿 규모에서 겪었습니다. 자체 구축과 멀티 클라우드를 합쳐 1만 장 규모의 카드 자산이 1,000개가 넘는 온라인 추론 서비스와 1,000개가 넘는 오프라인 학습 작업을 병렬로 떠받치고 있었고, 학습 쪽은 24시간에 걸쳐 90%가 넘는 사용률로 돌아갔습니다. 제약은 배치가 아니라 대기 시간, 즉 카드를 기다리는 사람이었습니다. 이들이 효과를 인정한 실천은 먼저 분할하되 무거운 작업과 대형 모델에는 카드 한 장을 통째로 남겨 두는 것, 반쪽짜리 조각을 흩뿌리는 대신 부분적으로 쓰인 GPU를 채우는 binpack 배치, 고부하 워크로드 둘이 같은 카드를 쓰지 않도록 하는 어피니티 조합, 모니터링 루프, 그리고 탄력적 스케일링입니다. 이들을 합쳐 GPU 사용률 50% 향상, 전체 비용 30% 절감, 추론 성능 저하는 10% 미만 유지라는 결과가 제시되었습니다.
Viettel의 설명이 가장 직설적이었습니다. 이 베트남 통신사업자는 세대가 제각각인 약 2,500기의 GPU를 팀별 배정 뒤에 두고 있었고, 최상위 카드 한 장으로 단일 추론 서비스를 풀 로드로 돌려도 사용률은 대략 10%에 그쳤습니다. 이들의 진단은 한계가 애초에 하드웨어가 아니라 할당 단위였다는 것입니다. 그 판단 위에 세운 4계층 스택은 OpenStack Ironic과 Nova로 베어메탈을 프로비저닝하고, Kubernetes에 HAMi 분할과 KEDA를 더해 오케스트레이션하며, vLLM, SGLang, KServe, llm-d로 서빙하고, Envoy AI Gateway로 토큰을 계량합니다. 이제 한 팀이 서버를 몇 주씩 기다리는 대신 몇 분 만에 API 키와 OpenAI 호환 엔드포인트를 받습니다. 프로덕션 카드 한 장에서, 같은 워크로드와 같은 서비스 수준으로 사용률은 13%에서 59%로 올라갔습니다. 이들은 이것을 원인으로 제시하고, 거기서 따라오는 결과를 따로 두었습니다. 카드 한 장당 처리량 3.5배는 자신들이 측정한 워크로드에서 같은 처리량을 내는 데 필요한 GPU가 71% 적다는 같은 결과를 달리 말한 것입니다. 와트당 처리량 2.1배는 그와 별개로 제시된 수치입니다.
더 유용했던 것은 공유를 하지 말아야 할 지점에 대한 설명이었습니다. 공유는 요청 크기가 상류에서 제한되어 카드의 10% 언저리를 결코 넘지 않는 예측 서비스에서 3.3배를 돌려주었습니다. 반면 엔진이 이미 연속적으로 배치 처리하는 모델에서는 1.6배 나빠졌고, 연산 바운드 학습에서는 종합 0.77배로 나와 격리 목적으로만 할 만했습니다. 다만 이들은 이 수치가 어디까지나 자기네 환경의 것이라고 못박았습니다. 다른 곳으로 옮겨 가는 것은 워크로드의 형태 쪽이며, 엔진이 이미 카드를 바쁘게 만들고 있다면 공유는 그것을 나눌 뿐입니다.
Alibaba는 같은 맞바꿈을 카드가 아니라 클러스터 계층에서 했습니다. Qwen은 Karmada 페더레이션을 가로질러 서빙되며, 여기서 이들이 보여준 마이그레이션 플랜은 온라인 유닛을 하나씩 옮깁니다. 각 라운드는 5분의 안정화 대기를 두고, 유닛을 옮기기 전에 대상 쪽 용량을 예약하며, 실패한 라운드를 되돌릴 수 있도록 기존 슬롯을 계속 붙들고 있습니다. 리밸런서는 스팟 용량이 클러스터 사이를 오가는 데 맞춰 배치 추론을 다시 나눕니다. 이들이 보고한 바로는 할당률은 약 15% 상승, 스팟 GPU 사용률은 약 30% 상승했고, 며칠씩 걸리던 클러스터 간 마이그레이션은 몇 분 만에 끝났습니다.
그룹이 된 레플리카
추론 레플리카 하나를 더 이상 파드 하나라고 단정할 수 없고, 바로 그 점이 이 워크로드들의 스케줄링을 어렵게 만듭니다. DaoCloud와 Huawei Cloud가 진행한 LeaderWorkerSet (LWS) 메인테이너 세션은 모델 크기 표를 제시했습니다. Kimi K3가 2.8조 파라미터, DeepSeek V4 Pro가 1.6조, GLM 5.3이 약 7,500억입니다. 이 정도 규모의 모델 가중치는 이제 노드 한 대의 HBM을 넘어선다는 것이 세션의 논지였고, 그래서 레플리카 하나가 여러 머신에 걸친 파드 그룹이 됩니다. Deployment도 StatefulSet도 리더와 그 워커를 하나의 복제 단위로 표현하지 못하는데, 그것을 제공하는 것이 LWS입니다. 레플리카 수에 그룹 크기를 곱한 구성, 주입되는 리더 주소, 그리고 파드 하나가 실패하면 기본적으로 그룹 전체를 다시 만드는 재시작 정책을 갖습니다. DisaggregatedSet은 그 위에 놓여, 하나의 서비스 정의에서 각각 모든 역할을 담은 슬라이스들을 만들어 냅니다. 자식 LWS 각각은 슬라이스·리비전·역할로 이름이 붙기 때문에, 롤아웃 도중에 새 prefill이 낡은 decode와 대화하는 일이 생기지 않습니다. 그 아래에 깔린 스케줄링 실패는 구체적입니다. 이 파드들을 따로따로 스케줄링하면 GPU 슬롯이 전부 리더로 채워지면서 어떤 레플리카도 준비 상태가 되지 않을 수 있습니다. Volcano는 LWS 그룹을 PodGroup으로 만들어 이에 답하며, 그룹은 하나의 단위로 통째로 승인되거나 아예 승인되지 않습니다. scheduler-plugins의 coscheduler도 같은 방식을 쓰고, YuniKorn은 자체 태스크 그룹으로 같은 결과에 도달합니다.
Huawei는 같은 구조를 소비자용 어시스턴트에 가져왔습니다. Celia 어시스턴트를 받치는 추론 플레인은 세 겹으로 중첩되어 있습니다. ModelServing이 서빙 그룹을 담고 각 그룹이 역할을 담기 때문에, 멀티모달 모델이 vit, prompt, decode 역할을 서로 다른 파드 구성으로, 일정한 비율을 유지하며 돌립니다. 갱 스케줄링 정책은 Volcano PodGroup으로 변환되고, 토폴로지 정책은 prefill과 decode를 같은 랙에 고정하며, 비율 제약은 각 역할이 자기 지표로 스케일하는 동안 prefill 대 decode 비율을 1과 3 사이로 유지합니다. 기억해 둘 만한 세부는 축출(eviction) 보호였습니다. 검증(Validating) 웹훅이 Kubernetes 자체의 PodDisruptionBudget 검사보다 앞서 논리 단위별로 확인하고, 단일 그룹이 해당 역할의 유일한 인스턴스를 갖고 있다면, 운영자가 개입하거나 용량이 추가될 때까지 축출은 거부됩니다. NPU 사용률은 30.1%에서 40.7%로, NPU 리소스의 운영 자동화율은 63%에서 87%로 움직였습니다. Huawei의 것이 아니라 Volcano 커뮤니티 프로젝트인 Kthena 라우터는 llm-d의 KV 캐시 인지 라우팅과 일곱 개 구성에서 비교되었고, 진 것까지 함께 제시되었습니다. 둘은 모든 지표에서 기준선보다 나빴고, 둘은 TTFT에서만 졌으며, 상위 셋은 여섯 항목 모두에서 개선되어 가장 좋은 것이 요청 처리량 25.1% 향상, TTFT 23.8% 감소에 도달했습니다.
AI 이야기가 아니었던 계층
Samsung SDS는 같은 질문을 물리 계층으로 가져갔습니다. 이 회사는 이기종 베어메탈과 VM 인프라를 서비스 형태로 17개 클라우드 데이터센터에서 제공하고 40개국에서 사업을 운영하는데, 새 제품이 나올 때마다 같은 언더레이 클러스터에 얹혀 왔습니다. 비용은 오브젝트 개수가 아니라 결합이었습니다. 노드 한 대가 Multus와 Calico와 OVN을 함께 돌리고, CSI 드라이버 둘에 컨테이너 런타임 둘을 얹은 채, 격리는 네임스페이스에서 멈췄습니다. Kubernetes와 드라이버 버전이 함께 움직이니 버전 한 번 올리는 일이 전면 재검증을 뜻했고, 한 워크로드의 데이터 플레인 장애가 나머지를 함께 끌어내렸습니다. 이들의 답은 언더레이를 목적별 클러스터로 쪼개고, 여러 개를 운영하는 비용은 Cluster API로 떠안는 것이었습니다. 목적별 클러스터의 컨트롤 플레인은 etcd를 포함해 공유 컨트롤 클러스터 위에 파드로 돌고, 서로 경로가 없는 두 오버레이 네트워크 사이를 Konnectivity가 API 서버 트래픽 터널로 잇습니다. 그러면 버전과 CNI를 클러스터마다 고를 수 있습니다. 이것을 행사의 나머지 이야기와 잇는 것은 그것이 무엇을 가져다주느냐입니다. 노드 구성이 선언적이기 때문에 커밋 한 번으로 한가한 클러스터에서 바쁜 클러스터로 노드가 옮겨 갑니다. 이들이 보여준 사용 사례는 일일 주기로, 업무 시간에는 GPU를 추론 쪽으로, 야간에는 학습 쪽으로 기울이는 것이었습니다. 거기에 붙인 경제 논리는 직설적입니다. 놀고 있는 노드는 값을 치렀는데 아무것도 벌지 못하는 하드웨어이고, 사용률이 곧 마진이라는 것입니다.
가져갈 만한 테마
실제로 해볼 만한 것은 네 가지입니다. 첫째, 더 사기 전에 카드 한 장이 프로덕션 부하에서 실제로 무엇을 내주는지 측정하십시오. 무대에 선 팀 중 셋은 대략 10%에서 35% 사이 어딘가에서 출발했고, 그중 가장 분명하게 말한 한 곳은 아무것도 더 사지 않고 그 구간을 벗어났습니다. 둘째, 예산보다 할당 단위를 먼저 바꾸십시오. HAMi로 카드를 쪼개는 것이든, LeaderWorkerSet으로 리더-워커 그룹을 쓰는 것이든, 서빙 그룹 안의 역할이든, 클러스터 사이를 오가는 노드든 상관없습니다. 셋째, 공유가 도움이 될 것이라 가정하지 말고 시험하십시오. Viettel의 세 결과, 즉 카드를 채우지 못하는 워크로드에서의 3.3배, 이미 채울 수 있는 워크로드에서의 1.6배 악화, 연산 바운드 학습에서의 종합 0.77배는 같은 질문을 세 가지 형태의 워크로드에 던진 것이고, 답을 가르는 것은 엔진이 이미 카드를 바쁘게 만들고 있느냐입니다. 넷째, 추론이 이미 노드 하나를 넘어섰다면, 나중에 덧붙이는 대신 지금 그룹 단위 워크로드 API와 갱 스케줄링으로 옮기십시오. prefill과 decode의 분리는 DisaggregatedSet과 Huawei의 ModelServing에서, LeaderWorkerSet이 주는 것 위에 그 자체로 하나의 API 면이 되었기 때문입니다. 상하이에서 작동한 지렛대가 할당만은 아니어서 캐싱, 압축, 라우팅도 각각 큰 성과를 냈지만, 거듭 등장한 것은 할당이었고, 그 모두의 밑에 깔린 자원은 가속기 시간입니다.