AI 모델 서빙 학습 시리즈 0단계

서빙의 전체 그림 먼저 보기

📚 앞으로 진행할 Serving 학습 시리즈

단계주제핵심 질문

1단계	Serving이란?	학습한 모델을 어떻게 서비스로 만드는가?
2단계	모델 파일 이해	모델은 파일인가? 폴더인가? 스토리지에 저장하는가?
3단계	Inference 개념	추론은 무엇이고 학습과 뭐가 다른가?
4단계	KServe 개념	KServe는 ALB인가? 모델 배포 도구인가?
5단계	InferenceService	Kubernetes에서 Serving을 정의하는 리소스는 무엇인가?
6단계	ServingRuntime	모델을 실제 실행하는 Runtime은 무엇인가?
7단계	Storage URI	s3://, pvc://, hf:// 같은 경로는 무엇인가?
8단계	Pod / Service / Endpoint	요청은 실제로 어디로 들어가고 어디서 처리되는가?
9단계	CPU / Memory / GPU	Serving 생성 시 자원은 어떻게 정해야 하는가?
10단계	Replica / Auto Scaling	요청이 많아지면 어떻게 확장되는가?
11단계	모델 배포 후 확인	Ready, Running, Failed 상태는 무슨 뜻인가?
12단계	API 호출 실습	curl로 모델을 호출하면 어떤 일이 생기는가?
13단계	장애 분석	Pending, OOM, ModelLoadFailed, ImagePullBackOff 원인
14단계	LLM Serving	vLLM, Hugging Face, GPU 메모리, KV Cache
15단계	운영 관점	모니터링, 로그, 비용, 안정성, 버전 관리

0단계에서 먼저 이해해야 할 큰 그림
AI 모델 서빙이란 무엇인가?
학습, 추론, 서빙은 어떻게 다른가?
모델 서빙의 전체 흐름
모델 파일은 어디에 저장되는가?
Serving 생성 시 내부에서 일어나는 일
KServe는 어떤 역할을 하는가?
사용자는 최종적으로 무엇을 호출하는가?
초보자가 가장 많이 헷갈리는 부분
0단계 핵심 요약

1. 0단계에서 먼저 이해해야 할 큰 그림

AI 모델 서빙을 처음 배우면 여러 용어가 한꺼번에 등장합니다.

예를 들면 다음과 같습니다.

Model
Inference
Serving
Runtime
Endpoint
Pod
Service
KServe
InferenceService
ServingRuntime
Storage URI
GPU
Replica
Auto Scaling

처음부터 이 용어를 전부 외우려고 하면 어렵습니다.

그래서 가장 먼저 해야 할 일은 서빙의 전체 구조를 큰 그림으로 이해하는 것입니다.

AI 모델 서빙을 아주 쉽게 말하면 다음과 같습니다.

학습이 끝난 AI 모델을
다른 사용자나 프로그램이 사용할 수 있도록
API 서비스 형태로 실행해 두는 것

예를 들어 고양이와 강아지를 구분하는 AI 모델이 있다고 해보겠습니다.

사용자가 사진을 보내면 AI가 다음처럼 결과를 돌려줍니다.

고양이일 확률: 97%
강아지일 확률: 3%

그런데 이 기능을 사용하려면 단순히 모델 파일만 있으면 안 됩니다.

모델 파일을 읽어서 실행하는 서버가 필요하고, 사용자가 요청을 보낼 수 있는 주소도 필요합니다.

즉, 모델을 실제 서비스처럼 사용할 수 있는 상태로 만드는 과정이 바로 모델 서빙입니다.

2. AI 모델 서빙이란 무엇인가?

서빙의 기본 의미

서빙이라는 단어는 원래 “제공하다”라는 의미입니다.

AI에서 서빙은 다음 의미로 사용됩니다.

학습된 모델을 실행 가능한 서버 형태로 배포하고,
사용자의 요청을 받아 예측 결과를 반환하는 과정

더 쉽게 표현하면 다음과 같습니다.

AI 모델을 실제 서비스로 사용할 수 있게 만드는 과정

예를 들어 이미지 분류 모델이 있다고 해보겠습니다.

학습이 끝난 모델 파일은 이런 식으로 저장되어 있을 수 있습니다.

cat-dog-model/
├── model.onnx
├── labels.json
└── preprocessor_config.json

하지만 이 파일만 있다고 사용자가 바로 쓸 수 있는 것은 아닙니다.

사용자가 이미지를 보내면 모델이 그 이미지를 읽고, 계산하고, 결과를 돌려줘야 합니다.

이때 필요한 것이 모델 서버입니다.

사용자
  ↓
이미지 전송
  ↓
모델 서버
  ↓
고양이/강아지 판단
  ↓
결과 반환

이 모델 서버를 Kubernetes 위에 만들고 운영하는 과정이 서빙입니다.

3. 학습, 추론, 서빙은 어떻게 다른가?

초보자가 가장 먼저 구분해야 하는 개념은 세 가지입니다.

학습
추론
서빙

이 세 가지는 비슷해 보이지만 역할이 다릅니다.

구분의미예시

학습	모델을 만드는 과정	고양이/강아지 사진을 많이 보여주며 훈련
추론	학습된 모델로 결과를 계산하는 과정	새 사진을 보고 고양이인지 강아지인지 판단
서빙	추론 기능을 API 서비스로 제공하는 과정	사용자가 URL로 사진을 보내면 결과를 돌려줌

쉽게 비유하면 이렇습니다.

학습 = 공부하는 과정
추론 = 문제를 푸는 과정
서빙 = 문제 풀이 서비스를 운영하는 과정

학생으로 비유해보겠습니다.

학생이 교재로 공부한다
→ 학습

학생이 시험 문제를 푼다
→ 추론

학생이 학원에서 질문을 계속 받아 답변해준다
→ 서빙

AI 모델도 비슷합니다.

데이터로 모델을 학습한다
→ 학습

학습된 모델이 새 입력값에 대해 답을 계산한다
→ 추론

그 추론 기능을 다른 사람이 계속 사용할 수 있게 서버로 운영한다
→ 서빙

4. 모델 서빙의 전체 흐름

AI 모델 서빙의 전체 흐름은 다음과 같습니다.

흐름 ① 데이터 준비
      ↓
흐름 ② 모델 학습
      ↓
흐름 ③ 모델 파일 생성
      ↓
흐름 ④ 모델 파일 저장
      ↓
흐름 ⑤ Serving 생성
      ↓
흐름 ⑥ 모델 서버 Pod 실행
      ↓
흐름 ⑦ Endpoint 생성
      ↓
흐름 ⑧ 사용자/API 요청
      ↓
흐름 ⑨ 추론 결과 반환

이제 각 흐름을 하나씩 쉽게 풀어보겠습니다.

흐름 ① 데이터 준비

먼저 모델을 학습시키기 위한 데이터가 필요합니다.

예를 들어 고양이/강아지 분류 모델이라면 이런 데이터가 필요합니다.

고양이 사진 10,000장
강아지 사진 10,000장
각 사진의 정답 라벨

정답 라벨은 이런 의미입니다.

cat001.jpg → 고양이
dog001.jpg → 강아지

모델은 이 데이터를 보면서 고양이와 강아지의 차이를 학습합니다.

흐름 ② 모델 학습

학습 과정에서는 모델이 데이터를 반복해서 봅니다.

처음에는 모델이 거의 랜덤하게 예측합니다.

실제 정답: 고양이

모델 예측:
고양이 30%
강아지 70%

틀렸기 때문에 모델은 내부 숫자 값을 조금씩 수정합니다.

이 내부 숫자를 보통 가중치라고 합니다.

가중치 수정 전: 0.2183
가중치 수정 후: 0.2191

이런 조정을 수많은 데이터에 대해 반복합니다.

충분히 학습되면 모델은 점점 더 정확하게 예측합니다.

실제 정답: 고양이

모델 예측:
고양이 97%
강아지 3%

흐름 ③ 모델 파일 생성

학습이 끝나면 모델 결과물이 파일로 저장됩니다.

모델 파일은 하나일 수도 있고 여러 개일 수도 있습니다.

작은 모델은 하나의 파일일 수 있습니다.

model.pkl
model.joblib
model.onnx
model.pt
model.pth

큰 모델, 특히 LLM은 여러 파일로 나뉘어 저장될 수 있습니다.

llm-model/
├── config.json
├── tokenizer.json
├── tokenizer_config.json
├── model.safetensors.index.json
├── model-00001-of-00004.safetensors
├── model-00002-of-00004.safetensors
├── model-00003-of-00004.safetensors
└── model-00004-of-00004.safetensors

이 파일들에는 다음 정보가 들어갑니다.

학습된 가중치
모델 구조
입력 데이터 처리 방식
출력 라벨 정보
토크나이저 정보
추론 설정값

즉, 모델은 단순한 코드 파일이 아니라 학습 결과가 저장된 파일들의 집합이라고 이해하면 됩니다.

흐름 ④ 모델 파일 저장

학습된 모델은 보통 스토리지에 저장합니다.

대표적인 저장 위치는 다음과 같습니다.

Object Storage
PVC
NFS
NAS
Lustre
Hugging Face Hub
Container Image

예를 들어 Object Storage에 저장하면 다음과 같은 구조가 됩니다.

s3://ai-models/cat-dog/v1/
├── model.onnx
├── labels.json
└── preprocessor_config.json

Kubernetes 환경에서는 PVC에 저장할 수도 있습니다.

/model-store/cat-dog/v1/
├── model.onnx
├── labels.json
└── preprocessor_config.json

중요한 점은 Serving 서버가 이 모델 파일 위치를 알아야 한다는 것입니다.

그래서 Serving 생성 시 보통 이런 값을 입력합니다.

storageUri: s3://ai-models/cat-dog/v1/

이 뜻은 다음과 같습니다.

이 경로에 있는 모델 파일을 가져와서 실행하세요.

흐름 ⑤ Serving 생성

이제 모델을 서비스로 띄웁니다.

Serving 생성 시 보통 다음 항목을 입력합니다.

Serving 이름
Namespace 또는 Project
모델 형식
Runtime
모델 저장 경로
CPU
Memory
GPU
Replica 수
Endpoint 설정

예를 들어 고양이/강아지 모델을 Serving한다고 하면 이런 느낌입니다.

Serving 이름: cat-dog
모델 형식: ONNX
모델 경로: s3://ai-models/cat-dog/v1/
CPU: 2 Core
Memory: 4Gi
GPU: 1개
Replica: 1

이 설정을 바탕으로 Kubernetes 안에서 모델 서버가 실행됩니다.

흐름 ⑥ 모델 서버 Pod 실행

Kubernetes에서는 컨테이너가 실행되는 기본 단위를 Pod라고 합니다.

Serving을 생성하면 모델을 실행하는 Pod가 만들어집니다.

cat-dog-predictor-pod
├── 모델 서버 컨테이너
├── 모델 파일
├── CPU
├── Memory
└── 필요 시 GPU

Pod가 시작되면 다음 과정을 거칩니다.

컨테이너 이미지 다운로드
      ↓
모델 파일 다운로드 또는 마운트
      ↓
Runtime 실행
      ↓
모델을 메모리에 로딩
      ↓
상태 점검
      ↓
Ready 상태 전환

여기서 중요한 상태가 Ready입니다.

Pod가 Running이라고 해서 무조건 요청을 받을 수 있는 것은 아닙니다.

Running = 컨테이너 프로세스가 실행 중
Ready = 모델까지 정상 로딩되어 요청 처리 가능

LLM처럼 큰 모델은 Running 상태가 된 뒤에도 모델 로딩에 시간이 오래 걸릴 수 있습니다.

이때는 아직 Ready가 아닙니다.

흐름 ⑦ Endpoint 생성

모델 서버가 준비되면 사용자가 호출할 수 있는 주소가 필요합니다.

이 주소를 보통 Endpoint라고 합니다.

예시는 다음과 같습니다.

https://cat-dog.example.com/predict

또는 KServe 형태에서는 이런 주소가 될 수 있습니다.

https://cat-dog.ai.example.com/v1/models/cat-dog:predict

사용자는 이 주소로 요청을 보냅니다.

사용자 이미지
  ↓
Endpoint 호출
  ↓
모델 서버
  ↓
결과 반환

흐름 ⑧ 사용자/API 요청

사용자는 API를 호출합니다.

예를 들어 curl 명령으로 호출하면 이런 형태입니다.

curl -X POST https://cat-dog.example.com/predict \
  -H "Content-Type: application/json" \
  -d @input.json

입력 데이터는 이미지일 수도 있고, 숫자 배열일 수도 있고, 텍스트일 수도 있습니다.

모델 종류에 따라 입력 형식이 달라집니다.

이미지 분류 모델 → 이미지 또는 이미지 배열
텍스트 분류 모델 → 문장
LLM → 프롬프트 또는 메시지
추천 모델 → 사용자 ID, 상품 ID
시계열 모델 → 시간별 수치 데이터

흐름 ⑨ 추론 결과 반환

모델 서버는 입력을 받아 계산한 뒤 결과를 반환합니다.

고양이/강아지 분류 모델이라면 결과가 이렇게 나올 수 있습니다.

{
  "label": "cat",
  "score": 0.973
}

또는 클래스별 확률을 모두 반환할 수도 있습니다.

{
  "predictions": [
    {
      "cat": 0.973,
      "dog": 0.027
    }
  ]
}

LLM이라면 결과가 문장으로 나옵니다.

{
  "answer": "GPU는 병렬 연산에 특화된 처리 장치입니다."
}

5. 모델 파일은 어디에 저장되는가?

모델 서빙에서 중요한 개념 중 하나가 모델 저장 위치입니다.

모델은 보통 다음 중 하나에 저장됩니다.

Object Storage

대표적인 예시는 다음과 같습니다.

AWS S3
NCP Object Storage
MinIO
기타 S3 호환 스토리지

경로는 보통 이런 식입니다.

s3://ai-models/cat-dog/v1/

Object Storage 방식의 장점은 다음과 같습니다.

모델 버전 관리가 쉽다
여러 Serving Pod가 같은 모델을 가져올 수 있다
Kubernetes 클러스터와 분리해서 관리할 수 있다
대용량 모델 저장에 적합하다

PVC

Kubernetes의 Persistent Volume Claim을 사용하는 방식입니다.

PVC: model-pvc
Mount Path: /models

모델 파일은 이런 식으로 저장됩니다.

/models/cat-dog/v1/
├── model.onnx
├── labels.json
└── preprocessor_config.json

PVC 방식은 Kubernetes 내부에서 모델을 바로 마운트해서 사용할 수 있다는 장점이 있습니다.

NAS, NFS, Lustre

온프레미스나 HPC 환경에서는 공유 파일시스템을 많이 사용합니다.

예를 들어 Lustre를 사용한다면 모델 경로가 이렇게 될 수 있습니다.

/lustre/models/cat-dog/v1/

대규모 학습 환경에서는 학습 결과를 Lustre 같은 고성능 파일시스템에 저장하고, Serving 환경에서 이를 읽어가는 구조도 가능합니다.

Hugging Face Hub

LLM이나 오픈소스 모델은 Hugging Face Hub에서 직접 가져오는 경우도 있습니다.

예시는 다음과 같습니다.

hf://meta-llama/Llama-3.1-8B-Instruct
hf://Qwen/Qwen2.5-7B-Instruct

이 방식은 모델을 별도로 직접 업로드하지 않아도 되는 장점이 있습니다.

하지만 운영 환경에서는 네트워크, 인증 토큰, 다운로드 시간, 보안 정책을 반드시 고려해야 합니다.

6. Serving 생성 시 내부에서 일어나는 일

Serving 생성 버튼을 누르면 겉으로는 간단해 보입니다.

하지만 내부에서는 여러 작업이 자동으로 진행됩니다.

Serving 생성 요청
      ↓
InferenceService 생성
      ↓
KServe Controller가 감지
      ↓
ServingRuntime 선택
      ↓
Pod 생성
      ↓
모델 파일 다운로드 또는 마운트
      ↓
모델 서버 실행
      ↓
Readiness Check
      ↓
Endpoint 활성화

조금 더 자세히 보면 다음과 같습니다.

내부 과정 ① InferenceService 생성

사용자가 Serving을 생성하면 Kubernetes 안에 InferenceService라는 리소스가 만들어질 수 있습니다.

InferenceService는 쉽게 말해 이런 내용을 담은 선언서입니다.

어떤 모델을
어디에서 가져와서
어떤 Runtime으로
얼마나 많은 자원을 주고
어떤 방식으로 서비스할 것인가

내부 과정 ② KServe Controller가 감지

KServe Controller는 Kubernetes 안에서 계속 리소스를 감시합니다.

사용자가 InferenceService를 만들면 KServe Controller가 이를 확인합니다.

새 InferenceService가 생겼네?
그러면 이 모델을 서비스할 Pod와 네트워크 구성을 만들어야겠다.

내부 과정 ③ ServingRuntime 선택

모델 형식에 맞는 Runtime이 필요합니다.

예를 들어:

ONNX 모델 → ONNX Runtime
TensorFlow 모델 → TensorFlow Serving
PyTorch 모델 → TorchServe 또는 Triton
sklearn 모델 → MLServer
LLM → vLLM 또는 Hugging Face Runtime

Runtime이 맞지 않으면 모델을 제대로 실행할 수 없습니다.

내부 과정 ④ Pod 생성

Kubernetes는 모델 서버를 실행할 Pod를 만듭니다.

Pod 안에서는 컨테이너가 실행됩니다.

Predictor Pod
└── Model Server Container

이 컨테이너가 실제 모델 요청을 처리합니다.

내부 과정 ⑤ 모델 파일 로딩

Pod가 시작되면 모델 파일을 가져옵니다.

Object Storage에서 다운로드
PVC에서 마운트
Hugging Face에서 다운로드
Container Image 내부에서 읽기

이후 Runtime이 모델을 메모리에 올립니다.

GPU 모델이라면 GPU 메모리에 올라갑니다.

모델 파일
  ↓
CPU Memory
  ↓
GPU Memory
  ↓
추론 준비 완료

내부 과정 ⑥ 상태 점검

모델 서버가 정상인지 확인합니다.

대표적인 점검은 다음과 같습니다.

Liveness Check
Readiness Check

차이는 다음과 같습니다.

점검의미

Liveness	컨테이너가 살아 있는가?
Readiness	실제 요청을 받을 준비가 되었는가?

중요한 것은 Readiness입니다.

모델이 아직 로딩 중이면 Pod는 살아 있어도 Ready가 아닐 수 있습니다.

내부 과정 ⑦ Endpoint 활성화

모델 서버가 Ready 상태가 되면 Endpoint가 활성화됩니다.

이제 외부에서 API를 호출할 수 있습니다.

사용자
  ↓
Endpoint
  ↓
Serving Pod
  ↓
모델 추론
  ↓
결과 반환

7. KServe는 어떤 역할을 하는가?

KServe는 Kubernetes 위에서 모델 Serving을 쉽게 하기 위한 오픈소스 플랫폼입니다.

초보자 입장에서는 이렇게 이해하면 됩니다.

Kubernetes = 컨테이너를 실행하는 기반
KServe = AI 모델 서버를 쉽게 만들고 운영하게 해주는 도구

Kubernetes만으로도 모델 서버를 직접 만들 수는 있습니다.

예를 들어 직접 Deployment, Service, Ingress를 만들 수 있습니다.

Deployment
Service
Ingress
HPA
ConfigMap
Secret
PVC

하지만 매번 직접 구성하려면 복잡합니다.

KServe는 이 과정을 모델 Serving에 맞게 정리해줍니다.

모델 경로 지정
Runtime 선택
Pod 생성
Service 생성
Route 구성
상태 점검
오토스케일링
Canary 배포
모델 버전 관리

즉, KServe는 외부 ALB처럼 단순히 트래픽만 전달하는 장비가 아닙니다.

KServe는 모델 서버를 만들고 운영하는 모델 서빙 관리자에 가깝습니다.

8. 사용자는 최종적으로 무엇을 호출하는가?

사용자는 최종적으로 Endpoint를 호출합니다.

예를 들어 이미지 분류 모델이라면:

https://cat-dog.example.com/predict

LLM이라면 OpenAI API와 비슷한 형태일 수 있습니다.

https://llm.example.com/v1/chat/completions

사용자는 이 주소로 요청을 보냅니다.

요청
  ↓
Endpoint
  ↓
Gateway 또는 Ingress
  ↓
KServe Route
  ↓
Kubernetes Service
  ↓
Serving Pod
  ↓
Runtime
  ↓
Model

응답은 다시 반대로 돌아옵니다.

Model
  ↓
Runtime
  ↓
Serving Pod
  ↓
Kubernetes Service
  ↓
Gateway 또는 Ingress
  ↓
Endpoint
  ↓
사용자

9. 초보자가 가장 많이 헷갈리는 부분

1. 모델 파일과 모델 서버는 다르다

모델 파일은 저장된 결과물입니다.

model.onnx
model.pt
model.safetensors

모델 서버는 이 파일을 읽어서 요청을 처리하는 실행 프로그램입니다.

ONNX Runtime
TensorFlow Serving
TorchServe
vLLM
Triton
MLServer

즉:

모델 파일 = 두뇌에 저장된 지식
모델 서버 = 그 지식을 사용해서 답하는 실행 환경

2. 학습과 서빙은 다르다

학습은 모델을 만드는 과정입니다.

서빙은 만들어진 모델을 사용하는 과정입니다.

학습은 무겁고 오래 걸릴 수 있음
서빙은 빠르게 응답하는 것이 중요함

학습에서는 대량 데이터와 긴 시간이 중요합니다.

서빙에서는 응답 속도, 안정성, 확장성이 중요합니다.

3. Running과 Ready는 다르다

Pod가 Running이라고 해서 사용 가능한 것은 아닙니다.

Running = 컨테이너가 실행 중
Ready = 모델이 로딩되어 요청 처리 가능

예를 들어 LLM 모델은 Pod가 Running 상태가 된 뒤에도 모델 로딩에 몇 분 이상 걸릴 수 있습니다.

이때는 아직 Ready가 아닙니다.

4. KServe는 ALB가 아니다

ALB는 외부 트래픽을 내부로 들여보내는 역할입니다.

KServe는 모델 서버를 생성하고 관리하는 역할입니다.

ALB = 외부 입구
KServe = 모델 서비스 관리자
Serving Pod = 실제 모델 실행 공간

전체 구조는 다음과 같습니다.

사용자
  ↓
ALB
  ↓
Ingress 또는 Gateway
  ↓
KServe가 만든 Route
  ↓
Service
  ↓
Serving Pod
  ↓
Model Runtime
  ↓
Model

5. GPU가 있다고 무조건 서빙이 되는 것은 아니다

GPU가 있어도 다음 조건이 맞아야 합니다.

모델이 GPU 메모리에 올라갈 수 있는가?
CUDA 버전이 맞는가?
Runtime이 GPU를 지원하는가?
Pod가 GPU를 정상 할당받았는가?
Node Selector나 Toleration이 맞는가?

GPU Serving에서 자주 발생하는 문제는 다음과 같습니다.

Insufficient nvidia.com/gpu
CUDA out of memory
Driver mismatch
Runtime error
ModelLoadFailed

10. 0단계 핵심 요약

AI 모델 서빙은 다음 한 문장으로 정리할 수 있습니다.

학습된 모델을 API로 호출할 수 있도록 서버 형태로 운영하는 과정

전체 흐름은 다음과 같습니다.

데이터 준비
  ↓
모델 학습
  ↓
모델 파일 생성
  ↓
스토리지 저장
  ↓
Serving 생성
  ↓
Pod 실행
  ↓
모델 로딩
  ↓
Endpoint 생성
  ↓
API 호출
  ↓
추론 결과 반환

초보자가 반드시 기억해야 할 개념은 다음입니다.

Model
= 학습 결과 파일들의 집합

Inference
= 모델이 입력을 받아 결과를 계산하는 것

Serving
= Inference를 API 서비스로 제공하는 것

Runtime
= 모델 파일을 실제로 실행하는 프로그램

KServe
= Kubernetes 위에서 모델 Serving을 쉽게 만들고 운영하는 플랫폼

InferenceService
= KServe에서 모델 Serving을 정의하는 Kubernetes 리소스

Endpoint
= 사용자가 호출하는 API 주소

마지막으로 가장 중요한 구조는 이것입니다.

[모델 파일]
   ↓
[스토리지]
   ↓
[Serving 생성]
   ↓
[모델 서버 Pod]
   ↓
[Endpoint]
   ↓
[사용자 요청]
   ↓
[추론 결과]

0단계에서는 이 전체 그림만 이해하면 충분합니다.

앞으로는 아래 순서로 하나씩 깊게 들어가면 됩니다.

1단계: Serving이란?
2단계: 모델 파일과 storageUri 이해
3단계: Inference 개념 이해
4단계: KServe 개념 이해
5단계: InferenceService YAML 이해

서빙을 어렵게 느끼는 이유는 기술이 어려워서라기보다, 여러 계층이 한 번에 등장하기 때문입니다.

AI 모델 계층
Kubernetes 계층
스토리지 계층
네트워크 계층
GPU 자원 계층
운영 모니터링 계층

이 계층들을 하나씩 분리해서 보면 Serving은 훨씬 쉽게 이해할 수 있습니다.

정리하면, 학습시리즈 표의 “단계”는 유지하고, 본문 내부 절차는 앞으로 계속 **“흐름 ① / 내부 과정 ① / 구성요소 ①”**로 쓰는 방식이 가장 깔끔합니다.

저작자표시 비영리 변경금지 (새창열림)

'[GPUaaS] > Serving' 카테고리의 다른 글

[4단계] KServe가 뭐야? TensorFlow, PyTorch, ONNX, scikit-learn, XGBoost 모델 서빙 쉽게 이해하기 🚀 (0)	2026.07.28
[3단계] Kubeflow가 뭐야? AI 학습부터 서빙까지 연결하는 초보자용 설명 🚀 (1)	2026.07.23
[2단계] AI 서빙 (Serving) 생성 화면, 초보자도 쉽게 이해하기 😊 !! (0)	2026.07.22
[1단계] AI 모델 서빙이란? 초보자를 위한 1단계 쉬운 설명 🍽️ (1)	2026.07.17

[NEW] AI 모델 서빙 학습 시리즈 0단계