기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

CPU 추론 및 오케스트레이션

개요

CPU 인스턴스는 Amazon EKS의 다양한 AI 워크로드를 위한 일류 컴퓨팅 옵션입니다. 소규모 언어 모델(SLMs) 및 클래식 ML 추론부터 데이터 파이프라인 및 에이전트 오케스트레이션에 이르기까지 CPUs 강력한 가격 대비 성능, 광범위한 용량 가용성 및 친숙한 Kubernetes 스케줄링 시맨틱을 제공합니다.

CPU와 GPU는 상호 보완적이며 경쟁적이지 않습니다. 에이전트 AI 파이프라인의 복잡성이 증가함에 따라 CPU 워크로드 표면도 함께 증가합니다. 모든 추론 호출은 CPU에서 모두 실행되는 도구 실행, 컨텍스트 어셈블리, 벡터 검색, 가드레일 및 오케스트레이션 로직으로 둘러싸여 있습니다. 두 컴퓨팅 유형을 모두 의도적으로 사용하는 아키텍처를 설계하여 각 워크로드를 최상의 비용 성능을 제공하는 계층에 배치하는 것이 좋습니다.

모든 워크로드에 GPU가 필요한 것은 아닙니다. 라우팅, 분류, 검색, 임베딩, 오케스트레이션 및 점점 늘어나는 언어 모델 추론은 모두 CPU에서 효과적으로 실행됩니다. arm64 및 x86 전반의 현재 세대 CPU 인스턴스는 ML 추론에 강력한 가격 대비 성능을 제공합니다. Karpenter의 노드 통합, KEDA의 이벤트 기반 조정 및 양자화된 모델 서비스와 결합하여 플랫폼 팀이 심층적인 GPU 전문 지식 없이 운영할 수 있는 프로덕션 지원 스택을 제공합니다.

이 가이드의 용도는 다음과 같습니다.

학습할 내용:

AI 워크로드용 CPUs를 사용해야 하는 이유

프로덕션 AI 파이프라인은 여러 컴퓨팅 계층에 작업을 분산합니다. CPUs 라우팅, 분류, 검색, 오케스트레이션 및 점점 늘어나는 추론을 처리합니다. 현재 세대 CPU 인스턴스는 강력한 가격 대비 성능과 친숙한 Kubernetes 스케줄링을 제공하므로 많은 AI 워크로드에 실용적인 옵션입니다.

이러한 워크로드에 CPU를 강력하게 만드는 세 가지 요소는 다음과 같습니다.

용량 가용성

GPU 인스턴스는 몇 주 전에 용량 예약이 필요한 경우가 많습니다. CPU 인스턴스는 전문 디바이스 플러그인, DRA 구성, MIG 파티셔닝 없이 모든 AWS 리전에서 광범위하게 사용할 수 있습니다. 빠르게 확장해야 하는 경우 CPU 용량을 가장 쉽게 사용할 수 있는 옵션입니다.

경제학

현재 세대 CPU 인스턴스는 ML 추론에 강력한 가격 대비 성능을 제공합니다. FinOps 검토를 실행하거나 다중 테넌트 클러스터를 관리하는 팀의 경우 CPU와 GPU 간의 비용 차이가 매우 큽니다. 특히 GPU 가속화로 수익이 감소하는 양자화된 SLMs 경우 더욱 그렇습니다. 워크로드에 가장 적합한 cost-per-token 찾으려면 사용 가능한 인스턴스 패밀리(Graviton, AMD, Intel)를 벤치마킹하는 것이 좋습니다.

운영 간소화

CPU 포드는 표준 Kubernetes 일정(requests, limits, 노드 선호도, 토폴로지 분산)을 사용합니다. 디바이스 플러그인, 사용자 지정 스케줄러, nvidia.com/gpu 리소스 유형이 없습니다. 심층적인 GPU 전문 지식 없이 AI 워크로드를 실행하려는 팀은 CPU에서 더 빠르게 프로덕션에 도달할 수 있습니다.

에이전트 파이프라인에서 CPU 표면 증가

에이전트 AI 파이프라인에서 모든 GPU 추론 호출은 도구 실행, 컨텍스트 어셈블리, 벡터 검색, 임베딩 조회, 가드레일, 응답 검증, 메모리 관리 및 오케스트레이션 로직과 같은 CPU 작업으로 둘러싸여 있습니다. 에이전트가 더 복잡해지면(더 많은 도구, 더 긴 체인, 다단계 추론) 이러한 CPU 워크로드는 매우 선형적으로 증가합니다. MCP(모델 컨텍스트 프로토콜)와 같은 프로토콜은 이를 더욱 증폭합니다. 각 MCP 도구 호출은 CPU에서 완전히 실행되는 데이터 검색, 변환 및 형식을 트리거합니다.

CPU vs GPU / Trainium: 각 항목을 선택해야 하는 경우

워크로드 결정 프레임워크

AI 워크로드에 적합한 컴퓨팅을 선택하는 것은 네 가지 차원으로 내려갑니다.

아래 표를 의사 결정 매트릭스로 사용합니다.

빠른 벤치마크 워크플로

인스턴스 패밀리에 커밋하기 전에 대상 p95 지연 시간에서 1,000개 쿼리당 비용이라는 단일 비교 지표에서 후보 CPU 패밀리(arm64 및 x86)를 GPU와 비교하는 구조화된 벤치마크를 실행하는 것이 좋습니다. 동일한 모델 구성(동일한 양자화, 컨텍스트 크기, 스레드 수)으로 패밀리당 하나의 노드를 배포하고 각 노드를 로드 테스트하고 비교합니다. CPU 인스턴스가 p95 SLO를 충족하는 경우 비용이 발생할 수 있습니다. 작은 여백으로 인해 놓치는 경우 GPU로 이동하기 전에 해당 패밀리의 최신 세대를 사용해 보세요. 동시성 대상에서 지연 시간이 여전히 너무 높으면 워크로드를 GPU로 이동하는 신호입니다.

프로덕션 패턴

패턴 1: 에이전트 AI - LLM 에스컬레이션을 사용하는 CPU의 SLM 프리 필터

대부분의 에이전트 워크플로는 요청을 분류하고, 도구를 선택하고, 구조화된 데이터를 추출하고, 응답을 검증하는 등 동일한 좁은 패턴을 반복적으로 실행합니다. 이러한 작업에는 70B 파라미터 모델이 필요하지 않습니다.

SLMs에 대한 연구(arXiv:2506.02153)는 10B 파라미터 미만의 모델이 도메인에 특화된 경우 상당히 낮은 비용과 지연 시간으로 CPU에서 효율적으로 실행되는 동시에 제한된 하위 작업에서 대규모 LLMs과 일치하거나 초과할 수 있음을 보여줍니다. 모델이 특정 도메인에 맞게 미세 조정되면 설치 공간이 작을수록 범용 LLM을 호출하는 것보다 더 정확하고 저렴할 수 있습니다.

이 패턴에서 CPU의 SLM은 대부분의 요청을 end-to-end 처리합니다. 라우팅 계층(CPU에서도 실행됨)은 실제로 복잡한 사례만 GPU 호스팅 LLM으로 에스컬레이션합니다.

CPU에서 실행되는 구성 요소:

GPU/Trainium의 구성 요소:

이 패턴이 작동하는 이유: 많은 에이전트 워크플로에서 요청의 60~80%는 SLM에서 분류하거나 추출할 수 있습니다. 또한 LLM 호출을 피할 때마다 큰 컨텍스트 창을 수집하고, 긴 응답에서 가드레일을 실행하고, 복잡한 상태를 관리하는 주변 CPU 작업을 피할 수 있습니다. CPU 계층은 GPU 계층과 독립적으로 조정됩니다.

일반적인 에이전트 파이프라인의 CPU 워크로드 범주에는 도구 실행(MCP 서버 호출, API 호출, 데이터베이스 쿼리), 컨텍스트 어셈블리, 벡터 검색 및 임베딩 조회, 오케스트레이션 및 계획 로직, 가드레일 및 안전 필터링, 응답 검증 및 형식 지정, 에이전트 메모리 및 상태 관리, 로깅/관찰성이 포함됩니다.

이 패턴은 미세 조정 수명 주기에도 적합합니다. CPU 노드에서 도메인 데이터를 수집하고 GPU에서 미세 조정한 다음 LLM 엔드포인트보다 훨씬 저렴한 비용으로 추론을 위해 정량화된 모델을 CPU에 다시 배포합니다. LoRA Land(arXiv:2405.00732)의 연구에 따르면 미세 조정된 7B 모델은 테스트된 대부분의 도메인별 작업에서 GPT-4보다 성능이 뛰어나 많은 프로덕션 사용 사례에서 "작은 모델을 미세 조정하고 CPU에서 실행" 경로를 실행할 수 있습니다.

패턴 2: 고밀도 CPU 모델 팜

프로덕션 ML 파이프라인은 임베딩, 추천자, 분류자, BERT 기반 득점자, 컴퓨터 비전 모델 등 수백 또는 수천 개의 작은 모델을 정기적으로 배포합니다. 개별적으로 가벼운 이러한 모델은 각에 자체 GPU 리소스가 할당되면 비용이 많이 듭니다.

Karpenter 관리 노드 수명 주기 및 관찰된 로드에 대한 KEDA 조정과 함께 고밀도 CPU 서비스(CPU에서 TorchServe 또는 Triton을 사용하여 노드당 여러 모델 빈 패킹)를 사용하는 것이 좋습니다.

이 패턴은 RAG 아키텍처로 자연스럽게 확장됩니다. OpenSearch에서 임베딩 생성, 문서 청킹 및 검색은 모두 CPU 노드에서 비용 효율적으로 실행되어 최종 생성 단계에서만 GPU 호스팅 LLM에 결과를 제공합니다. CPU 팜은 볼륨을 처리하고 GPU는 복잡성을 처리합니다.

규제 대상 산업(금융 서비스, 의료, 정부)의 경우이 패턴은 특히 강력합니다. CPU에서 VPC로 실행되는 수백 개의 특수 모델과 계정을 벗어나지 않는 전체 감사 추적 및 데이터가 있습니다. 자체 관리형 추론에 대한 규정 준수 요구 사항은 sub-8B 모델의 CPU 비용 이점과 자연스럽게 일치합니다.

최적화 모범 사례

양자화

CPU에서 전체 BF16으로 7B 모델을 실행하는 것은 실용적이지 않습니다. Q4 양자화에서 모델을 실행하는 것은 실행 가능하고 비용 효율적입니다. 양자화가 CPU에 도움이 되는 이유를 이해하는 것이 올바른 인프라 결정을 내리는 데 중요합니다.

CPU 추론에서 양자화가 중요한 이유. CPU 추론은 컴퓨팅 경계가 아닌 메모리 대역폭 경계입니다. 디코딩 단계(한 번에 하나씩 토큰 생성) 동안 모델의 전체 가중치는 생성된 모든 토큰에 대해 RAM에서 읽습니다. CPU는 대부분의 시간을 수학을 하지 않고 메모리에서 데이터가 도착할 때까지 기다립니다. BF16의 7B 모델은 약 14GB이며 Q4_K_M에서는 약 4GB로 축소됩니다. 병목 현상이 RAM에서 CPU 코어로 바이트 이동하기 때문에 3.5배 더 작은 모델은 읽기 속도가 3.5배 더 빠르므로 거의 3.5배 더 빠른 토큰 생성으로 직접 변환됩니다. 이것이 양자화가 CPU 추론에 가장 영향을 미치는 단일 최적화인 이유와 메모리 채널이 더 많은 최신 CPU 세대가 동일한 클럭 속도에서도 더 빠른 추론을 생성하는 이유입니다.

아키텍처 최적화 백엔드(ARM64의 경우 ARM NEON/SVE2, x86의 경우 AVX-512/AMX)를 사용하여 추론 엔진을 구축하고, 스레드 수를 vCPU 수와 동일하게 설정하고, Q4_K_M 또는 Q8_0 양자화 형식을 선택하는 것이 좋습니다.

sub-2B 모델의 경우 CPU는 GPU와 비교하여 가격 대비 성능이 뛰어납니다. 이러한 모델은 GPU 가속화가 최소한의 이점을 제공할 만큼 작지만 시간당 비용은 훨씬 더 높습니다. 워크로드가 sub-2B 모델을 사용할 수 있는 경우 CPU가 권장되는 기본값입니다.

아키텍처별 최적화: arm64에서 현재 세대 Graviton 인스턴스는 SVE2를 지원합니다. 대상에 적합한 -march 플래그를 사용하여 추론 엔진을 빌드합니다. x86에서 AMD EPYC 인스턴스는 AVX-512를 지원하고 Intel Xeon 인스턴스는 매트릭스 가속화를 위해 AMX를 추가합니다. 추론은 메모리 대역폭 경계이므로, 더 많은 DDR5 메모리 채널이 있는 최신 CPU 세대는 동일한 클럭 속도에서도 더 빠른 추론을 생성합니다. 인스턴스 유형을 선택할 때 코어 수보다 메모리 대역폭의 우선 순위를 지정합니다.

컨텍스트 창 크기 조정: 분류 및 라우팅 워크로드의 경우 입력은 일반적으로 토큰 200개 미만이고 출력은 토큰 2~3개입니다. 기본 2048 대신 작은 컨텍스트 창(예: 토큰 512개)을 설정하면 KV 캐시 메모리 사용량이 줄어들고 요청당 지연 시간이 개선됩니다. 입력이 실제로 긴 경우에만 컨텍스트 기간을 늘립니다.

Flash Attention: 추론 엔진이 Flash Attention을 지원하는 경우 Flash Attention을 활성화합니다. Flash Attention은 전체 관심 행렬의 구체화를 방지하여 관심 계산을 위한 메모리 사용량을 줄입니다. CPU에서는 GPU보다 이점이 작지만 더 긴 입력에는 여전히 도움이 됩니다.

밀집 제공을 위한 빈 패키징

클래식 ML 및 임베딩 모델(일반적으로 각각 <500MB)의 경우 목표는 안정적인 테일 지연 시간에서 노드당 최대 포드 밀도입니다. 이를 달성할지 여부는 정확한 리소스 요청과 제어된 스레딩이라는 두 가지로 결정됩니다.

실제 부하에서 관찰된 p50-p90 사용량requests을 기반으로 합니다. 로드 테스트에서 Goldilocks, VPA 권장 사항 또는 Prometheus 히스토그램을 사용합니다. 기본값은 거의 항상 양방향으로 잘못되어 있습니다.

ML 라이브러리(PyTorch, ONNX 런타임, MKL, OpenBLAS)는 포드에 할당된 CPUs가 아닌 노드에서 vCPUs를 볼 수 있는 수만큼 스레드를 생성합니다. 포드가 20개인 고밀도 노드에서는 모든 포드가 32개의 스레드를 생성하려고 시도합니다. 노드는 컨텍스트 전환 시 스래시되고 p99 지연 시간이 급증합니다. 이 문제를 명시적으로 수정합니다.

env:
  - name: OMP_NUM_THREADS
    value: "2"          # match your cpu request (2000m = 2 threads)
  - name: MKL_NUM_THREADS
    value: "2"
  - name: OPENBLAS_NUM_THREADS
    value: "2"
  - name: INTRA_OP_NUM_THREADS    # PyTorch / ONNX Runtime
    value: "2"
  - name: NUM_INTER_THREADS
    value: "1"          # keep inter-op parallelism minimal

각 값을 CPU 요청과 같거나 낮게 설정합니다. 코어가 4개 이상인 포드의 경우 2~4개 스레드부터 벤치마킹합니다. 캐시 효율성으로 인해 스레드 수를 줄이면 많은 소형 모델의 성능이 향상됩니다. 여러 개의 얇은 포드에서 HPA를 사용하는 경우 포드당 1~2개의 스레드가 거의 항상 성공합니다.

예약 및 비용 최적화

CPU 추론 비용을 크게 줄이는 두 가지 사례인 Karpenter 통합을 사용하는 스팟 인스턴스와 다중 아치 컨테이너 이미지.

Karpenter의 통합은 대기열 또는 로드 밸런서 뒤의 상태 비저장 추론 포드가 중단을 정상적으로 허용하기 때문에 CPU 추론에 적합합니다. 스케일 다운 중에 용량이 감소하지 않도록 동시 중단(예: 한 번에 노드의 20%)을 제한하는 예산으로 사용률이 낮은 노드에서 작동하도록 통합을 구성합니다. Karpenter의 nodePool 사양을 사용하면 단일 풀에서 스팟과 온디맨드 용량을 혼합하고 스팟을 기본 옵션으로, 온디맨드를 대체할 수 있습니다.

다중 아치 이미지(arm64 및 amd64)를 빌드하면이 기능이 추가로 잠금 해제됩니다. 두 아키텍처를 모두 사용할 수 있는 경우 Karpenter는 실시간 가격 및 가용성에 따라 전체 인스턴스 패밀리(Graviton, AMD, Intel) 중에서 선택할 수 있습니다. 이는 인스턴스 유형 및 아키텍처를 다각화하여 중단 빈도를 줄이는 스팟 워크로드에 특히 유용합니다. 다중 플랫폼 빌드와 함께 docker buildx 또는 CI 파이프라인을 사용하여 두 아키텍처를 모두 포함하는 단일 매니페스트를 생성합니다.

컨테이너 시작 최적화

Karpenter가 새 노드를 프로비저닝하면(스케일 업, 스팟 교체) 포드를 시작하기 전에 컨테이너 런타임에서 추론 이미지를 가져와야 합니다. 다중 GB 추론 이미지의 경우 포드 시작에 30~60초를 추가할 수 있습니다.

Bottlerocket을 추론 워크로드의 노드 OS로 사용하고 병렬 풀/언팩 모드에서 SOCI 스냅샷 생성기와 함께 사용하는 것이 좋습니다. SOCI는 기본 순차 계층 추출을 병렬 청크 기반 다운로드로 대체하여 대용량 이미지의 이미지 가져오기 시간을 크게 줄입니다. 컨테이너 이미지를 변경할 필요가 없습니다.

자세한 구성 지침은 SOCI 구성, EBS 스냅샷 사전 풀링 및 컨테이너 런타임 캐시 전략을 다루는이 가이드의 성능 섹션을 참조하세요.

관찰성

모델 계층에서 관찰성이 없으면 맹목적으로 조정됩니다. 모든 추론 서비스에 Prometheus 지표를 노출하고 이를 사용하여 KEDA 조정 및 운영 대시보드를 모두 구동하는 것이 좋습니다.

대부분의 추론 서버(llama.cpp, vLLM, Triton, TorchServe)는 /metrics 엔드포인트에서 Prometheus 호환 지표를 노출합니다. 지표 이름은 서버마다 다르지만 개념은 동일합니다.

계측할 주요 지표:

Autoscaling: CPU 사용률이 아닌 대기열 깊이에 따라 조정

CPU 사용률은 포화 지표입니다. 지연 시간이 이미 저하된 후에는 급증합니다. 사용률 기반 자동 크기 조정이 반응할 때까지 사용자는 이미 기다리고 있습니다.

대기열 깊이(요청 지연/대기)는 선행 지표입니다. 모든 처리 슬롯이 사용 중일 때 요청이 대기열에 추가되기 때문에 지연 시간이 저하되기 전에 증가합니다. 대기열 깊이를 조정하면 기존 복제본이 정상적으로 응답하는 동안 새 복제본이 프로비저닝됩니다.

KEDA는를 사용하여 여러 지표를 단일 조정 공식으로 결합하는 것을 지원합니다scalingModifiers(KEDA 2.12 이상 필요). 추론 워크로드에 권장되는 패턴은 진행 중인 요청을 대기열에 있는 요청과 결합하여 대기열 지표를 크게 강조하는 것입니다.

advanced:
  scalingModifiers:
    formula: "running + (waiting * 10)"
    target: "25"
    activationTarget: "5"

공식은 대기 중인 요청 3개running + (waiting * 10)도 결합된 지표를 25개 목표보다 훨씬 높은 55개로 푸시한다는 의미입니다. 지연 시간이 저하되기 전에 조정이 시작됩니다. activationTarget의 5는 노이즈가 불필요한 scale-from-zero 이벤트를 트리거하지 못하도록 합니다.

CPU 우선 워크로드에 대한 모델 품질 평가

CPU에 양자화된 SLM을 배포하는 것은 비용 및 지연 시간 결정입니다. 모델이 여전히 워크로드에 대해 올바르고 유용한 출력을 생성하는 경우에만 적합합니다.

모델 또는 양자화가 작을수록 컴퓨팅 비용이 절감되지만 품질은 저하될 수 있습니다. 영향은 다양합니다. CPU에서 잘 작동하는 워크로드(분류, 추출, 라우팅, 요약, 임베딩)는 적절한 양자화 및 프롬프트를 통해 3B-7B 범위에서 좋은 품질을 유지하는 경우가 많습니다.

평가할 항목

워크로드마다 다른 방식으로 성능이 저하됩니다.

실용적인 평가 워크플로

인스턴스 유형을 선택하기 전에 로드 테스트를 실행하는 방법과 마찬가지로 프로덕션 전에 품질 검사를 생성하는 것이 좋습니다. 워크플로에는 네 단계가 있습니다.

품질을 복구하는 방법

모델 성능이 좋지 않은 경우 작업 순서대로 시도해 보세요.

참조