GenAI on K8s/EKS 인퍼런스 최적화

DevOps

GenAI on K8s/EKS 인퍼런스 최적화

frontheadlock 2026. 8. 2. 01:40

최근 OSSAI 활동을 통해, GenAI On EKS에 대해 교육받을 수 있는 기회가 생겼습니다.

교육 기간 중 Amazon EKS 기반의 Agentic AI 플랫폼 설계 및 배포와 관련하여,
AWS로부터 핸즈온 가능한 플랫폼을 제공받아 직접 작업해볼 수 있었습니다.

이번 핸즈온의 목표는,
LLM 배포부터 지능형 어플리케이션 구축까지 AI 플랫폼을 구축하는 것이었습니다.

핸즈온 환경

Agentic AI 플랫폼: EKS Auto Mode
LLM: AQwen 3 8B와 DeepSeek R1 Qwen 3 8B(Neuron Chip), Amazon Bedrock (Claude)
최신 AI 패턴: 관측성, 비용 추적, 확장성
프레임워크: LangChain, LangGraph, Model Context Protocol(MCP)

워크샵 구성

워크샵은 총 5개의 모듈로 구성되어 있습니다.

1. 모델과 상호작용

다양한 배포 패턴을 통해 LLM과 상호작용하며 시작합니다.

Open WebUI: 모델 상호작용을 위한 ChatGPT 유사 인터페이스 배포
vLLM on AWS Neuron: Neuron 위에서 Qwen 3 8B와 DeepSeek R1 Qwen 3 8B 호스팅
AWS Bedrock: Bedrock을 통해 Claude 4.5 Sonnet 연결

2. Agentic AI 플랫폼 컴포넌트

개별 컴포넌트를 통합 플랫폼으로 전환합니다.

LiteLLM Gateway: 모든 모델을 위한 통합 API 생성
Langfuse Observability: 모든 토큰, 비용, 상호작용 추적
Platform Integration: 컴포넌트들을 원활하게 연결

3. Agentic AI 애플리케이션 구축

최신 프레임워크를 사용해 챗봇을 넘어선 지능형 에이전트를 만듭니다.

LangChain & LangGraph: 체인, 에이전트, 워크플로우 구축
Model Context Protocol: MCP 서버로 외부 도구 및 API 통합
Loan Buddy Agent: LangGraph 기반의 대출 처리 애플리케이션 구축
Secure and Observe: 에이전트 플로우를 플랫폼 컴포넌트와 통합

4. 플랫폼 확장 및 평가

플랫폼이 대규모에서도 품질을 유지하도록 만듭니다.

LLM-as-a-Judge: Langfuse로 에이전트 출력 품질 자동 평가
A/B Model Routing: LiteLLM의 가중치 기반 트래픽 분할로 모델 비교
AMP/AMG Monitoring: Prometheus / Grafana로 대시보드 구축
Auto-Scaling: HPA와 Karpenter를 통한 탄력적 추론 용량 확보

5. 프로덕션 준비

엔터프라이즈 요구사항에 맞춰 에이전트를 프로덕션 수준으로 끌어올립니다.

RAG with Milvus: 정책 인식 결정을 위한 벡터 데이터베이스
Ragas Evaluation: RAG 품질 측정 (충실도, 관련성, 정확도)
Security Hardening: Pod Identity, External Secrets, Bedrock Guardrails
Streaming Responses: 더 나은 UX를 위한 실시간 SSE 출력

이번 글에서는 워크샵 환경 구성과 모듈 1(모델과 상호작용)까지를 정리하고,
이후 모듈은 다음 글에서 이어서 다뤄보겠습니다.

아키텍처

워크샵에서 구축하는 플랫폼의 전체 아키텍처는 다음과 같습니다.

사용자는 Open WebUI로 대화하고,
모든 요청은 LiteLLM 게이트웨이를 거쳐 vLLM 또는 Bedrock으로 라우팅됩니다.
그리고 이 과정 전체가 Langfuse로 추적됩니다.

어떤 모델을 쓰든 요청이 반드시 게이트웨이 한 곳을 지나가도록 만든 구조 덕분에,
비용 추적과 관측성, 모델 교체가 전부 이 지점에서 해결됩니다.

Agentic AI에 EKS가 유용한 이유

Scalability
- AI 워크로드 수요에 따른 오토스케일링
- 특수 하드웨어 지원 (GPU, Neuron)
- 분산 추론 및 다중 모델 배포 패턴
Flexibility
- 자체 호스팅 오픈소스 모델과 관리형 클라우드 서비스 통합
- 하이브리드 배포 패턴, 커스텀 최적화 전략
Operations
- Langfuse를 통한 포괄적인 관측성
- Helm을 통한 자동화된 라이프사이클 관리
- 비용 최적화 및 추적, 보안 모범 사례

워크샵 환경

시작하기

AWS에서 핸즈온용 플랫폼을 제공해주어, 비용 부담 없이 개발 가능한 환경을 제공받았습니다.🥹👍

Workshop Studio에 액세스하면 위와 같이,
브라우저에서 바로 열리는 Visual Studio Code 기반의 IDE가 주어집니다.

workshop 폴더에는 components, terraform 등 실습에 사용할 코드가 미리 담겨 있고,
하단 터미널은 participant 계정으로 EKS 클러스터와 AWS CLI에 바로 연결되어 있습니다.

사전에 구성된 EKS 클러스터와 임시 자격 증명이 포함되어 있기에,
별도 설정 없이 바로 kubectl을 사용할 수 있었습니다.

워크샵의 주제는 어디까지나 Agentic AI인 만큼,
애플리케이션을 구축하고 배포하기 이전의 기반 인프라는 모두 사전 구성되어 제공되었습니다.

EKS Auto Mode

워크샵 환경에는 완전히 작동하는 Amazon EKS 클러스터가 포함되어 있고,
이 클러스터는 EKS Auto Mode로 구성되어 있습니다.

EKS Auto Mode는 컴퓨팅, 스토리지, 네트워킹 리소스 관리의 운영 오버헤드를 제거하는
완전 관리형 Kubernetes 경험을 제공합니다.

자동 컴퓨팅 프로비저닝: EC2 인스턴스를 수동으로 생성하거나 관리할 필요 없음
동적 확장: 워크로드 수요에 따라 용량을 자동으로 조정
패치 관리: OS 및 Kubernetes 컴포넌트 자동 업데이트
비용 최적화: 지능형 인스턴스 선택 및 Spot 인스턴스 통합

터미널에서 클러스터를 조회해보면 다음과 같습니다.

조회된 노드가 모두 Ready 상태인데, COMPUTE-TYPE 레이블이 전부 auto입니다.
제가 직접 만든 노드가 하나도 없이,

Auto Mode로 워크로드에 맞춰 알아서 프로비저닝되었습니다.

클러스터 노드 구성

노드풀과 스토리지를 조회해보면 클러스터의 구성이 한눈에 들어옵니다.

여기서 재미있는 부분이 노드풀별 노드 수입니다.

일반적으로 AI는 gpu 환경 위에서 동작을 하는데,

neuron 노드풀에만 노드 2개가 떠있고, gpu 노드풀은 0개입니다.

노드풀 정의는 되어 있지만, GPU 워크로드가 없는 동안에는 비싼 노드를 하나도 유지하지 않습니다.

StorageClass로는 ebs(기본)와 efs가 준비되어 있고,

huggingface-cache, neuron-cache라는 100Gi EFS 볼륨 2개가 바인딩되어 있습니다.

이 두 캐시는 뒤의 vLLM 섹션에서 다시 등장합니다.

클러스터는 워크로드 성격에 따라 세 종류의 노드로 나뉘어 있습니다

General Purpose Nodes (Multi-Architecture)

Instance Types: 최신 세대 컴퓨팅(C), 메모리(M), 범용(R) 최적화 인스턴스
- AWS Graviton (ARM64): 비슷한 x86 대비 최대 40% 향상된 가격 대비 성능
- x86 (AMD/Intel): 기존 x86 아키텍처 인스턴스
Architecture Support: 워크로드 호환성에 따라 자동 선택되는 멀티 아키텍처 (amd64/arm64)
Purpose: 일반 워크로드, 웹 서비스, 컨트롤 플레인 컴포넌트 실행
Scaling: Karpenter가 Pod 요구사항에 따라 비용이 효율적인 인스턴스를 자동 선택, 낮은 노드는 통합

GPU-Accelerated Nodes

Instance Types: NVIDIA GPU (g5, g6, p4, p5 패밀리)
Purpose: GPU 집약적 AI/ML 워크로드 실행
Features: CUDA 지원, GPU 오퍼레이터 사전 설치

AWS Neuron Nodes

Instance Types: inf2, trn1, trn2 인스턴스
Purpose: 대규모 언어 모델을 위한 최적화된 추론
Benefits:
- GPU 대비 추론당 최대 50% 낮은 비용
- 최적 성능을 위한 사전 컴파일 모델
- 네이티브 int8 양자화 지원

스토리지 구성

클러스터는 영구 스토리지로 Amazon EFS(Elastic File System)를 사용합니다.

Shared Storage: 여러 Pod가 동시에 읽기/쓰기 가능
Elastic Throughput Mode: 워크로드에 따라 성능을 자동으로 확장
Model Caching: 빠른 배포를 위해 사전 다운로드된 모델을 EFS에 저장
Cross-AZ Availability: 여러 가용 영역에 걸친 고가용성

사전 설치된 Agentic AI 스택

Agentic AI 애플리케이션을 바로 구축할 수 있도록, 주요 컴포넌트들이 미리 배포되어 있습니다.

서비스를 조회해보면 스택 전체가 실제로 떠 있는 것을 확인할 수 있습니다.

각 컴포넌트의 역할은 다음과 같습니다.

Open WebUI

대규모 언어 모델과 상호작용하기 위한 웹 인터페이스입니다.

Features: 채팅 인터페이스, 대화 기록, 모델 전환
Integration: LiteLLM 게이트웨이와 연동되도록 사전 구성

LiteLLM

여러 LLM 제공자에 대한 단일 인터페이스를 제공하는 통합 API 게이트웨이입니다.

Purpose: 서로 다른 모델 제공자 간 API 호출 표준화
Supported Models: vLLM, AWS Bedrock, OpenAI 호환 엔드포인트
Load Balancing: 사용 가능한 모델 전반에 요청을 자동 분산

Langfuse

LLM 애플리케이션을 위한 포괄적인 관측성 플랫폼입니다.

Monitoring: 토큰 사용량, 지연시간, 비용 추적
Debugging: 전체 스택을 관통하는 개별 요청 추적
Analytics: 모델 성능 및 사용자 상호작용 분석

vLLM

대규모 언어 모델을 위한 고성능 추론 엔진입니다.

Pre-loaded Models: Qwen 3 8B, DeepSeek R1 Qwen 3 8B (Neuron)
Optimization: Continuous Batching, PagedAttention, Tensor Parallelism
Hardware Acceleration: AWS Neuron 칩에 최적화

모듈 1. 모델과 상호작용

모듈 1에서 다루는 구성요소들은 다음과 같이 연결됩니다.
Open WebUI가 LiteLLM 통합 API를 바라보고, LiteLLM이 세 개의 모델에 요청을 나눠줍니다.

Open WebUI

Open WebUI는 원래 Ollama WebUI라는 이름으로 시작한 오픈소스 프로젝트로,
다음과 같은 기능을 제공합니다.

최신 채팅 인터페이스: ChatGPT와 유사한 깔끔하고 반응형 디자인
다중 모델 지원: 여러 모델 간 원활한 전환
대화 관리: 채팅 기록 저장, 정리 및 검색
파일 업로드: 문서 및 이미지 지원 (모델이 지원하는 경우)
프롬프트 템플릿: 자주 쓰는 작업을 위한 사전 구성 프롬프트
다중 사용자 지원: 개인화된 설정을 가진 개별 계정

워크샵에서 사용된 Helm values는 다음과 같습니다.

# Open WebUI Helm values
nameOverride: openwebui

# ALB Ingress 구성
ingress:
  enabled: true
  annotations:
    alb.ingress.kubernetes.io/target-type: ip
    {{#if DOMAIN}}
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
    {{/if}}
  host: openwebui.{{{DOMAIN}}}

# LiteLLM API 게이트웨이 연결 (클러스터 내부 주소 사용)
openaiBaseApiUrl: http://litellm.litellm:4000/v1

extraEnvVars:
  - name: OPENAI_API_KEY
    value: {{{LITELLM_API_KEY}}}
  - name: WEBUI_ADMIN_EMAIL
    value: {{{OPENWEBUI_ADMIN_EMAIL}}}
  - name: WEBUI_ADMIN_PASSWORD
    value: {{{OPENWEBUI_ADMIN_PASSWORD}}}

# 로컬 Ollama 비활성화 (외부 모델 사용)
ollama:
  enabled: false
pipelines:
  enabled: false

# 대화를 위한 영구 스토리지
persistence:
  enabled: true
  size: 100Gi

# 리소스 할당
resources:
  requests:
    cpu: 1
    memory: 2Gi
  limits:
    memory: 2Gi

1. LiteLLM 통합

Open WebUI는 모델 엔드포인트에 직접 연결하는 대신 LiteLLM에 연결합니다.

통합 API: 모든 모델에 대한 단일 엔드포인트
로드 밸런싱: 모델 레플리카 간 자동 분산
Fallback 지원: 모델 간 원활한 전환

LiteLLM은 AI 게이트웨이 역할을 하며,
모든 모델에 대해 통합된 OpenAI 호환 인터페이스를 제공합니다.
LiteLLM 자체는 모듈 2에서 자세히 다루겠습니다.

2. AWS Load Balancer 통합

Ingress 구성은 Application Load Balancer(ALB)를 생성합니다.

HTTPS Termination: SSL/TLS를 로드 밸런서에서 처리
Target Type IP: 더 나은 성능을 위한 직접 Pod 네트워킹
커스텀 도메인: https://openwebui.${DOMAIN}으로 접근 가능

3. 영구 스토리지

100Gi의 EBS 스토리지가 다음을 보장합니다.

대화 기록: 모든 채팅이 보존됨
사용자 설정: 세션 간 설정 유지
안정적인 성능: 애플리케이션의 일관된 I/O 성능

EKS Auto Mode는 StorageClass만 정의하면 PVC에 대한 EBS 자동 프로비저닝
수동 CSI 드라이버 설치와 노드 구성이 필요 없다는 점이 편리했습니다.

배포와 접속

인프라 설정 중에 실행된 배포 프로세스는 다음과 같습니다.

# Helm 레포지토리 추가
helm repo add open-webui https://open-webui.github.io/helm-charts
helm repo update

# 커스텀 구성으로 Open WebUI 설치
helm upgrade --install openwebui open-webui/open-webui \
  --namespace openwebui \
  --create-namespace \
  -f values.rendered.yaml

# Open WebUI URL 확인
echo "Open WebUI URL: http://$(kubectl get ingress -n openwebui openwebui -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')"

# 생성된 관리자 계정 조회 후 로그인
helm get values openwebui -n openwebui

발급된 ALB 주소로 접속해 로그인하면, 모델 선택 드롭다운이 표시됩니다.

드롭다운에는 qwen3-8b, deepseek-r1, 그리고 bedrock이 나타납니다.

EKS에서 직접 서빙 중인 모델과 Bedrock의 관리형 모델이
하나의 UI에서 완전히 같은 방식으로 노출되는 것인데, 이것이 LiteLLM 게이트웨이의 효과입니다.

다만 bedrock/claude-4.5-sonnet은 EKS에서 호스팅되는 것이 아니라,
LiteLLM을 거쳐 Bedrock API로 라우팅됩니다.

Open WebUI는 Agentic AI 스택에서 다음과 같이 통합되어 사용됩니다.

vLLM 모델이면 클러스터 내부 Pod로, Bedrock 모델이면 AWS API로 분기하지만,
사용자 입장에서는 어떤 백엔드든 동일한 요청과 응답 형태를 갖습니다.

vLLM: 자체 호스팅 모델 서빙

그렇다면 이러한 GenAI 모델들은 Kubernetes에서 실제로 어떻게 실행되고 있을까요?

실행 중인 모델은 다음과 같이 탐색할 수 있습니다.

# 현재 실행 중인 vLLM 모델 확인
kubectl get pods -n vllm

# 채팅 경험 뒤의 실제 Deployment 확인
kubectl get deployments -n vllm -o wide

# 모델을 호스팅하는 노드 확인
kubectl get pods -n vllm -o wide

# vLLM 구성 디렉터리 확인
ls /workshop/components/llm-model/vllm/

# 방금 사용한 Qwen 3 배포 살펴보기
cat /workshop/components/llm-model/vllm/model-qwen3-8b-neuron.rendered.yaml

# DeepSeek 배포와 비교
cat /workshop/components/llm-model/vllm/model-deepseek-r1-qwen3-8b-neuron.rendered.yaml

실제로 조회해보면 다음과 같습니다.

방금까지 채팅하던 두 모델이 각각 1/1 Running 상태의 Pod로 돌아가고 있습니다.

채팅 한 번의 요청 흐름은 다음과 같습니다.

메시지 입력 → Open WebUI → LiteLLM → vLLM Pod
Pod가 AWS Neuron 하드웨어에서 요청 처리
응답이 동일한 경로를 역으로 거쳐 브라우저에 도착

vLLM이란?

LLM을 고속으로 추론하기 위한 효율적 엔진으로, 서빙 환경에서 높은 처리량과 낮은 지연 시간이 목표
출처: SKT Enterprise

vLLM은 다음과 같은 기능을 제공합니다.

높은 처리량: 여러 요청을 효율적으로 서빙하도록 최적화
Continuous Batching: 최적의 하드웨어 활용을 위한 동적 요청 배칭
PagedAttention: 긴 컨텍스트를 위한 효율적인 메모리 관리
Tensor Parallelism: 여러 가속기에 모델 분산
OpenAI 호환 API: OpenAI API의 드롭인 대체

그럼 이러한 모델은 요청을 받았을 때 실제로 어떻게 동작할까요?

마침 치킨을 시켰던 터라, 치킨을 주제로 모델의 동작 과정을 살펴보았습니다.

Open WebUI에서 DeepSeek 모델에게
"교촌 치킨이랑 처갓집 양념치킨 중에 어떤 게 더 맛있어? 근거를 수치 기반으로 제공해줘."라고 물어봤습니다.
~~(선택장애..)~~

그러고는 가격 대비 맛 만족도부터 성분 라벨 비교까지, 수치를 들어가며 제법 진지하게 비교해줍니다.
~~(둘 다 처음 보는 메뉴인데?)~~

이 질문에 답하는 동안 vLLM Pod의 로그를 실시간으로 지켜보면 다음과 같습니다.

participant:/workshop$ kubectl logs -f --tail=0 -n vllm deployment/deepseek-r1-qwen3-8b-neuron
(APIServer pid=1) INFO:     10.0.45.96:60236 - "POST /v1/chat/completions HTTP/1.1" 200 OK
INFO 08-01 13:16:36 [metrics.py:398] Avg prompt throughput: 4.2 tokens/s, Avg generation throughput: 0.1 tokens/s, Running: 1 reqs, GPU KV cache usage: 0.0%, CPU KV cache usage: 33.3%.
INFO 08-01 13:16:41 [metrics.py:398] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 17.8 tokens/s, Running: 1 reqs, GPU KV cache usage: 0.0%, CPU KV cache usage: 33.3%.
INFO 08-01 13:16:46 [metrics.py:398] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 18.2 tokens/s, Running: 1 reqs, GPU KV cache usage: 0.0%, CPU KV cache usage: 33.3%.
...(약 2분간 18 tokens/s 내외로 토큰 생성)...
INFO 08-01 13:18:22 [metrics.py:398] Avg prompt throughput: 301.5 tokens/s, Avg generation throughput: 11.9 tokens/s, Running: 1 reqs, GPU KV cache usage: 0.0%, CPU KV cache usage: 33.3%.
(APIServer pid=1) INFO:     10.0.45.96:60236 - "POST /v1/chat/completions HTTP/1.1" 200 OK
INFO 08-01 13:18:57 [metrics.py:398] Avg prompt throughput: 343.0 tokens/s, Avg generation throughput: 11.6 tokens/s, Running: 1 reqs, GPU KV cache usage: 0.0%, CPU KV cache usage: 33.3%.
INFO 08-01 13:19:02 [metrics.py:398] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 18.2 tokens/s, Running: 1 reqs, GPU KV cache usage: 0.0%, CPU KV cache usage: 33.3%.

....

이 로그에서 볼 수 있는 것은 다음과 같습니다.

요청 수신: POST /v1/chat/completions로 프롬프트가 도착
모델 처리 중: 토큰 생성 및 처리 지표가 5초 단위로 갱신
성능 통계: 처리량, 실행 중인 요청 수, KV 캐시 사용률

주목할 주요 지표는 다음과 같습니다.

Prompt throughput
- 평소에는 0, 요청이 들어와 프롬프트를 읽는 순간 300 tokens/s 이상으로 튀어 오릅니다.
Generation throughput
- 응답을 생성하는 동안 약 18 tokens/s로 일정하게 유지됩니다.
KV cache usage
- GPU KV cache가 0인 이유는, GPU가 아닌 Neuron 위에서 실행되고 있기 때문입니다.

AWS Neuron 배포 구성

AWS Neuron은 AWS Inferentia(inf2) 및 Trainium(trn1) 칩을 위한 SDK입니다.

비용 효율성: GPU 대비 추론당 최대 50% 낮은 비용
LLM 최적화: 트랜스포머 아키텍처에 대한 기본 지원
Quantization: 메모리 사용을 줄이기 위한 INT8 및 FP8 지원
컴파일: 최적의 성능을 위한 사전 컴파일 모델

vLLM 배포는 네임스페이스, 스토리지, 시크릿, Deployment, Service로 구성됩니다.

# Namespace 격리
apiVersion: v1
kind: Namespace
metadata:
  name: vllm

스토리지: 두 개의 캐시

Amazon EFS를 사용해 다운로드한 모델과 컴파일된 Neuron 그래프를 캐시합니다.

# pvc-huggingface-cache.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: huggingface-cache
  namespace: vllm
spec:
  storageClassName: efs
  accessModes:
    - ReadWriteMany  # 여러 Pod가 읽기/쓰기 가능
  resources:
    requests:
      storage: 100Gi
---
# pvc-neuron-cache.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: neuron-cache
  namespace: vllm
spec:
  storageClassName: efs
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 100Gi

앞서 클러스터 구성에서 kubectl get pv로 확인했던 100Gi EFS 볼륨 2개가 바로 이 캐시들입니다.

캐시를 두 개로 나눠 사용하는 이유는 다음과 같습니다.

HuggingFace 캐시: 다운로드한 모델 가중치 저장
Neuron 캐시: 컴파일된 모델 그래프 저장
재사용성: 캐시된 데이터는 Pod 재시작 후에도 유지되어, 재배포가 훨씬 빨라짐

시크릿: HuggingFace 토큰

# secret.template.yaml
apiVersion: v1
kind: Secret
metadata:
  name: hf-token
  namespace: vllm
type: Opaque
stringData:
  token: ${HF_TOKEN}  # 배포 중 주입됨

Deployment: Neuron 최적화 Qwen 3 8B

# model-qwen3-8b-neuron.rendered.yaml (주요 섹션)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: qwen3-8b-neuron
  namespace: vllm
spec:
  replicas: 1
  selector:
    matchLabels:
      app: qwen3-8b-neuron
  template:
    spec:
      # Neuron 하드웨어를 위한 노드 선택
      nodeSelector:
        eks.amazonaws.com/instance-family: inf2
        node.kubernetes.io/instance-type: inf2.xlarge
      containers:
        - name: vllm
          image: public.ecr.aws/agentic-ai-platforms-on-k8s/vllm-neuron:qwen3-8b
          command: ["vllm", "serve"]
          args:
            - --served-model-name=qwen3-8b-neuron
            - --trust-remote-code
            - --gpu-memory-utilization=0.90
            - --enable-auto-tool-choice
            - --tool-call-parser=hermes
            - --reasoning-parser=qwen3
            - --tensor-parallel-size=2
            - --max-num-seqs=1
            - --max-model-len=16384
          resources:
            requests:
              cpu: 3
              memory: 12Gi
              aws.amazon.com/neuroncore: 2  # 2개의 Neuron 코어 요청
            limits:
              aws.amazon.com/neuroncore: 2

주요 구성 세부 사항은 다음과 같습니다.

노드 선택: Pod가 Neuron이 장착된 inf2 인스턴스에서만 실행되도록 보장
Neuron 코어: neuroncore 리소스는 요청(requests)과 제한(limits)이 반드시 일치해야 함
Tensor Parallelism: 더 빠른 추론을 위해 2개의 Neuron 코어에 모델 분할
컨텍스트와 동시성: 16K 컨텍스트 윈도우로, 한 번에 하나의 시퀀스만 처리

Service

Service는 vLLM Deployment를 노출해, LiteLLM 같은 다른 컴포넌트가 접근할 수 있도록 합니다.

apiVersion: v1
kind: Service
metadata:
  name: qwen3-8b-neuron
  namespace: vllm
spec:
  selector:
    app: qwen3-8b-neuron
  ports:
    - name: http
      port: 8000

Selector: app: qwen3-8b-neuron 레이블이 있는 Pod와 매칭
포트 8000: OpenAI 호환 엔드포인트를 위한 표준 vLLM API 포트
ClusterIP: 클러스터 내부에서만 접근 가능한 내부 서비스

이 외에도 LiteLLM을 통해 Bedrock 모델을 같은 인터페이스로 호출할 수 있습니다.

Open WebUI에서의 RAG

Open WebUI에는 또한 기본 RAG(Retrieval Augmented Generation) 기능이 내장되어 있습니다.

RAG가 문서의 특정 컨텍스트를 제공해 AI의 응답을 어떻게 변화시키는지 확인해보겠습니다.

먼저 IDE 터미널에서, 모델이 알기 힘든 내용의 테스트 파일을 만듭니다.

cat > super-secret.txt << 'EOF'
Super Secret Document

This document contains classified information about the secret project.
Only authorized personnel are allowed to access this data.

Project Codename: Nightfall
Objective: Develop an untraceable communication device.
Status: In progress

Remember, this information is top secret and must not be shared with anyone.
EOF

이 파일을 IDE 파일 탐색기에서 로컬 머신으로 다운로드한 뒤, Open WebUI에 업로드합니다.

다음으로 Open WebUI에서 Knowledge Base를 생성합니다.

Workspace > Knowledge로 이동해 새 Knowledge Base 생성

양식 작성
- Name: super-secret-info
- Description: Store secret info in knowledge base
- Visibility: Private
Create Knowledge 클릭 후, + > Upload files로 super-secret.txt 업로드

이제 bedrock/claude-4.5-sonnet에게 같은 질문을 RAG 유무에 따라 비교해봅니다.

질문은 "What is the objective of project nightfall?"입니다.

RAG 없이 질문

RAG 없이 질문하면, 모델은 "Project Nightfall에 대한 구체적인 정보가 없다"며
소설이나 게임, 군사 프로젝트 등의 가능성만 나열하고 오히려 맥락을 되묻습니다.

학습한 적 없는 내용이니 당연한 결과입니다.

2. Knowledge Base 연결 후 질문

Knowledge Base를 연결한 뒤에는 Retrieved 1 source 표시와 함께,
super-secret.txt를 출처로 인용하며 "추적 불가능한 통신 장치 개발"이라고 정확히 답합니다.

같은 모델이라도 어떤 컨텍스트를 쥐여주느냐에 따라,
답변의 질이 완전히 달라진다는 것을 직접 확인할 수 있었습니다.

마무리

이번 글에서는 EKS Auto Mode 기반의 워크샵 환경 구성과,
모듈 1에서 다룬 모델과의 상호작용까지 정리해보았습니다.

다음 글에서는 모듈 2를 이어서,
LiteLLM 게이트웨이와 Langfuse 관측성을 중심으로
개별 컴포넌트들이 어떻게 하나의 플랫폼으로 통합되는지 정리해보겠습니다.

관련하여 더 자세한 내용이 궁금하시다면,

https://github.com/aws-samples/sample-genai-on-eks-starter-kit

GitHub - aws-samples/sample-genai-on-eks-starter-kit: A comprehensive toolkit for deploying production-ready Generative AI infra

A comprehensive toolkit for deploying production-ready Generative AI infrastructure on Amazon EKS. Includes pre-configured components for: 🚀 AI Gateway (LiteLLM) 🤖 LLM Serving (vLLM, SGLang, Ollam...

github.com