ECS GPU 공유: 추론 서비스를 꽉 채우기 전에 배포 여유를 계산하자

GPU 한 장을 여러 서비스가 쓰게 된 변화

AWS는 2026년 10월 27일 Amazon ECS에 NVIDIA Multi-Process Service(MPS)를 이용한 GPU 공유를 발표했다. 작은 모델 추론·임베딩 생성처럼 GPU 일부만 쓰는 작업을 함께 배치하는 기능이다. 대상은 ECS Managed Instances와 EC2 기반 ECS이며, 발표상 모든 AWS 상용 리전과 GovCloud(US) 리전에서 제공된다. 리전 제공과 원하는 인스턴스를 즉시 확보할 수 있는지는 별도 문제다. AWS 발표

이 글은 10월 30일 확인한 공식 문서에 근거한 운영 분석이다. 실제 AWS 계정에서 배포하거나 GPU 성능을 측정하지 않았다. 아래 숫자는 특정 GPU의 사양·벤치마크가 아니라, 공유 도입 전에 빠뜨리기 쉬운 배포 공간을 계산하기 위한 가정이다.

예를 들어 사내 검색 서비스가 작은 임베딩 모델을 사용한다고 하자. 요청이 드문 시간에는 GPU가 많이 쉬지만, 검색량이 몰리면 응답 지연이 중요해진다. 비용을 줄이려고 여러 복제본을 같은 GPU에 모을 때는 다음 세 질문이 남는다.

• 각 복제본이 필요한 메모리를 확보할 수 있는가?
• 동시에 바쁠 때도 검색 응답 목표를 지키는가?
• 기존 복제본을 유지한 채 새 버전을 먼저 올릴 수 있는가?

첫 번째만 통과하면 “실행 가능”에 가까워진다. 세 번째까지 통과해야 업데이트를 계속할 수 있는 운영 구성이 된다.

MPS가 함께 실행하는 것과 ECS가 배치하는 것

MPS는 여러 CUDA 프로세스의 작업을 같은 GPU에서 동시 실행할 수 있게 하는 장치다. NVIDIA는 개별 프로세스가 GPU를 충분히 채우지 못할 때 남는 실행 자원을 다른 프로세스의 커널로 활용하는 경우를 설명한다. 이미 한 프로세스가 자원을 충분히 사용한다면 공유만으로 처리 능력이 늘어난다고 기대할 수 없다. NVIDIA의 적용 조건

여기서 소프트웨어 공유를 서로 독립된 GPU 여러 장으로 이해하면 안 된다. NVIDIA 문서상 MPS 클라이언트는 각자의 GPU 주소 공간을 가지지만, 실행에 필요한 일부 자원은 공유한다. 주소 공간의 구분과 성능·장애의 완전한 독립은 다른 속성이다. MPS 구조

ECS에서는 컨테이너의 GPU 요구량에 sharingStrategy.nvidiaMps를 지정한다. 기존의 전용 GPU 수인 value와 함께 넣지 않는다. ResourceRequirement API

설정	의미	읽어서는 안 되는 의미
memory	MiB 단위 GPU 메모리 할당 요구량	모델 파일 크기만 입력하면 충분하다는 뜻
maxComputePercent	GPU 연산 사용의 상한	그 비율만큼 항상 확보되는 처리 성능

한 태스크 안에 GPU 컨테이너가 여러 개면 같은 물리 GPU에 놓이며, 그 GPU에 합계 메모리가 들어가야 한다. 연산 상한을 생략하면 MPS 서버의 active thread 비율을 따르고 기본값은 100이다. 따라서 운영 설정을 확인하지 않고 생략값을 별도 예약으로 취급해서는 안 된다. NvidiaMpsAllocation API

가령 두 컨테이너에 각각 maxComputePercent=50을 정했다고 해서 둘 다 혼자 실행할 때의 절반 속도를 얻는다는 계약은 없다. “각자 넘지 못할 상한”과 “요청마다 보장받는 서비스 시간”은 다르다. 지연을 판단할 때는 같은 입력·동시 요청에서 측정한 결과가 필요하다.

세 개는 들어가는데, 네 번째는 시작하지 못한다

이제 GPU 프로세스 한 개를 쓰는 컨테이너 한 개가 태스크 한 개를 구성한다고 가정하자. 이미 필요한 시스템 여유를 제외한 GPU 배치 예산을 22,528 MiB로 잡고, 태스크마다 6,144 MiB를 요구하도록 정한다. 이 값은 실제 장치에서 읽은 값이 아니다. CPU·호스트 메모리 등 나머지 배치 조건은 충족되며, 다른 GPU나 자동 확장 용량은 없다고 가정한다.

정상 상태의 복제본 세 개는 3 × 6,144 = 18,432 MiB로 예산에 들어간다. 남는 공간은 4,096 MiB다. 그런데 새 버전 태스크 하나를 먼저 올리려면 6,144 MiB가 더 필요하다. 기존 세 개와 새 한 개의 합은 24,576 MiB로 예산보다 2,048 MiB 많다.

가정한 운영 상태	정상 요구량	새 태스크 한 개 포함	메모리 계산의 결과
복제본 3개 유지	18,432 MiB	24,576 MiB	이 GPU에서는 먼저 추가할 수 없음
복제본 2개 유지	12,288 MiB	18,432 MiB	메모리 조건상 먼저 추가 가능

이 차이는 공유 기능의 오류가 아니다. 운영자가 정상 상태와 배포 상태에 서로 다른 수의 태스크를 요구하기 때문이다. ECS의 공유 배치는 GPU 메모리를 기준으로 하며 연산 사용률은 배치 판단에 포함하지 않는다. 연산이 한가하더라도 메모리 요구량을 만족하지 못하면 같은 결론이 난다. GPU 공유 배치 규칙

롤링 업데이트에서 minimumHealthyPercent=100, maximumPercent=200, desiredCount=3이라고 하자. 모두 정상인 기존 태스크를 세 개 유지하면서, 설정상 실행·대기 태스크는 최대 여섯 개까지 허용한다. 그러나 허용 개수는 GPU 공간을 제공하지 않는다. 다른 배치 가능한 자원이 없다는 위 가정에서는 새 태스크 하나를 먼저 실행할 메모리부터 부족하다. ECS 배포 설정

선택지는 세 가지다. 먼저 용량을 늘려 기존 복제본을 보존하거나, 실제 부하 시험을 거쳐 정상 복제본 수를 줄이거나, 일부 기존 태스크를 먼저 멈추는 배포를 허용할 수 있다. 마지막 선택은 교체 중 처리 여력을 줄이므로 설정값만 낮춰 해결했다고 볼 수 없다. 요청량이 많은 시간의 큐 대기와 실패를 함께 봐야 한다.

예제의 두 복제본 구성이 항상 더 좋다는 뜻도 아니다. 두 개로는 업무 처리량을 감당하지 못할 수 있다. 반대로 자동 확장이 제때 새 인스턴스를 확보한다면 세 개 구성을 유지한 채 배포할 수 있다. 이 계산은 선택지를 가르는 첫 조건이며 전체 스케줄러 시뮬레이션은 아니다.

메모리는 평균 대신 최악 입력을 기준으로 잡는다

도입 시험에서는 임베딩 요청의 최대 문서 길이와 허용 배치 크기를 먼저 고정한다. 평소의 짧은 문장만 넣어 얻은 사용량을 한도로 삼으면 긴 문서가 몰릴 때 판단이 달라질 수 있다. 생성형 모델이면 문맥·동시 시퀀스에 따른 캐시도 포함해야 한다. 그 계산의 배경은 LLM 추론 메모리 설명에서 이어 볼 수 있다.

또한 이 글의 단일 GPU 프로세스 가정을 벗어나면 한도 해석을 다시 확인해야 한다. AWS는 다중 GPU 프로세스 컨테이너의 합계 최고 사용량과 애플리케이션 차원의 통제를 별도로 요구한다. 설정한 숫자가 여러 프로세스의 합계 소비를 언제나 막아 준다고 일반화하지 않는다. 공유 시 고려사항

배포 후보를 비교할 때는 새 버전의 요구량도 다시 넣는다. 이전 버전이 6,144 MiB였어도 새 버전이 12,288 MiB를 요구한다면, 복제본 두 개를 유지할 때 남은 10,240 MiB로는 시작하지 못한다. “지난번 두 개로 배포했으니 이번에도 된다”가 성립하지 않는 반례다. 모델·추론 엔진·배치 설정이 바뀌면 정상·교체 계산을 함께 갱신한다.

공유 효과는 응답과 교체를 한 표에서 비교한다

다음은 실제 시험에 쓸 빈 관측 계획이다. 이 글에서 성능값을 수집한 표가 아니다. 동일한 모델·입력 묶음·요청 도착 패턴을 쓰고, 캐시와 준비 실행 조건을 맞춘다. 비교마다 결과 정확성도 확인한다.

비교할 실행	남길 관측	결정에 쓰는 방법
전용 GPU의 기준 실행	완료 요청/초, p95 응답 시간, 오류율	현재 업무 기준과 비교할 출발점
공유 복제본이 함께 바쁜 실행	같은 지표와 서비스별 큐 대기	합계 처리량 증가가 개별 응답 악화를 감추는지 확인
정상 부하 중 롤링 교체	새 태스크 준비 시간, 기존 응답, 배치 실패 사유	모델 로드와 건강 검사까지 감당하는지 확인
긴 입력·최대 허용 배치	메모리 부족, 실패 요청, 복구 후 정상 결과	운영 한도와 거절·재시도 조건 결정

p95는 관측 요청의 95%가 그 시간 이내에 끝났다는 뜻이다. 측정 기간과 표본 수를 함께 남겨야 한다. 공유 후 평균이 좋아져도 일부 요청의 긴 대기가 업무 목표를 넘으면 그 구성을 채택하지 않을 수 있다. 큐 대기와 추론 시간을 나누는 방법은 AI 지연의 임계 경로와 연결된다.

모니터링의 빈칸도 예상해야 한다. AWS 가이드는 MPS 공유에서 태스크·컨테이너별 GPU 이용률과 메모리 지표 일부를 제공하지 않는다고 명시한다. 해당 그래프가 없다고 사용량이 0인 것은 아니다. GPU 식별자·남은 메모리의 API 정보와 애플리케이션의 응답·오류 기록을 목적별로 조합한다. 공유 GPU 모니터링

배치 예산·부하 시험·교체 결과 기록지 내려받기

기록지에는 성능값이 비어 있다. 허용 p95·오류율·배포 시간을 팀이 먼저 정하고, 실제 시험 뒤 채택·추가 용량·전용 실행 가운데 하나를 선택하기 위한 양식이다.

같은 GPU의 복제본은 함께 영향을 받을 수 있다

같은 GPU에 복제본 세 개가 있다는 사실은 GPU 세 장에 흩어진 구성과 다른 장애 범위를 만든다. NVIDIA는 치명적인 GPU 오류가 관련 GPU를 공유하는 클라이언트에 전파될 수 있음을 설명한다. 독립된 주소 공간만으로 장애 영향까지 분리되는 것은 아니다. MPS 오류 격리 범위

Managed Instances의 자동 복구는 GPU·MPS 데몬의 장애를 감지해 인스턴스를 교체하는 기능이다. 기본 활성화된 복구 절차는 드레이닝과 대체 인스턴스 준비, 태스크 종료 유예를 포함한다. 이를 이미 진행 중인 추론 요청이 모두 보존된다는 약속으로 읽을 수는 없다. GPU 자동 복구 문서

사내 문서 임베딩을 비동기로 만드는 작업이라면 완료하지 못한 문서 ID를 다시 처리할 수 있는지 확인하는 것이 유용하다. 실시간 검색이라면 영향을 받지 않은 용량으로 요청을 넘길 수 있는지와 실패 응답의 처리 방식이 더 중요하다. 이는 이 글의 운영 설계 제안이며 장애 복구를 직접 시험한 결과가 아니다.

어떤 팀의 선택이 달라질까

ECS에서 작은 추론을 이미 운영하고, 함께 실행해도 응답 목표를 지키며, 업데이트 때의 추가 메모리와 장애 영향을 관리할 수 있는 팀이라면 MPS 공유를 검토할 이유가 생겼다. 반대로 한 작업이 GPU 대부분을 쓰거나 하드웨어 수준 격리가 필요하면 전용 자원 등 다른 구성이 더 적절할 수 있다.

환경 확인도 남는다. 10월 30일 가이드 기준 EC2 방식은 ECS 에이전트 1.107.0 이상과 AL2023 GPU 최적화 AMI 20261019 이상이 필요하다. Fargate는 이 GPU 공유 기능의 대상이 아니다. 지원 환경

팀별 할당량과 Kubernetes 전체 배치가 문제라면 Run:ai 운영 계층 분석이 다른 출발점이다. 이번 ECS 판단은 메모리에 들어가는 정상 구성, 응답 목표를 지키는 동시 실행, 다음 버전을 올릴 교체 공간을 한꺼번에 만족하는지에 집중한다. 배포 전에 기록지를 다시 채워 볼 수 있도록 이 글을 저장해 두면 된다.