DEVOCEAN

이번 글에서는 AI 컴퓨팅 트렌드가 어디로 향하는지, 그 흐름에서 추론(inference) 인프라를 운영하는 데 쿠버네티스가 어떤 도움을 주는지,

그리고 AWS 위에서 대규모 추론을 안정적으로 돌리는 방법까지 다뤄보려고 합니다.

긴 글을 읽기 부담스러우신 분들은 제가 Youtube 영상으로 제작해 놓았으니 영상으로 보셔도 좋습니다.

• https://youtu.be/i2LsxlQMpwc

최근 트렌드를 살펴봤을 때 클라우드 네이티브와 오픈소스로 AI를 활용하는 영역은 크게 모델 학습, 모델 추론, AI 에이전트 세 가지로 나눌 수 있습니다.

에이전트만으로도 할 얘기들이 많지만, 이 글은 모델, 그중에서도 추론에 집중해보려고 합니다.

1. 무게중심이 학습에서 추론으로 넘어갔다

그동안 모델 프로바이더들은 더 정확한 모델을 만들기 위해 AI 컴퓨팅 자원을 학습(training)에 집중해 왔습니다.

지난 몇 년간 프런티어 모델들이 앞다투어 출시된 것이 바로 그 이유죠. 그런데 지금은 누구나 AI를 쓰는 시대입니다.

자연히 추론 요청이 기하급수적으로 늘고 있습니다.

딜로이트의 *Technology, Media & Telecommunications Predictions 2026*(2025년 11월) 보고서는 이 전환을 수치로 보여줍니다.

불과 3년 만에 학습과 추론의 비중이 역전됐습니다.

그리고 더 많은 사람들이 AI를 활용할 것이기 때문에 당연하게도 이 흐름은 앞으로 더 가속될 것입니다.

왜 추론이 이렇게 커질까요?

학습은 모델을 만들 때 한 번(혹은 주기적으로) 일어나는 배치성 작업입니다.

반면 추론은 사용자가 AI를 쓸 때마다 발생하는 상시성 작업이죠. 게다가 최근 모델들은 답을 내놓기 전에 "생각"하는 추론(reasoning) 단계를 두면서, 한 번의 요청에 소비하는 토큰이 크게 늘었습니다.

사용자 수 × 요청 빈도 × 요청당 토큰이 모두 커지니, 추론 컴퓨팅 수요가 폭발하는 것은 필연입니다.

2. 모델에 대한 요구의 변화 ("얼마나 큰가"에서 "얼마나 잘 아는가"로)

예전에는 얼마나 더 크고 똑똑한 AI인지가 경쟁의 핵심이었습니다.

그런데 이제는 인터넷상의 학습 데이터를 대부분 학습했다고 할 만큼 모델 성능이 상향 평준화된 느낌입니다. 상위 모델 간 벤치마크 격차도 점점 좁아지고 있죠.

그래서 기업들의 시선이 "좋은 범용 모델에 의존"에서 "우리 업무를 잘 아는 나만의 모델"로 옮겨가고 있습니다.

가트너는 2028년까지 엔터프라이즈가 사용하는 생성형 AI 모델의 60% 이상이 도메인 특화(domain-specific) 모델일 것으로 전망합니다.

도메인 특화 모델을 갖추는 방법은 처음부터 학습하는 것만이 아닙니다.

현실에서는 대개 이런 스펙트럼으로 접근합니다.

·       RAG(검색 증강 생성): 사내 문서·DB를 검색해 컨텍스트로 주입하는 방법이며, 가장 쉽고 빠르게 적용해볼 수 있는 방법입니다.

·       파인튜닝 / LoRA: 오픈웨이트 모델을 우리 데이터로 미세조정하는 방식입니다.

·       지속 사전학습(continued pre-training): 특정 도메인 코퍼스로 추가 학습 합니다.

·       자체 사전학습: 대규모의 인프라가 필요하고 전문 엔지니어들이 필요하기 때문에 시간과 비용이 가장 많이 들어갑니다.

어느 방법을 택하든, 결국 내가 만든/조정한 모델을 내가 운영하는 추론 인프라가 필요합니다.

그리고 대규모 모델은 서버 한 대로 돌릴 수 없습니다. 결국 안정적인 분산 시스템을 갖추는 것이 기업 AI 도입의 성공과 실패를 가릅니다.

3. 왜 쿠버네티스인가

쿠버네티스는 태생부터 분산 시스템을 위해 만들어졌습니다.

스케줄링, 자가치유(self-healing), 오토스케일링, 서비스 디스커버리, 선언적 운영, 방대한 에코시스템 등 쿠버네티스는 AI 추론 인프라에 필요한 요소가 이미 갖춰져 있습니다.

이 흐름은 CNCF 연간 설문에서도 확인됩니다.

• 설문에 참여한 (컨테이너를 쓰는) 조직 중 82%가 이미 프로덕션에서 쿠버네티스를 운영

• 생성형 AI를 호스팅하는 조직 중 66%가 추론 인프라로 쿠버네티스를 사용

쿠버네티스가 사실상 AI 인프라의 표준이 되어가고 있는 것입니다.

4. 그냥 쿠버네티스의 Service로 부하 분산하면 안 되는 이유

쿠버네티스로 추론 인프라를 아주 단순하게 구축해본다고 해봅시다.

사용자가 질문을 보내면 Ingress나 Gateway API를 거쳐 Service가 트래픽을 받고, Service는 엔드포인트에 등록된 파드들에 랜덤으로 부하를 분산합니다.

이 부하 분산 방식은 내부적으로는 iptables를 사용해서 논리적인 분산을 하게 되는데  일반 웹 서비스라면 훌륭한 방식이지만, LLM에서는 성능을 크게 떨어뜨립니다.

이유를 이해하려면 LLM이 추론하는 방식을 알아야 합니다.

4.1 자기회귀(auto-regressive) 방식과 KV 캐시

LLM은 답변을 만들 때 이전 토큰을 참고해 다음 토큰을 생성하는 자기회귀 방식으로 동작합니다.

첫 스텝에서 토큰 하나를 만들고, 다음 스텝에서는 앞서 만든 토큰까지 포함해 그다음 토큰을 만들고… 이 과정을 답변이 끝날 때까지 반복합니다.

즉 매 스텝마다 앞의 모든 토큰을 다시 참조해야 합니다.

이걸 매번 처음부터 계산하면 엄청나게 비효율적입니다.

그래서 이미 계산된 토큰들의 Key/Value 값을 GPU 메모리에 저장해두고 재사용합니다.

이 캐시가 바로 KV 캐시입니다.

여기서 추론이 사실 두 단계로 나뉜다는 점이 중요합니다.

·       Prefill(프리필): 입력 프롬프트 전체를 한 번에 병렬 처리해 KV 캐시를 채우는 단계. 연산량(FLOPs) 바운드이고 버스트성이 강합니다.

·       Decode(디코드): 토큰을 하나씩 자기회귀적으로 생성하는 단계. 메모리 대역폭·지연에 민감합니다.

두 단계의 하드웨어 특성이 다르다는 점은 뒤에서 조금 더 자세히 설명하겠습니다.

4.2 랜덤 분산이 만드는 캐시 미스

멀티턴 대화를 예로 들어보죠. 첫 질문이 Service를 거쳐 2번 파드로 갔다면, 계산된 토큰들이 그 파드의 KV 캐시에 저장됩니다.

그런데 후속 질문은 다시 랜덤 분산되므로 이번엔 3번 파드로 갈 수 있습니다. 3번 파드에는 캐시가 없으니 모든 토큰을 처음부터 다시 연산해야 합니다.

부하 분산이 확률로 결정되니 이런 캐시 미스가 매우 빈번하게 일어납니다.

결과는 명확합니다. 성능(지연)은 나빠지고 비용(재연산)은 올라갑니다. 그래서 상태(state)를 인식하는 라우팅 전략이 필요합니다.

사실 이 문제는 비용과도 직결됩니다. (KV 캐시의 경제학)

KV 캐시는 컨텍스트가 길어질수록(수만~수십만 토큰) 사용자 세션당 수십~수백 GB의 값비싼 HBM(고대역폭 메모리)을 잡아먹습니다.

그래서 업계에서는 KV 캐시를 전용 저장 계층(플래시·CXL 메모리 등)으로 계층화해 사용자당 메모리 비용을 크게 낮추는 연구가 활발합니다.

"캐시를 어디에 두고 어떻게 재사용하느냐"가 곧 추론 단가를 좌우합니다.

5. AI 라우터, 그리고 llm-d

캐시 미스 문제를 푸는 것이 AI 라우터(inference-aware router)입니다.

일반 로드밸런서가 "연결 수를 균등하게"에 최적화한다면, AI 라우터는 "추론 특성을 이해한 라우팅"을 합니다.

대표적인 능력은 다음과 같습니다.

• 세션(대화 맥락)을 기억한다

• 한 클러스터에서 여러 모델을 운영할 때 요청을 알맞은 모델로 보낸다

• KV 캐시가 있는 파드를 찾아 보낸다 (캐시 히트율↑)

• 각 파드의 여유 용량을 인식해 분산한다

대표적인 프레임워크가 llm-d입니다.

쿠버네티스 네이티브로 대규모 LLM 추론을 가능하게 하는 오픈소스이며, 올해 3월 CNCF 샌드박스 프로젝트로 편입됐습니다.

5.1 핵심 컴포넌트

llm-d의 핵심 컴포넌트는 크게 Router, InferencePool, Model Server 세 가지입니다.

• Router(라우터) = Proxy + EPP. 지능형 진입점입니다.

• Proxy: 산업용 L7 프록시(Envoy 계열). 트래픽을 받아 대기시키고, 결정만 EPP에 위임합니다. Gateway API Inference Extension(GAIE) 표준을 따릅니다.

• EPP(Endpoint Picker): 실시간 지표·KV 캐시 친화도·정책으로 최적 파드를 점수화(score)해 고르는 두뇌 역할을 합니다.·

• InferencePool: 같은 모델을 서빙하는 파드들을 레이블로 묶는 "LLM에 최적화된 Service"라고 볼 수 있습니다. 즉, AI Router의 라우팅 대상이 됩니다.

• Model Server: vLLM·SGLang 같은 실제 추론 엔진이 탑재된 서버입니다.

5.2 동작 흐름

라우팅 파드 안에서 Envoy 프록시가 사이드카로 돌고, EPP가 함께 실행됩니다.

1.      Envoy가 트래픽을 받는다

2.     Envoy가 ext-proc(External Processing) 프로토콜로 EPP에게 "어느 파드로 보낼까?"를 묻는다

3.     EPP가 후보 파드들을 점수화해 최적 파드를 알려준다

4.     Envoy가 선택된 파드로 트래픽을 라우팅한다

EPP는 하나의 알고리즘을 고정하지 않고 여러 스코어러(scorer)의 가중 합산으로 결정합니다.

대표적으로 접두사 캐시 인지(prefix-cache-aware)에 가장 높은 가중치를 두고, 대기 큐 깊이·KV 캐시 점유율·부하 인지를 함께 반영합니다.

여기서 접두사의 의미는 매번 반복되는 프롬프트라고 이해하시면 되고, 대기큐 깊이는 요청을 받을 서버에 얼마나 많은 질문들이 대기하고 있는지 여부입니다.

즉, "캐시가 있는 곳으로 보내되, 한 파드에 쏠려 큐가 밀리면 부하를 분산"하는 균형을 잡는 것이죠.

llm-d를 쓰면 멀티모델 관리도 자연스럽습니다.

단순한 요청은 작은 모델로 가볍게, 복잡한 요청은 큰 모델로 트래픽 특성에 따라 대상 모델로 라우팅할 수 있습니다.

6. 대규모로 가면 고려할 것이 급격히 늘어난다

대규모 모델을 서빙하고 요청량도 많다고 가정하면, 신경 쓸 것이 순식간에 많아집니다. 단순하게 생각해봐도 아래와 같은 고려사항들을 떠올릴 수 있겠죠.

• 트래픽에 따라 파드를 확장할 수 있어야 한다

• 멀티모델이면 모델별 트래픽 증가량이 다르므로 모델별로 노드도 확장해야 한다

• 보안, 장애 대응, 관측성, 비용 최적화까지 모두 챙겨야 한다

사실 일반 웹 서비스 운영과 크게 다르지 않습니다.

만약 우리 회사가 추론을 서비스로 제공하는 비즈니스를 하고 있다면, 추론 시스템의 장애 시 비즈니스 손실이 훨씬 클 수 있습니다.

결국 쿠버네티스를 안정적으로 운영할 수 있는 역량이 필수적이라는 의미가 됩니다.

그래서 지금부터는 "그 안정적 운영을 어떻게 쉽게 만들 것인가"에 대해 알아보려고 합니다.

7. Prefill/Decode 분리 — 지금 추론 인프라의 최전선

최근 대규모 추론에서 지금 가장 뜨거운 아키텍처 변화가 prefill/decode 분리(disaggregation)입니다.

앞서 언급했 듯이 prefill은 연산 바운드, decode는 메모리 대역폭 바운드로 성격이 다릅니다. 이 둘을 같은 GPU에서 섞어 돌리게 되면 서로 간섭합니다.

특히 긴 입력의 prefill이 진행 중인 decode를 지연시켜 사용자 체감 속도를 떨어뜨리죠.

그래서 prefill 전용 풀과 decode 전용 풀을 분리해 각각 독립적으로 확장하는 방식이 프로덕션 표준으로 자리잡고 있습니다.

마치 우리가 웹 서비스를 구축할 때 기능간 부하나 버그 전파를 방지하기 위해 MSA 방식으로 전환했던 것이 유행했던 것과 비슷하죠.

• 여러 시스템의 실측에서 처리량 최대 2배, 비용 30~40% 절감 효과가 보고됩니다.

• llm-d도 이를 지원합니다. EPP가 decode 워커와 prefill 워커를 각각 골라주고(llm-d.ai/role 레이블로 구분), 두 풀 사이의 KV 캐시 전송은 NIXL(NVIDIA Inference Transfer Library) 같은 라이브러리로 RDMA(InfiniBand·RoCE·EFA)를 통해 GPU 메모리 간 직접 전송합니다.

즉, 앞서 본 "캐시를 어디 두느냐"의 문제가 노드 경계를 넘어 풀 사이의 고속 전송 문제로 확장되는 것입니다.

여기서 네트워크가 병목이 되고, EC2의 placement group, EFA, Trainium/NeuronLink 같은 고속 인터커넥트가 중요해집니다.

8. Amazon EKS와 AI Conformance 인증

CNCF는 작년 11월, 쿠버네티스 환경에서 AI/ML 워크로드를 안정적·효율적으로 실행할 수 있는지 검증하는 AI Conformance 인증 프로그램을 출범했습니다.

AWS의 관리형 쿠버네티스인 Amazon EKS는 이 인증을 초기에 획득했습니다.

그만큼 AI 워크로드를 운영하기에 적합하다는 신호이자, 어느 환경으로든 이식 가능한 표준을 따른다는 뜻이기도 합니다.

Amazon EKS는

• GPU/가속기 리소스를 효율적으로 관리하고

• 분산 AI 워크로드를 스케줄링하며

• 요구에 따라 클러스터를 유연하게 확장·축소하고

• 기본적으로 통합 모니터링을 제공합니다.

가속기를 위한 "빌트인 스케줄링·할당"이란?

쿠버네티스 기본 스케줄러는 원래 CPU·메모리만 이해합니다. GPU/Neuron 같은 가속기를 쓰려면 별도 메커니즘이 필요합니다.

Device Plugin(GPU를 정수 단위로 파드에 할당), DRA(Dynamic Resource Allocation)(GPU를 쪼개 쓰거나 토폴로지·속성 기반으로 정교하게 할당),

GPU 공유(time-slicing·MPS·MIG), 갱 스케줄링(Kueue·Volcano로 "N개를 동시에 확보 못하면 시작 안 함"), 토폴로지 인지 배치(EFA·placement group) 등

복잡한 것들을 고려해야하는데 EKS는 이런 것들을 가속 AMI에 내장하고 자동화해 제공합니다.

개발자는 nvidia.com/gpu: 1 한 줄만 적으면 내부적으로 알아서 동작하는거죠.

9. Karpenter로 노는 자원을 없애 비용 절감

Datadog의 *State of Cloud Costs 2024* 보고서에 따르면 컨테이너 비용의 83%가 유휴 자원으로 낭비되고 있다고 합니ㄷ. 값비싼 GPU라면 손실이 훨씬 크겠죠.

AWS는 이 문제를 겨냥해 오픈소스 오토스케일러 Karpenter를 개발해 쿠버네티스 프로젝트(CNCF 산하 SIG)에 기증했습니다.

그래서 AWS뿐 아니라 온프레미스·타 클라우드의 관리형 쿠버네티스에서도 쓸 수 있는 벤더 중립 도구입니다.

• 필요한 즉시 노드를 프로비저닝하고, 이때 파드가 요구하는 스펙에 맞춰 최적의 인스턴스 사양을 선택합니다.

• 운영 중 저활용 노드가 있으면 더 알맞은 사양으로 교체하거나, 다른 노드로 파드를 통합(consolidation)한 뒤 폐기합니다.

• 노드를 그냥 지우면 위험하므로, 내부적으로 drain을 수행해 파드가 다른 노드로 안전하게 재배치되게 합니다.

여기에 더해 Graviton(ARM) 인스턴스로 가격 대비 성능을 높이고, Spot 인스턴스로 최대 90%까지 비용을 낮추며, 서버리스 컨테이너인 Fargate로 노드 관리 자체를 없애는 선택지도 있습니다.

GPU를 자체 호스팅할지 판단하는 기준

"직접 GPU를 띄우는 게 API를 호출하는 것보다 싼가?"는 GPU 활용률로 갈립니다.

값비싼 GPU를 24시간 켜두고 실제로는 일부 시간만 쓴다면, 관리형 API보다 비쌀 수 있습니다.

그래서 비교는 반드시 "할당 기반 비용(띄워둔 시간 전체)"으로 해야 하고, 자체 호스팅이 유리해지는 손익분기점은 대체로 활용률 50% 이상입니다.

Karpenter의 통합·Spot 활용, prefill/decode 분리로 이 활용률을 끌어올리는 것이 곧 비용 최적화입니다.

10. EKS 클러스터 아키텍처

쿠버네티스 운영에서 가장 어려운 것이 컨트롤 플레인입니다.

Amazon EKS는 이 컨트롤 플레인을 AWS가 전담 관리합니다.

컨트롤 플레인에는 컨트롤러와 스케쥴러를 포함해 다양한 컴포넌트로 구성되어 있는데, 모든 요청의 관문 역할을 하는 API 서버와, 클러스터의 모든 상태가 저장되는 데이터베이스인 etcd가 특히 중요합니다.

이 둘은 장애 시 클러스터 전체가 멈출 수 있기 떄문에 고가용성 설계가 필수입니다.

API 서버는 최소 2대 이상, etcd는 Raft 합의 알고리즘을 쓰기 때문에 홀수(최소 3대) 이상으로 구성됩니다.

이것만 해도 최소 다섯 대의 서버를 안정적으로 관리하고 확장·축소까지 유연하게 해야 하는 셈입니다.

이 부담을 AWS가 대신 하기 때문에 사용자는 데이터 플레인(노드용 EC2)만 관리하면 됩니다.

로드밸런서가 필요하면 AWS 로드밸런서(ELB/ALB)를, 퍼시스턴트 볼륨이 필요하면 EBS·EFS를 프로비저닝해 붙이면 됩니다.

11. EKS Auto Mode / Capabilities

비유를 하나 들어보겠습니다. 80~90년대 운전하던 시절엔 대부분 간단한 정비 기술을 알고 있었습니다.

차가 길에서 자주 퍼졌고, 보닛을 열면 부품이 다 드러나 있어 직접 고칠 수 있었으니까요.

지금은 어떤가요? 대부분 감춰져 있고, 기술이 좋아져 잘 고장 나지도 않습니다. 복잡한 부분은 전문가에게 맡기면 됩니다.

Amazon EKS도 그 방향으로 진화하고 있습니다. 사용자는 어려운 부분을 신경 쓰지 않고 서비스와 모델을 실행하는 데만 집중하면 됩니다.

• EKS Auto Mode: 컨트롤 플레인뿐 아니라 데이터 플레인까지 AWS가 관리합니다. 클러스터 생성 시 옵션으로 켜면, 스토리지·네트워킹·컴퓨팅 컨트롤러를 AWS가 전담하고, 노드용 인스턴스는 사용자 계정에 생성되되 그 업데이트·확장·축소는 AWS가 담당합니다. NVIDIA·Neuron 드라이버와 디바이스 플러그인도 내장돼 별도 설치가 필요 없습니다.

• EKS Capabilities: 여기서 한 걸음 더 나갑니다. Argo CD 같은 필수 운영 도구조차 AWS가 관리형으로 운영해줍니다. Argo CD도 결국 쿠버네티스 리소스라 직접 배포·유지보수해야 하고, 하루에도 수십 번 배포가 일어나는데 여기 장애가 나면 비즈니스에 타격이 갑니다. 단순히 설치만 해주는 애드온과 달리 유지보수까지 책임진다고 이해하시면 됩니다.

정리하면 AWS는 컨트롤 플레인 → 데이터 플레인 → 필수 도구까지 복잡성을 단계적으로 흡수하고 있습니다.

덕분에 인프라 전문가가 아닌 AI/ML 엔지니어도 쿠버네티스 기반 추론 인프라를 손쉽게 다룰 수 있게 됩니다.

관리형 편의 vs 이식성 (트레이드오프)

관리형이 편한 만큼, 특정 클라우드 기능에 의존할수록 이식성은 조금씩 줄어듭니다.

그래서 이식성이 중요하면 상류(upstream) 표준(예: Gateway API Inference Extension, DRA)을 우선 채택하고,

속도가 중요하면 Auto Mode/Capabilities 같은 관리형을 택하는 식으로 의식적으로 선택하는 것이 좋습니다.

EKS가 AI Conformance 인증을 초기에 받은 이유도 "표준을 지키면서 관리형을 제공"하려는 방향과 맞닿아 있습니다.

12. 일반적인 추론 아키텍처 흐름 (EKS 기준)

EKS 위에서 추론 인프라를 세우는 전형적인 흐름을 훑어보겠습니다.

1. 먼저 모델을 실행할 GPU 인스턴스를 프로비저닝합니다.

2. 컨테이너 레지스트리 Amazon ECR에서 추론 엔진(vLLM 등) 컨테이너를 pull 받아 실행합니다.

3. 모델은 Hugging Face 같은 모델 레지스트리로부터 다운로드 받습니다.

4. 모델은 스토리지에 저장하는데 속도·비용·기반 OS 요구에 따라 S3, EBS, EFS, FSx 등 알맞은 스토리지를 고릅니다. (대형 모델은 컨테이너 이미지·모델 로딩 시간이 콜드스타트 병목이 되므로, 지연 로딩·캐싱 기법도 함께 고려합니다.)

5. 모델이 준비되면 GPU 메모리에 로드하고, 모델 크기에 맞춰 필요한 만큼 노드를 확장합니다.

6. 준비가 끝나면 쿠버네티스에서 엔드포인트를 expose해 사용자에게 제공합니다. 로드밸런서나 API Gateway를 진입점으로 씁니다.

7. 엔드유저는 개발자일 수도 있지만, 최근에는 AI 에이전트가 스스로 API를 호출하기도 합니다.

8. 사용자 상호작용·애플리케이션 로그·인프라 지표를 CloudWatch, OpenTelemetry, Prometheus 등으로 수집·시각화합니다.

추론 시대의 관측성

웹 서비스에서 보던 CPU·메모리·응답시간에 더해, 추론에서는 TTFT(첫 토큰까지 시간), ITL(토큰 간 지연), GPU 활용률, KV 캐시 히트율, 토큰당 비용 같은 지표가 핵심입니다.

업계에서는 단순 처리량(FLOPS)보다 "SLA를 지키며 실제로 유용하게 처리한 양"을 뜻하는 goodput을 효율 지표로 삼는 흐름이 뚜렷합니다.

비용이 갑자기 튀면 대개 버그(무한 루프·라우팅 오류)의 신호이므로, 비용을 알림 지표를 넘어 회로차단기로 활용하는 것도 좋은 실무 습관입니다.

13. Amazon EKS 기반의 대규모 추론

이미 많은 고객이 EKS 위에서 수백만 개의 GPU 인스턴스를 사용하고 있고, 2024년 이후 EKS의 GPU 인스턴스 수는 2배 이상 증가했습니다.

수조 개 파라미터 모델까지 서빙할 수 있도록, Amazon EKS는 단일 클러스터에서 10,000개 이상의 노드를 쓸 수 있는 울트라스케일 클러스터를 지원합니다.

대표적인 사례가 Anthropic입니다.

Anthropic의 Claude 제품군이 Amazon EKS에서 운영되며, 울트라스케일 클러스터를 도입해 지연 개선과 운영 효율 목표를 달성했습니다.

Project Rainier는 AWS와 Anthropic이 협력해 Claude 운영을 위해 구축한 대규모 AI 컴퓨팅 클러스터입니다.

여기 쓰이는 Trainium 울트라 서버는 대규모 학습·추론에서 서버 간 통신이 매우 빈번한데, 이때 네트워크 지연을 줄이는 것이 핵심 과제입니다.

서버 사이를 잇는 고속 연결망 NeuronLink가 이 서버 간 지연을 최소화해 대규모 모델 운영을 효과적으로 뒷받침합니다.

마치며

• AI의 무게중심은 학습에서 추론으로 넘어왔습니다(2026년 컴퓨팅의 2/3가 추론).

• 대규모·도메인 특화 추론을 안정적으로 돌리려면 분산 시스템이 필요하고, 그 사실상 표준이 쿠버네티스입니다.

• LLM의 KV 캐시 특성 때문에 AI 라우터(llm-d, EPP)가 필요하고, 대규모에서는 prefill/decode 분리까지 나아갑니다.

• 운영의 어려움(컨트롤 플레인·비용·확장)은 Amazon EKS와 Auto Mode/Capabilities/Karpenter가 대신해, 여러분은 모델과 서비스에 집중할 수 있습니다.

인프라의 복잡성은 관리형 서비스에 맡기고, 여러분은 모델과 서비스, 그리고 사용자에게 줄 가치에 집중하시길 바랍니다.

해당 내용은 아래 저의 Youtube 채널 영상에서도 확인하실 수 있습니다.

도움이 되셨다면 구독과 좋아요도 부탁드립니다. 😊