홈강좌LAYA 결정 모델 24편 중 13편째
학습한 LAYA 를 어디에 올릴까 — EC2·컨테이너 서비스·Lambda·관리형 비교
맥북에서 학습한 LAYA 는 파일 몇 개다. 그래서 어디로든 옮길 수 있다. 이 편은 EC2 CPU·EC2 GPU·컨테이너 서비스·Lambda·관리형(Hugging Face, SageMaker)을 속도·수고·켜 두는 비용으로 비교하고, 요청량과 응답 시간에 따라 고르는 기준을 정리한다. 실행한 예제는 없고, 수치는 공식 문서의 것이다.
01 옮기는 것은 무엇인가
7편에서 본 체크포인트 폴더 가운데 서비스에 필요한 것은 이것뿐이다.
| 파일 | 크기(v1 기준) |
|---|---|
model.safetensors | 614MB |
tokenizer/ | 33MB |
encoder/·rl_agent_config.json·questions.json | 몇 KB |
학습 중 백업인 checkpoint_latest/(647MB)는 빼도 된다. 이 파일들과 laya[serve](12편의 HTTP 서버)를 한 컨테이너 이미지에 담아 두면(14편) 아래 어느 곳에든 같은 이미지를 올릴 수 있다.
맥북의 GPU(MPS)는 서버에 없다. 서버에서는 CPU 로 돌리거나 NVIDIA GPU(CUDA) 로 돌린다. 학습한 가중치는 그대로 쓰고, 어디서 계산할지만 바뀐다.
02 CPU 로 충분한가
모델 카드의 수치(Tesla T4 GPU 기준)와 CPU 수치는 이렇다.
| 어디서 | 질문 1개 판단 |
|---|---|
| GPU(T4), 다국어 체크포인트 | 32.8ms |
| CPU(라우터를 거친 판단) | 193~464ms |
결정 모델은 작아서 CPU 로도 1초 안에 답한다. 초당 수십 건을 넘지 않는 사내 도구·문의 분류라면 CPU 로 시작하는 것이 가장 싸고 쉽다. 14편에서 컨테이너를 CPU 로 띄워 실제 시간을 잰다.
03 선택지 비교
| 선택지 | 무엇을 하나 | 좋은 점 | 신경 쓸 것 |
|---|---|---|---|
| EC2 + Docker(CPU) | 가상 서버 하나에 14편의 이미지를 띄운다 | 가장 단순하다. 늘 켜져 있어 첫 요청도 빠르다. ARM(Graviton) 서버용 이미지도 공식 문서에 안내가 있다 | 서버 관리(보안 업데이트·HTTPS·재시작)를 직접 한다. 안 쓰는 시간에도 요금이 든다 |
| EC2 GPU(g4dn.xlarge) | T4 GPU 1개·vCPU 4·메모리 16GiB 서버 | 판단이 수십 ms. 요청이 많을 때 한 대로 버틴다 | GPU 서버는 CPU 서버보다 훨씬 비싸다. NVIDIA 드라이버와 CUDA 판 이미지가 필요하다 |
| 컨테이너 서비스(ECS·App Runner) | 이미지를 맡기면 띄우고 늘리고 다시 시작해 준다 | 서버 관리가 준다. 판 교체·되돌리기가 쉽다 | ECS 에서 GPU 는 EC2 컨테이너 인스턴스로 쓴다. 기본은 CPU 로 생각한다 |
| Lambda(컨테이너 이미지) | 요청이 올 때만 함수를 띄운다 | 요청이 드물면 가장 싸다 | 이미지 10GB·메모리 10,240MB·실행 15분이 한도다. 쉬던 함수는 600MB 모델을 다시 올리느라 첫 요청이 느리다 |
| Hugging Face Inference Endpoints | Hub 에 올린 모델이나 내 컨테이너를 관리형 엔드포인트로 띄운다 | Hub 의 비공개 저장소로 판 관리가 함께 된다 | 요금 체계와 지역을 미리 본다 |
| SageMaker 실시간 엔드포인트 | AWS 관리형 추론 엔드포인트 | 자동 확장·모니터링이 AWS 안에서 묶인다 | 설정할 것이 많다. 작은 서비스에는 무겁다 |
요금은 지역·시점마다 다르니 각 서비스의 가격 페이지에서 직접 계산한다.
04 요청량으로 고르기
- 하루 수백 건, 사내 도구 — EC2 CPU 작은 서버 하나, 또는 Lambda. 쉬는 시간이 길면 Lambda 가 싸고, 첫 요청 지연(수 초)이 싫으면 EC2.
- 늘 요청이 들어오는 서비스, 응답 1초 안팎이면 됨 — EC2 CPU 나 컨테이너 서비스(CPU). 판 교체를 자주 한다면 컨테이너 서비스가 편하다.
- 초당 수십 건 이상, 수십 ms 응답 — GPU(g4dn 등). 여러 질문을 한 번에 묻는 묶음 요청(
/v1/systemone/batch)으로 GPU 를 꽉 채운다.
어느 경우든 처음에는 가장 단순한 것(EC2 CPU 한 대)으로 시작하고, 실제 요청량과 응답 시간을 재서 옮기는 편이 낫다. 결정 모델은 작아서 옮기기 쉽다.
05 판은 어떻게 관리하나
지속 학습을 하면 판이 계속 생긴다(v1·v2·…). 어디에 올리든 판을 나누는 방법은 둘이다.
- 이미지 태그 —
laya-tickets:v2처럼 판마다 이미지를 만든다(14편). 되돌리기는 이전 태그를 다시 띄우는 것이다. - 모델 저장소 — Hugging Face Hub 비공개 저장소나 S3 에 판마다 올리고, 서버는 시작할 때 정해진 판을 내려받는다.
laya.load는 Hub 의 특정 커밋(revision=)을 고를 수 있고, 내려받은 파일의 해시를 미리 확인하는 기능(expected_sha256)도 있다.
이 시리즈는 이미지 태그 방식으로 간다. 이미지 하나에 코드·모델·설정이 함께 묶여 "지금 무엇이 돌고 있나" 가 태그 하나로 정해지기 때문이다. 다음 편에서 v2 를 이미지로 만들어 띄운다.