26O14a

QK·3일 전

NVIDIA B300 × 8 기반 멀티모델 vLLM 서빙 구성

현재 Kubernetes GPU 클러스터에서 B300 8장으로 5개 LLM과 Docling을 동시에 서비스하려면, 단순히 GPU를 모델별로 균등 배분하기보다 모델 크기, MoE 구조, KV Cache, 예상 동시 요청량을 기준으로 배치해야 합니다.

특히 다음 두 가지를 구분해야 합니다.

모델 적재 가능 여부: 모델 가중치와 KV Cache가 GPU HBM에 들어가는가?
서비스 가능 여부: 모델이 적재된 상태에서 원하는 context length, 동시성, 응답속도를 만족하는가?

B300 8장이라면 총 HBM 용량은 상당하지만, GPU별 메모리가 자동으로 하나의 공유 메모리처럼 동작하지는 않습니다. 따라서 각 모델의 TP(Tensor Parallelism), DP(Data Parallelism), GPU 공유 방식을 함께 설계해야 합니다.

또한 Docling은 문서 변환 프레임워크이지 단일 vLLM 모델이 아닙니다. OCR, 레이아웃 분석, 테이블 인식 등은 별도 GPU 워커로 운영하고, 필요할 때 LLM 추론 API와 연동하는 구조가 적절합니다.

1. 먼저 모델 크기를 보면 배분 전략이 달라집니다

B300은 GPU당 288GB, 8장 기준 총 2,304GB HBM을 제공합니다.

image

NVIDIA Docs

모델	확인된 규모	배치 시 고려사항
GLM-5.3	753B급 MoE	다중 GPU 필수
Qwen3.6-35B-A3B	35B / 활성 3B	단일 GPU 적재 가능
gpt-oss-20b	20B급	단일 GPU 적재 가능
DeepSeek-V4.1-Flash	552B / 활성 8B 입력, 16B 출력	다중 GPU 권장
GLM-5.3-Flash	별도 MoE 모델	정확한 메모리 요구량 확인 필요
Docling	문서 처리 파이프라인	CPU 또는 GPU 워커

GLM-5.3과 DeepSeek-V4.1-Flash는 소형 모델이 아닙니다. 특히 MoE 모델은 활성 파라미터가 적더라도 일반적으로 전체 전문가 가중치를 메모리에 유지해야 합니다.

image

Hugging Face

따라서 5개 LLM을 모두 BF16으로 상주시킨다는 전제는 피해야 합니다. FP8/FP4 등 실제 지원되는 가중치 형식과 동시 상주할 모델 수를 먼저 정해야 합니다.

2. 권장 GPU 배분안

가장 먼저 검토할 구성은 대형 모델 1개를 주력으로 운영하고, 나머지 모델을 상주 또는 교체 운영하는 방식입니다.

B300 8-GPU 배치 시뮬레이션

GPU당 288GB HBM · 모델 적재 검증 전 계획안

A · 대형 모델 우선

B · Flash 모델 우선

C · 소형 모델/Docling 우선

GPU 0

GPU 1

GPU 2

GPU 3

GPU 4

GPU 5

GPU 6

GPU 7

DeepSeek V4.1 Flash

4 GPU

GLM-5.3 Flash

2 GPU

Qwen3.6

1 GPU

gpt-oss

1 GPU

4개 모델 상주를 목표로 한 후보. DeepSeek의 실제 가중치 형식과 KV 메모리 검증 필요.

이 배분은 동시 적재가 검증된 확정 구성은 아닙니다. 특히 A안의 GLM-5.3 FP8은 가중치만 약 753GB 수준이고, B안의 DeepSeek-V4.1-Flash는 552B이므로 정밀도에 따라 요구량이 크게 달라집니다. 또한 각 모델의 TP/EP 지원 여부도 확인해야 합니다.

제가 우선 검증할 안은 B안입니다. 단, GLM-5.3까지 항상 켜놓아야 한다면 B300 한 노드에서 5개 모델을 동시에 제공하기보다는 시간대별 모델 교체 또는 추가 GPU 노드가 필요할 가능성이 높습니다.

3. K8s 배포 구조

각 모델은 독립된 vLLM Deployment와 ClusterIP Service로 배포하고, Gateway에서 모델명에 따라 라우팅합니다. vLLM Production Stack도 여러 모델을 각각 다른 GPU에 배포하는 패턴을 제공합니다.

image

GitHub

Compute Cluster / Clients

OpenAI-compatible API

API Gateway / LiteLLM (선택)

모델 라우팅 · API Key · Rate Limit

GPU Node · B300 × 8

vLLM Deployment: DeepSeek

vLLM Deployment: GLM

vLLM Deployment: Qwen

vLLM Deployment: gpt-oss

Docling Worker · CPU/GPU 별도

MinIO AIStor

모델 파일 · Docling 입력/출력 · 로컬 NVMe 캐시

GPU 지정은 Kubernetes nvidia.com/gpu 정수 리소스를 기본으로 사용합니다. 예를 들어 TP=4 모델은 4개 GPU를 요청하는 하나의 Pod로 배치합니다. 일반적인 Device Plugin 환경에서 여러 Pod가 동일 GPU를 공유하려면 별도 공유 설정이 필요하므로, 기본 구성에서는 GPU 중복 할당을 피하는 것이 안전합니다.

4. vLLM 초기 설정 예시

Qwen3.6-35B-A3B는 공식 모델 카드에서 vLLM 사용을 안내하고 있어, 첫 검증 대상으로 적합합니다.

image

Hugging Face

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-qwen36
  namespace: llm
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: vllm-qwen36
  template:
    metadata:
      labels:
        app: vllm-qwen36
    spec:
      nodeSelector:
        kubernetes.io/hostname: gpu-b300-01
      containers:
        - name: vllm
          image: vllm/vllm-openai:<validated-version>
          command: ["vllm", "serve"]
          args:
            - Qwen/Qwen3.6-35B-A3B
            - --served-model-name
            - qwen36
            - --tensor-parallel-size
            - "1"
            - --gpu-memory-utilization
            - "0.85"
            - --max-model-len
            - "32768"
          resources:
            limits:
              nvidia.com/gpu: 1
          ports:
            - containerPort: 8000

<validated-version>은 B300, CUDA, 모델 아키텍처가 검증된 이미지 태그로 교체해야 합니다. 32768 context와 0.85 메모리 비율은 시작값이며 최종값이 아닙니다. 노드 로컬 모델 캐시 볼륨, Secret, readiness/startup probe, Service 등은 실제 배포 시 추가해야 합니다.

5. Docling은 별도로 운영하는 것이 좋습니다

Docling의 Standard Pipeline은 OCR·레이아웃·테이블 분석을 CPU/GPU로 처리할 수 있고, VLM Pipeline은 별도 추론 서버와 연동할 수 있습니다.

image

Docling

초기에는 다음 순서를 추천합니다.

CPU Docling Worker를 기존 Compute 클러스터에 배포해 처리량을 측정합니다.
OCR/레이아웃 처리가 병목이면 B300 GPU 1장을 전용 할당합니다.
VLM 기반 문서 이해가 필요하면 기존 Qwen 등의 API와 연결할 수 있는지 품질 검증합니다.
Docling 결과는 AIStor에 Markdown/JSON 등으로 저장합니다.

이렇게 하면 비싼 B300 GPU를 문서 변환에 고정적으로 할당하는 것을 피할 수 있습니다.

6. Stage7에서 확정할 설정

항목	초기값/검증 방향
GPU	모델별 1/2/4/6/8장 후보
TP	1, 2, 4, 8 비교
EP	대형 MoE에서 지원 커널 검증
DP	남는 GPU가 있을 때 replica 확장
Context	8K / 32K / 64K 단계적 검증
Concurrency	1 / 4 / 8 / 16 요청
KV Cache	가중치 적재 후 실제 여유 측정
성능	TTFT, ITL, output tok/s, GPU HBM
안정성	OOM, 모델 로딩 시간, 재시작

대형 MoE에서는 EP가 유용할 수 있지만, vLLM 버전과 DeepEP/DeepGEMM 등의 호환성을 검증해야 합니다.

image

GitHub

최종 권장

B300 8장 한 노드에서 5개 LLM을 모두 상주시키는 것을 초기 목표로 잡기보다는, Qwen + gpt-oss를 안정적으로 상주시키고 대형 모델을 선택적으로 운영하는 방식을 추천합니다.

구체적인 GPU 배분을 확정하려면 한 가지 조건이 가장 중요합니다.

5개 LLM이 모두 24시간 동시에 응답해야 하나요?

5개 모두 24시간 상주 필수

자주 쓰는 모델만 상주, 나머지는 교체 가능

주간/야간 시간대별 모델 전환 가능

이 조건으로 상세 배분 설계

이 조건에 따라 모델별 GPU 수, FP8/FP4 선택, TP/EP, 예상 HBM 여유, K8s Deployment 구성을 현실적으로 좁힐 수 있습니다.

===

B300 × 8 멀티모델 vLLM 주간/야간 운영 설계

권장 방향은 주간에 경량·Flash 모델의 응답성을 확보하고, 야간에는 대형 모델에 GPU 8장을 집중 할당하는 방식입니다.

현재 환경에서는 다음을 기준으로 설계하겠습니다.

GPU: NVIDIA B300 8장, GPU당 288GB HBM, 총 2,304GB
Kubernetes: GPU 전용 클러스터, NVIDIA GPU Operator, Cilium Native + BGP/ECMP
모델: GLM-5.3, Qwen3.6-35B-A3B, gpt-oss-20b, DeepSeek-V4.1-Flash, GLM-5.3-Flash
문서 처리: Docling
스토리지: MinIO AIStor + GPU 노드 로컬 NVMe
서빙: vLLM, 고정 Gateway URL, 향후 LiteLLM/Keycloak 확장

설계에서 가장 중요한 것은 GPU별 물리적 할당과 HBM 사용량을 구분하는 것입니다. 예를 들어 4-GPU 모델이 GPU당 100GB만 사용하더라도, Kubernetes에서 GPU 4장을 독점 할당했다면 남은 HBM을 다른 Pod가 자동으로 사용할 수 있는 것은 아닙니다.

또한 아래 정밀도와 TP/EP는 배포를 위한 후보값입니다. 각 모델의 실제 체크포인트, vLLM 지원 여부, FP8/FP4 커널 호환성 확인 전에는 운영 확정값으로 취급하면 안 됩니다.

1. 모델별 정밀도와 HBM 용량 계획

우선 가중치 메모리만 계산하면 다음과 같습니다. 아래 표에서 GLM-5.3은 753B, DeepSeek-V4.1-Flash는 552B라는 앞선 모델 규모 가정을 사용합니다. 나머지 모델의 정확한 체크포인트와 파라미터 수는 배포 전에 확인해야 합니다.

모델	계획 정밀도	가중치 메모리 추정	권장 GPU 후보
GLM-5.3 (753B 가정)	FP8	약 753GB	8
GLM-5.3	FP4 계열	약 377GB + 오버헤드	4~8
DeepSeek-V4.1-Flash (552B 가정)	FP8	약 552GB	4~8
DeepSeek-V4.1-Flash	FP4 계열	약 276GB + 오버헤드	2~4
Qwen3.6-35B-A3B (35B 가정)	BF16	약 70GB	1
gpt-oss-20b (20B 가정)	네이티브 저정밀 포맷 우선	포맷별 확인	1
GLM-5.3-Flash	FP8/FP4 후보	파라미터 수 확인 필요	미확정

GB는 십진 단위의 이론적인 가중치 크기입니다. 실제 GPU 메모리에는 양자화 스케일, 비양자화 레이어, 런타임 버퍼, CUDA Graph, KV Cache가 추가됩니다. FP4는 모델별 호환 체크포인트가 있다는 전제이며, 단순히 플래그를 켜면 자동으로 지원되는 것은 아닙니다.

HBM 예산 계산

초기에는 GPU당 전체 288GB 중 약 85%인 244.8GB를 vLLM 메모리 예산의 상한 후보로 잡겠습니다. 나머지는 드라이버, CUDA, 기타 프로세스와 여유 공간을 위해 남깁니다.

GPU HBM 계획 계산기

가중치 기준 추정

모델 크기

GLM-5.3 · 753B 가정

DeepSeek-V4.1-Flash · 552B 가정

Qwen3.6 · 35B 가정

gpt-oss · 20B 가정

정밀도

BF16

FP8

FP4 (이론치)

GPU 수

1 GPU

2 GPU

4 GPU

8 GPU

가중치 추가 오버헤드 가정

15%

GPU당 가중치 + 가정 오버헤드

158.7 GB

GPU당 남은 계획 예산

86.1 GB

남은 공간은 KV Cache, activation, 런타임 버퍼 등의 실제 측정 전 상한입니다.

이 계산은 모든 가중치가 균등하게 샤딩된다는 단순 모델입니다. EP 구성에서는 attention 복제, shared expert, expert 불균형으로 실제 GPU별 HBM이 달라집니다.

2. 권장 주간/야간 GPU 프로파일

추가 확인 결과 GLM-5.3-Flash는 약 321B 규모이며, 공개 체크포인트는 FP8 계열입니다. 따라서 앞서 제시했던 GLM Flash 2-GPU 배치는 가능성은 있지만 HBM 여유와 모델 지원을 검증해야 합니다.

image

Hugging Face

주간: 경량 모델과 Flash 중심

DAY Profile

예: 08:00–20:00

GLM-F

DS-F

Qwen

OSS

GLM-5.3-Flash	2 GPU · FP8 · TP2
DeepSeek-V4.1-Flash	4 GPU · FP8 · TP4
Qwen3.6-35B-A3B	1 GPU · BF16 · TP1
gpt-oss-20b	1 GPU · MXFP4 · TP1

조건부 구성: GLM Flash 2장 및 DeepSeek 4장에 모델 가중치, KV Cache, 런타임이 모두 적재되고 vLLM에서 정상 구동되는 경우에만 채택합니다.

Docling은 이 프로파일에서는 Compute 클러스터의 CPU Worker로 운영합니다. GPU 가속이 필요하면 Qwen 또는 gpt-oss용 GPU 중 하나를 Docling 전용으로 전환하는 별도 프로파일을 만듭니다.

야간: GLM-5.3 고품질 추론 중심

NIGHT Profile

예: 20:00–08:00

GLM

GLM-5.3 · 8 GPU · FP8

1차 후보 TP8 / DP1 / EP 비활성

2차 후보 TP2 / DP4 / EP8 — 커널 지원 및 처리량 비교 후 결정

야간에는 다른 GPU 모델을 종료하므로 해당 API의 요청은 대기·거절·대체 모델 라우팅 중 하나의 정책을 적용해야 합니다.

GLM-5.3의 공개 FP8 체크포인트 크기는 약 756GB이므로 8장에 균등 배분하면 GPU당 가중치가 약 95GB입니다. HBM 용량 자체는 충분하지만, 모델 아키텍처에 맞는 vLLM 버전과 커널이 정상 동작해야 합니다.

image

Hugging Face

대안: 야간에도 소형 모델 유지

야간 API 연속성이 필요하다면 다음 구성도 후보입니다.

모델	GPU	정밀도
GLM-5.3	6	FP8, TP6 후보
Qwen3.6	1	BF16
gpt-oss-20b	1	MXFP4

단, TP6이 해당 모델에서 지원되는지와 성능을 반드시 확인해야 합니다. 단순한 메모리 계산만으로 TP6을 운영 가능하다고 판단해서는 안 됩니다.

3. 모델별 vLLM 시작 파라미터

모델	TP	DP	EP	Context 시작값	`max-num-seqs`
GLM-5.3	8	1	비활성	32K	8
GLM-5.3-Flash	2	1	비활성	16K	8
DeepSeek-V4.1-Flash	4	1	비활성	16K	8
Qwen3.6-35B-A3B	1	1	비활성	32K	16
gpt-oss-20b	1	1	비활성	32K	16

이 값은 첫 구동을 위한 보수적인 테스트 출발점이지 성능 최적값이 아닙니다. 모델별 최대 context 및 구현 지원에 따라 조정해야 합니다.

MoE 모델은 TP 방식으로 먼저 안정적인 구동을 확인하고, 이후 EP를 비교합니다. vLLM의 EP는 별도의 임의 숫자로 설정하는 것이 아니라 일반적으로 EP = TP × DP 관계로 구성되며, --enable-expert-parallel로 활성화합니다.

image

vLLM

EP를 사용할 경우 attention은 TP/DP 구성에 따라 분할 또는 복제되고, expert는 EP 그룹에 분산됩니다. 따라서 TP2/DP4/EP8이 TP8/DP1보다 항상 빠르지는 않습니다.

4. 공개 체크포인트 기준 HBM 추정 보정

모델 저장소를 확인한 결과, 단순한 파라미터 수 × 비트 수보다 실제 체크포인트 크기를 기준으로 잡는 편이 정확합니다.

모델	공개 체크포인트 크기	제안 GPU 수	GPU당 가중치 단순 평균
GLM-5.3	약 756GB	8	94.5GB
GLM-5.3-Flash	약 321GB 이상 규모	2	약 160GB 이상
DeepSeek-V4.1-Flash	약 510GB	4	127.5GB
Qwen3.6-35B-A3B	약 71.9GB	1	71.9GB
gpt-oss-20b	약 13.8GB	1	13.8GB

image

Hugging Face

DeepSeek의 체크포인트는 단순 FP8이 아니라 FP8과 FP4 expert를 조합한 형식이므로, 공개 체크포인트를 그대로 로딩하는 것을 우선 권장합니다.

image

deepseek-ai/DeepSeek-V4.1-Flash at main

이 수치는 파일 크기를 균등 분할한 계산이며 실제 HBM 사용량은 아닙니다. GLM-5.3-Flash의 정확한 체크포인트 크기, vLLM의 GPU별 메모리 할당, KV Cache 여유는 별도 측정해야 합니다.

5. Kubernetes 배포 구조

초기에는 Kueue로 상주 추론 Deployment를 관리하려 하기보다, Argo CD로 모델별 Deployment를 선언적으로 관리하고 주간/야간 프로파일을 전환하는 방식을 권장합니다.

Client / Compute Cluster

고정 API URL · llm.ai.internal

Gateway / LiteLLM

모델 라우팅 · 가용성 · 인증

GPU Kubernetes Cluster

Day Profile

GLM Flash · 2 GPU

DeepSeek Flash · 4 GPU

Qwen · 1 GPU

gpt-oss · 1 GPU

Night Profile

GLM-5.3 · 8 GPU

기타 GPU Deployment 중지

Argo CD · Profile Controller/CronJob

Local NVMe Cache ↔ MinIO AIStor

모델 가중치 · 버전 고정 · 사전 다운로드

주간/야간 전환 절차

단일 B300 노드에서는 두 프로파일을 동시에 띄울 GPU 여유가 없으므로 무중단 전환은 보장할 수 없습니다.

Gateway에서 전환 대상 모델의 신규 요청을 중단하고 진행 중 요청을 drain합니다.
현재 프로파일의 Deployment를 replicas: 0으로 변경합니다.
GPU 메모리와 Pod 종료를 확인합니다.
다음 프로파일의 Deployment를 활성화합니다.
vLLM 모델 로딩 및 /health 확인 후 Gateway 라우팅을 전환합니다.
실패하면 이전 프로파일로 롤백합니다.

Argo CD를 사용한다면 CronJob이 Deployment를 직접 패치하는 것보다 Git의 프로파일 값을 변경하는 방식이 GitOps 상태 불일치를 줄입니다. 단순 CronJob 직접 패치 방식은 Argo CD 자동 동기화와 충돌하지 않도록 별도 설계가 필요합니다.

Deployment 템플릿

아래는 DeepSeek 4-GPU 프로파일을 위한 기본 예시입니다. 정확한 모델/커널 호환성을 검증한 vLLM 이미지를 사용해야 합니다.


apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-deepseek-flash
  namespace: llm
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: vllm-deepseek-flash
  template:
    metadata:
      labels:
        app: vllm-deepseek-flash
    spec:
      nodeSelector:
        kubernetes.io/hostname: gpu-b300-01
      containers:
        - name: vllm
          image: registry.internal/vllm:validated-b300
          command: ["vllm", "serve"]
          args:
            - /models/deepseek-v4.1-flash
            - --served-model-name
            - deepseek-v4.1-flash
            - --tensor-parallel-size
            - "4"
            - --gpu-memory-utilization
            - "0.85"
            - --max-model-len
            - "16384"
            - --max-num-seqs
            - "8"
          resources:
            limits:
              nvidia.com/gpu: 4
          ports:
            - containerPort: 8000
          volumeMounts:
            - name: models
              mountPath: /models
              readOnly: true
      volumes:
        - name: models
          hostPath:
            path: /data/model-cache
            type: Directory

실제 운영에서는 hostPath 대신 Local PV 또는 통제된 노드 로컬 캐시를 고려하고, 모델별 디렉터리·버전·접근 권한을 분리해야 합니다. GPU Device Plugin이 할당한 장치를 사용하므로 별도 CUDA_VISIBLE_DEVICES 하드코딩은 피합니다.

또한 모델 로딩에 수분 이상 걸릴 수 있으므로 startup probe와 충분한 종료 유예시간, terminationGracePeriodSeconds를 설정해야 합니다.

6. Stage7 검증 순서와 합격 기준

각 모델을 처음부터 동시 배포하지 말고 다음 순서로 검증하는 것이 좋습니다.

순서	검증	합격 기준
1	Qwen 1 GPU, gpt-oss 1 GPU	정상 응답, KV Cache 및 HBM 측정
2	GLM Flash 2 GPU	로딩 성공, OOM 없음, 목표 context 충족
3	DeepSeek Flash 4 GPU	로딩 성공, FP8/FP4 커널 호환
4	주간 4개 모델 동시 실행	GPU 충돌 없음, 목표 동시성 충족
5	GLM-5.3 8 GPU	단독 서빙 성공, TP/EP 비교
6	주간 ↔ 야간 전환	정상 drain, 모델 재기동, 라우팅 복구
7	Docling CPU/GPU 비교	문서 처리량과 GPU 점유율 측정

최소한 TTFT, ITL, output tokens/sec, GPU HBM, KV Cache 사용률, 요청 대기시간, 모델 로딩시간을 기록합니다.

최종 추천 구성

시간대	모델	GPU
주간	GLM-5.3-Flash	2
주간	DeepSeek-V4.1-Flash	4
주간	Qwen3.6-35B-A3B	1
주간	gpt-oss-20b	1
야간	GLM-5.3	8
상시	Docling CPU Worker	0

이것을 1차 PoC 목표 프로파일로 정하는 것을 추천합니다.

다만 실제 운영 확정 전 가장 중요한 검증은 GLM-5.3-Flash의 2-GPU 적재, DeepSeek-V4.1-Flash의 4-GPU 적재, 그리고 B300 환경의 최신 vLLM 커널 호환성입니다. 세 항목이 확인되면 주간 4모델·야간 1모델 구성은 상당히 구체화할 수 있습니다.

그리고 주간에 GLM-5.3까지 반드시 접근 가능해야 한다면, 단일 노드에서는 API 연속성보다 모델 교체를 우선하는 구조이므로 별도 GPU 노드 추가 또는 외부 대체 엔드포인트를 검토해야 합니다.

===

현재 정리한 Stage7 검증 7단계는 기존 script7의 테스트 항목과 완전히 1:1로 대응하는 구조는 아닙니다.

특히 구분해야 할 부분은 다음과 같습니다.

모델 단독 성능 검증: 기존 script7의 핵심 역할
여러 모델의 동시 상주 검증: GPU 할당 충돌, HBM, 처리량 간섭 검증
주간/야간 프로파일 전환: Kubernetes Deployment와 Gateway까지 포함하는 운영 검증
Docling CPU/GPU 비교: vLLM 모델 벤치마크와는 별도인 문서 처리 파이프라인 검증

따라서 기존 script7은 최대한 재사용하되, 멀티모델 배치 및 K8s 운영 검증을 별도 단계로 추가하는 것이 좋습니다.

다만 현재 대화에는 기존 script7의 실제 코드나 테스트 항목 목록이 없어, 스크립트 내부 함수·옵션과의 정확한 매핑은 아직 확정할 수 없습니다.

1. Stage7의 7단계와 기존 script7 매핑

아래는 실제 코드 확인 전의 기능 기준 잠정 매핑입니다.

Stage7	기존 script7에서 대응할 테스트	추가 필요성
1. Qwen/gpt-oss	단일 모델 로딩, HBM, KV Cache, 추론 벤치마크	GPU별 배치 검증
2. GLM Flash	모델 로딩, Context, OOM, TP 테스트	MoE 커널·EP 호환성
3. DeepSeek Flash	모델 로딩, FP8/FP4, TP 성능	양자화 커널·EP 비교
4. 주간 4모델	단일 모델 벤치마크 재사용	동시 상주·간섭 테스트 신규
5. GLM-5.3	TP/DP/EP, HBM, 처리량	다중 GPU 통신·NCCL 분석
6. 주야간 전환	직접 대응하는 벤치마크가 없을 가능성	K8s 운영 테스트 신규
7. Docling	일반 LLM 벤치마크와 별도	Docling 전용 테스트 신규

2. 부족할 가능성이 높은 검증 항목

단순히 7단계를 수행하는 것만으로는 최적 GPU 배분을 확정하기 어렵습니다. 특히 다음 항목을 추가해야 합니다.

항목	필요한 검증	이유
GPU 적재	GPU별 HBM peak, OOM, 초기화 시간	GPU 수 결정
TP/DP/EP	구성별 TTFT, ITL, tokens/s	병렬화 최적값
KV Cache	Context × Concurrency 조합	실제 동시 사용자 수
모델 품질	FP8/FP4 품질 회귀 테스트	양자화에 따른 정확도 저하 확인
동시 상주	4개 모델 동시 부하 및 간섭	주간 프로파일 검증
NVMe/AIStor	Cold/Warm 모델 로딩 시간	주야간 전환 시간
K8s	Pod 재시작, GPU 해제, 롤백	운영 안정성
Gateway	Drain, timeout, 인증, 라우팅	서비스 연속성
Docling	페이지/s, 문서 품질, CPU/GPU 사용량	GPU 할당 필요성 판단

추가로 중요한 것은 TP/EP 성능 측정과 GPU 배분을 확정하는 순서입니다. 예를 들어 GLM Flash가 2GPU에 적재된다는 사실만으로 2GPU가 최적이라는 결론을 내리면 안 됩니다. 2GPU와 4GPU에서 동일한 context·concurrency 조건으로 처리량과 지연시간을 비교해야 합니다.

3. 제가 권장하는 최종 테스트 구조

기존 script7을 성능 측정 엔진으로 유지하고 다음처럼 구성하는 것이 좋겠습니다.

기존 script7

단일 모델 벤치마크 · HBM · TP/DP/EP · KV Cache

확장 테스트

Multi-Model Test

Profile Switch Test

Storage/Cache Test

Docling Test

최종 모델별 서빙 프로파일

GPU / TP / DP / EP / HBM / KV / Context / Concurrency

Day Profile · Night Profile · Rollback Profile

이렇게 하면 단일 모델 성능 테스트와 운영 수준의 검증을 분리할 수 있습니다.

기존 script7 파일 또는 해당 스크립트가 포함된 디렉터리를 ZIP으로 올려주실 수 있을까요?

파일을 확인하면 각 테스트를 기존 함수·CLI 옵션에 정확히 매핑하고, 재사용 가능 / 수정 필요 / 신규 추가로 구분한 뒤 누락 항목과 구체적인 변경 지점까지 정리하겠습니다.

===

아, script7이 아니라 기존에 논의했던 Stage7 검증 절차를 말씀하신 거군요.

그러면 별도 스크립트와 매핑하는 것이 아니라, 기존 Stage7의 세부 테스트 항목과 이번에 제안한 7개 검증 단계를 비교해야 합니다.

다만 현재 확인 가능한 이전 대화에는 Stage7의 전체 세부 테스트 정의가 없으므로, 아래는 기존에 논의한 Stage7의 검증 목적을 기준으로 한 잠정 매핑입니다.

1. 기존 Stage7과 이번 7개 Step 매핑

이번 Step	기존 Stage7에서 대응하는 검증 영역	추가 검증
1. Qwen / gpt-oss	단일 모델 HBM, KV Cache, Context, Concurrency, TTFT/ITL	1GPU 동시 상주
2. GLM Flash	모델 적재, TP, Context, HBM, OOM	MoE 커널 호환성, EP
3. DeepSeek Flash	TP/EP, 양자화, 처리량, HBM	FP8/FP4 혼합 체크포인트
4. 주간 4모델	모델별 성능 검증 결과 활용	멀티모델 동시 부하 및 간섭
5. GLM-5.3	TP/DP/EP 최적화, KV Cache, Concurrency	8GPU 분산 통신
6. 주야간 전환	모델별 프로파일 결과 활용	K8s 프로파일 전환·복구
7. Docling	직접 대응 영역 확인 필요	CPU/GPU 문서 처리 성능

2. Stage7에서 보완해야 할 핵심

이번 B300 8GPU 멀티모델 운영에서는 기존 모델별 벤치마크 외에 세 가지 검증 영역이 중요합니다.

첫째, Multi-Model 검증입니다. 개별 모델이 정상 동작하더라도 4개 모델을 동시에 실행했을 때 GPU별 메모리, CPU/RAM, NVMe I/O, API 응답 지연이 어떻게 달라지는지 확인해야 합니다.

둘째, Profile Switching 검증입니다. 주간 4개 모델에서 야간 GLM-5.3으로 전환할 때 요청 drain, GPU 자원 해제, 모델 로딩, Gateway 라우팅 변경, 실패 시 롤백까지 검증해야 합니다.

셋째, Storage 및 Model Loading 검증입니다. MinIO AIStor에서 모델을 직접 읽는 경우와 로컬 NVMe 캐시에서 읽는 경우의 Cold/Warm Start 시간을 비교해야 합니다.

3. 권장 Stage7 확장 구조

구분	테스트 범위
Stage7-A	모델별 단독 적재 및 HBM 측정
Stage7-B	TP/DP/EP 및 정밀도 최적화
Stage7-C	Context, KV Cache, Concurrency 최적화
Stage7-D	주간 멀티모델 동시 상주 검증
Stage7-E	야간 대형 모델 단독 검증
Stage7-F	주간/야간 전환 및 장애 복구
Stage7-G	AIStor/NVMe 로딩 성능 및 Docling 검증

여기서 A~G는 기존 Stage7의 공식 단계명이 아니라 이번 환경에 맞춰 제가 제안하는 분류입니다.

다음 확인 사항

정확히 매핑하려면 이전에 정리한 Stage7 테스트 계획서 또는 Stage7의 세부 단계 목록이 필요합니다.

그 내용을 공유해 주시면 기존 Stage7의 순서와 명칭을 그대로 유지하면서 다음 세 가지를 명확히 정리하겠습니다.

이번 7개 Step이 기존 Stage7의 어느 테스트에 해당하는지
기존 Stage7만으로 충분한 부분과 부족한 부분
B300 8GPU의 주간/야간 멀티모델 운영을 위해 추가해야 할 테스트

특히 기존 Stage7을 불필요하게 다시 설계하지 않고, 기존 검증 체계에 필요한 테스트만 추가하는 방향으로 정리하겠습니다.

===

기존 Stage7 Main 스크립트 분석

올려주신 7개 파일을 기준으로 확인하면, 기존 Stage7은 이미 **LLM 야간 배치(Stage7a), 온라인 SLO(Stage7b), Docling(Stage7c), K8s 재검증(Stage7d)**으로 구분되어 있습니다.

따라서 기존 구조를 새로 만들 필요는 없습니다. 현재 구조를 유지하면서 B300 8GPU의 주간/야간 멀티모델 운영에 필요한 테스트만 보완하는 것이 좋겠습니다.

1. 기존 Stage7 구성

구분	Main 파일	현재 역할
Stage7a	`stage7a_night_batch_qualification.sh`	GLM-5.3, Qwen, gpt-oss 야간 배치 검증
Stage7b	`stage7b_online_slo_qualification.sh`	DeepSeek Flash, GLM Flash 온라인 검증
Stage7c	`stage7c_docling_run.sh`	Docling 문서 처리 및 품질 검증
Stage7d	`stage7d_k8s_model_revalidation.sh`	K8s 배포 후 LLM 성능 재검증

Stage7a와 7b는 모두 stage7_llm_qualification.py를 호출하고, 각각 night_batch, online 클래스를 전달합니다. Stage7d는 같은 엔진을 --external-server 옵션으로 호출하므로 기존 bare-metal 테스트와 K8s 테스트의 비교를 의도한 구조입니다.

stage7a_night_batch_qualification.sh

stage7b_online_slo_qualification.sh

stage7d_k8s_model_revalidation.sh

여기서 중요한 점은 Stage7a의 night_batch는 워크로드 유형이지, 반드시 야간에만 실행하는 Kubernetes 프로파일을 의미하지는 않는다는 것입니다. 따라서 Qwen과 gpt-oss를 주간에 상주시켜도 기존 Stage7a의 배치 테스트를 그대로 재사용할 수 있습니다.

2. 앞서 제안한 7개 Step과 실제 Main 매핑

Step	검증 내용	기존 Stage7	판정
1	Qwen/gpt-oss 단독 검증	7a	부분 확인
2	GLM Flash 2GPU	7b	부분 확인
3	DeepSeek Flash 4GPU	7b	부분 확인
4	주간 4모델 동시 상주	7a + 7b + 7d	추가 필요
5	GLM-5.3 8GPU	7a	부분 확인
6	주간 ↔ 야간 프로파일 전환	7d 연계	신규 필요
7	Docling CPU/GPU 비교	7c	확장 필요

여기서 '부분 확인'은 해당 모델을 대상으로 하는 Main 진입점이 존재한다는 의미입니다. 실제 TP/DP/EP, HBM, KV Cache, Context 및 성능 측정 구현까지 확인됐다는 뜻은 아닙니다.

3. 파일별 확인 결과와 부족한 부분

Stage7a / Stage7b — 기존 구조 유지

모델과 워크로드 클래스를 공통 Python 엔진에 전달하는 방식이므로 구조가 적절합니다. 다만 실제 TP/EP 탐색, HBM 측정, KV Cache 분석, SLO 합격 기준은 stage7_llm_qualification.py와 manifest를 확인해야 합니다.

Stage7c — Docling 품질 측정은 이미 구현

문서별 처리시간, pages/min, 성공률, 텍스트 유사도, 테이블/그림 개수 등을 수집합니다. 텍스트 유사도 임계값도 지정할 수 있습니다.

stage7c_document_pipeline.py

그러나 GPU peak HBM, CPU/GPU 비교, GPU 점유율, 처리 동시성은 현재 Main 코드에서 확인되지 않습니다. 또한 기본 유사도는 정식 OCR CER/WER가 아닙니다.

Stage7d — K8s 단일 모델 재검증

K8s에서 이미 노출된 모델 엔드포인트를 대상으로 기존 테스트 엔진을 재사용합니다.

stage7d_k8s_model_revalidation.sh

하지만 이 Main 자체에는 Deployment 생성, GPU 스케줄링, 여러 모델 동시 부하, 주야간 전환, drain/rollback 기능이 없습니다.

추가로 Stage7c의 Golden Template는 현재 텍스트 PDF, 스캔 PDF, 테이블 PDF의 3개 샘플 경로로 구성되어 있습니다. 실제 운영 검증에는 복잡한 표, 다단 문서, 이미지 포함 문서, 대용량 PDF 등으로 Golden Set을 확장하는 것이 좋습니다.

4. 권장 보완 구조

기존 Stage7a~d는 유지하고 두 가지를 추가하는 것이 가장 깔끔합니다.

구분	권장 역할	변경
Stage7a	야간 배치 유형의 LLM 성능 검증	유지
Stage7b	온라인 LLM SLO 검증	유지
Stage7c	Docling 품질 및 CPU/GPU 비교	확장
Stage7d	K8s 단일 모델 재검증	유지
Stage7e (신규)	주간 4모델 동시 상주 및 성능 간섭	추가
Stage7f (신규)	주간/야간 전환, Gateway, 장애 복구	추가

Stage7e에서는 모델별 단독 측정 결과를 기준선으로 삼아, 4개 모델을 동시에 실행했을 때 TTFT, ITL, throughput, GPU HBM 및 오류율이 얼마나 변하는지 비교합니다.

Stage7f에서는 GPU 할당 해제, Pod 종료, 모델 재로딩, Gateway 라우팅, 요청 drain, 롤백을 검증합니다.

5. 추가로 확인해야 할 파일

정확한 기능 매핑과 코드 변경 범위를 확정하려면 다음 파일이 필요합니다.

stage7_llm_qualification.py — Stage7a/b/d의 공통 핵심 엔진
stage7_model_qualification.yaml — 모델별 검증 조건과 합격 기준
validation_env.sh — 테스트 실행 환경
stage7_docling_adapter.py — Docling 실제 실행 어댑터

현재 Main 기준 결론: Stage7a~d의 구조는 유지해도 됩니다. 다만 주간 4모델 동시 상주와 주야간 전환은 기존 Stage7의 단순 재실행만으로 검증할 수 없으므로 Stage7e/f를 추가하는 것이 좋습니다.

다음으로 공통 엔진과 manifest를 확인하면, 기존 Stage7에서 이미 측정하는 항목을 중복 개발하지 않고 정확히 무엇을 추가해야 하는지 함수 단위까지 정리할 수 있습니다.

===

추가로 올려주신 Stage7 공통 엔진, 모델 manifest, Production Policy, Evidence 및 배포 설정 생성 코드를 확인했습니다.

이제 주간/야간 모델 구성을 다음과 같이 확정된 운영 요구사항으로 반영하겠습니다.

1. 확정된 주간/야간 모델 구성

구분	모델	기존 Stage7
야간	GLM-5.3	7a
야간	Qwen3.6-35B-A3B	7a
야간	gpt-oss-20b	7a
주간	DeepSeek-V4.1-Flash	7b
주간	GLM-5.3-Flash	7b
주야간 상시	Docling	7c
공통	K8s 재검증	7d

이는 실제 stage7_model_qualification.yaml에 정의된 night_batch, online, document 워크로드 구분과도 일치합니다.

stage7_model_qualification.yaml

단, 워크로드 분류와 실제 GPU 상주 배치는 별개입니다. 현재 Stage7은 모델별 최적 구성을 찾도록 설계되어 있지만, B300 8장에 해당 시간대의 모든 모델과 Docling이 동시에 들어가는지는 아직 검증되지 않았습니다.

2. 기존 Stage7의 실제 구현 수준

추가 파일을 확인하면서 이전 분석에서 보완해야 할 부분도 발견했습니다.

검증 항목	현재 구현	판정
모델별 TP 후보 탐색	Manifest의 `tp_candidates` 순회	구현
Context / Concurrency	프로파일별 부하 테스트	구현
TTFT / ITL / Throughput	vLLM benchmark 측정	구현
SLO + Headroom 기반 선택	최소 TP 후보 선택	구현
온라인 간섭 테스트	동일 모델의 Short/Long 혼합 AB/BA	구현
Bare-metal ↔ K8s 비교	Baseline Compare + Fingerprint	구현
품질 / Soak / K8s 승인	Evidence Gate	승인 로직 구현
GPU별 Peak HBM	직접 측정 및 합격 판정	부족
EP / DP 최적화	TP 외 병렬화 탐색	미구현
모델별 정밀도 비교	BF16/FP8 등 자동 탐색	미구현
주간 2모델 동시 실행	모델 간 자원 및 SLO 간섭	미구현
야간 3모델 동시 실행	모델 간 자원 및 처리량 간섭	미구현
Docling 상시 실행	LLM과 자원 공유 검증	미구현
주야간 자동 전환	Drain / 재배포 / 롤백	미구현

현재 stage7_llm_qualification.py는 TP 후보별로 vLLM을 실행하고, Warm-up 후 부하 테스트를 수행하며, SLO와 Headroom을 기준으로 후보를 선택합니다.

stage7_llm_qualification.py

또한 기존 간섭 테스트는 동일 vLLM 서버의 Short/Long 요청 간섭을 측정하는 것이므로 서로 다른 모델 간의 간섭 검증을 대체하지 못합니다.

3. B300 8GPU에서 확인해야 할 자원 배분

현재 manifest에 있는 TP 후보를 기준으로 하면 다음과 같습니다.

시간대	모델	현재 TP 후보
야간	GLM-5.3	8
야간	Qwen3.6-35B-A3B	1, 2
야간	gpt-oss-20b	1, 2
주간	DeepSeek-V4.1-Flash	2, 4, 8
주간	GLM-5.3-Flash	2, 4, 8

stage7_model_qualification.yaml

이때 중요한 문제가 있습니다.

야간 — 현재 Manifest 최소 GPU 합계

GLM-5.3

Qwen

gpt-oss

최소 요구 GPU 합계

10 / 8

주간 — 최소 GPU 합계

DeepSeek Flash

GLM Flash

최소 요구 GPU 합계

4 / 8

TP를 GPU 점유 수와 동일하게 가정한 단순 계산입니다. 실제 적재 가능성과 성능을 보장하지 않습니다. Docling GPU 사용량은 제외했습니다.

즉, 현재 manifest 그대로는 야간 3모델의 GPU 동시 상주가 불가능합니다. GLM-5.3이 8장을 전부 사용하기 때문입니다.

주간에는 두 모델을 각각 2~4GPU로 배분하는 후보를 검토할 수 있지만, 모델 체크포인트의 실제 HBM 적재와 SLO 충족 여부가 선행 검증되어야 합니다.

Docling은 우선 CPU Worker로 상시 운영하는 구성을 기준으로 잡는 것이 적절합니다. Docling에 GPU가 반드시 필요하다면 주간과 야간 각각 GPU를 별도로 확보하거나 공유 방식을 검증해야 합니다.

4. 기존 Stage7에서 추가로 발견한 개선점

현재 코드는 단순 테스트뿐 아니라 운영 설정 생성까지 이미 상당 부분 구현되어 있습니다.

stage7_baseline_compare.py: Bare-metal과 K8s 결과를 동일 workload key로 비교하고, Fingerprint 차이도 검증합니다.

stage7_baseline_compare.py
stage7_generate_production_config.py: Evidence Gate 통과 후 Production Profile과 Helm Values를 생성합니다.

stage7_generate_production_config.py
stage7_generate_serving_platform_configs.py: InferencePool, HTTPRoute, LiteLLM 용량 설정을 생성합니다.

stage7_generate_serving_platform_configs.py

다만 다음은 수정이 필요합니다.

TP와 GPU 수의 분리: 현재는 gpu_count = tp를 가정합니다. EP/DP를 사용한다면 실제 GPU 점유 수를 별도 계산해야 합니다.
모델별 정밀도 및 KV 설정 탐색: 현재는 런타임의 여러 설정을 자동 탐색하지 않으므로 검증 후보 매트릭스를 추가해야 합니다.
SLO 임계값 설정: Production Policy의 TTFT, ITL 및 일부 Throughput 목표가 null입니다. 운영 승인 전 실제 기준을 확정해야 합니다.

stage7_production_profile_policy.yaml
Production Profile의 조합 검증: 모델별 승인 여부뿐 아니라 시간대별 GPU 합계, Docling 자원, 실제 동시 상주 가능 여부를 검증해야 합니다.
K8s 배포 전 검증: 생성된 Helm Values와 Gateway/InferencePool 설정이 실제 클러스터에서 동작하는지 별도 검증해야 합니다.

5. 최종 권장 Stage7 확장

Stage	최종 역할	조치
7a	야간 3모델 개별 성능 검증	유지 + HBM/EP/DP 보완
7b	주간 2모델 개별 SLO 검증	유지 + HBM/EP/DP 보완
7c	Docling CPU/GPU 및 문서 품질	확장
7d	K8s 개별 모델 재검증	유지
7e	주간 2모델 + Docling 동시 운영 검증	신규
7f	야간 3모델 + Docling 운영 가능성 검증	신규
7g	주야간 프로파일 전환 및 장애 복구	신규
7h	AIStor/NVMe 모델 로딩 및 전환 시간	신규

가장 먼저 해결해야 할 것은 야간 구성입니다.

현재의 GLM-5.3 TP=8을 유지한다면 Qwen과 gpt-oss를 같은 노드에서 동시에 GPU 서빙할 수 없습니다. 따라서 야간 3모델을 반드시 동시 제공해야 하는지, 아니면 야간에 필요할 때 모델을 순차 전환해도 되는지가 설계를 결정합니다.

야간 3모델은 반드시 동시에 API 서빙되어야 하나요? 아니면 GLM-5.3을 실행하는 동안 Qwen/gpt-oss를 중지하고, 필요할 때 전환하는 방식도 가능한가요?

이 조건이 정해지면 Stage7e~h의 테스트 구조와 GPU 배분 정책을 구체적으로 확정할 수 있습니다.

===

네. GLM-5.3의 TP를 8에서 6 또는 4로 줄이는 방향을 검토할 수 있습니다. 다만 실제로 가능한지는 GLM-5.3 체크포인트의 전체 파라미터 크기, 정밀도, MoE 구조, vLLM의 병렬화 지원 여부에 달려 있습니다.

여기서 중요한 것은 TP를 줄이는 것과 GPU 사용량을 줄이는 것이 반드시 같은 의미는 아니라는 점입니다.

예를 들어 TP=4, EP=4로 설정해도 EP가 같은 4개 GPU 내에서 동작한다면 총 4GPU를 사용할 수 있지만, 별도 병렬화 구성을 사용하면 실제 GPU 수가 달라질 수 있습니다.

현재 업로드된 Stage7 manifest에는 GLM-5.3이 다음처럼 고정되어 있습니다.

glm_5_3:
  tp: 8
  tp_candidates:
    - 8

따라서 현재 Stage7은 TP=4나 TP=6을 시험하지 않고 있습니다. 이것은 TP=8만 가능하다는 증거가 아니라, 검증 후보를 8로 제한했다는 의미입니다.

1. B300에서 TP를 얼마나 줄일 수 있을까?

GLM-5.3은 약 753B 파라미터의 MoE 모델이며, 기본 체크포인트는 FP8입니다. Blackwell GPU용 NVFP4 변형도 제공됩니다.

image

vLLM Recipes

B300 1장당 HBM 288GB를 기준으로 단순 추정하면 다음과 같습니다.

정밀도	TP=4	TP=6	TP=8
FP8	약 190GB/GPU	약 127GB/GPU	약 95GB/GPU
NVFP4	약 116GB/GPU	약 78GB/GPU	약 58GB/GPU
적재 가능성	검증 필요	검증 필요	공식 레시피 존재

FP8은 약 760GB, NVFP4는 약 465GB의 가중치 규모를 균등 분할한다고 가정한 대략적인 계산입니다. 실제 HBM에는 KV Cache, 런타임, 통신 버퍼, 비균등 레이어 배치 등이 추가됩니다. NVFP4는 모든 가중치가 4비트인 구성이 아닙니다.

가장 유망한 후보는 NVFP4 + TP=4입니다. FP8 TP=4도 총 HBM 용량만 보면 가능성이 있지만, 실제 커널 호환성과 메모리 여유를 검증해야 합니다.

반면 TP=6은 GPU 수 관점에서는 매력적이지만, 모델의 Attention Head 분할 및 vLLM 커널 제약에 따라 지원되지 않을 수 있으므로 우선순위를 낮추는 것이 좋겠습니다.

2. 야간 GPU 배분 추천

권장 검증 후보 — GLM-5.3 TP=4

GPU 0–3: GLM-5.3 NVFP4, TP=4

GPU 4: Qwen3.6-35B-A3B, TP=1

GPU 5: gpt-oss-20b, TP=1

GPU 6–7: 여유 2장

Docling은 Compute 클러스터의 CPU Worker로 상시 실행하는 것을 기본 가정합니다.

이 구성은 야간 3모델을 동시에 서비스하면서 GPU 2장을 남길 수 있다는 장점이 있습니다. 단, 아직 검증되지 않은 목표 구성입니다.

3. Stage7 변경 사항

stage7_model_qualification.yaml에서 GLM-5.3의 후보를 다음처럼 확장하는 것을 권장합니다.

glm_5_3:
  tp: 8
  tp_candidates:
    - 4
    - 8

하지만 이것만 변경하면 FP8과 NVFP4를 비교할 수 없습니다. 현재 Stage7 엔진은 TP만 순회하고 정밀도별 체크포인트를 자동 전환하지 않기 때문입니다.

따라서 다음 세 가지를 별도 실행하는 것이 좋습니다.

실험	체크포인트	TP	목적
A	공식 FP8	8	기준 성능
B	공식 FP8	4	GPU 축소 가능성
C	Blackwell NVFP4	4	야간 최종 후보

각 실험에서 모델 적재 성공, Peak HBM, 최대 Context, Concurrency, 처리량, 품질 회귀를 비교합니다. 특히 NVFP4는 원본 FP8 대비 Golden Set 품질 검증이 필요합니다.

참고로 공식 vLLM 레시피는 GLM-5.3 NVFP4를 TP=8, EP 활성화 구성으로 소개하고 있으므로, TP=4는 B300에서 직접 검증해야 합니다.

image

vLLM Recipes

결론: GLM-5.3을 반드시 8GPU로 운영할 필요가 있다고 단정할 수 없습니다. 현재 환경에서는 NVFP4 + TP=4를 1순위 실험 후보, FP8 + TP=4를 2순위 후보, FP8 + TP=8을 기준선으로 두는 것이 적절합니다.

이 결과가 통과하면 야간에 GLM-5.3, Qwen, gpt-oss를 모두 상시 제공하는 6GPU 구성이 가능해집니다.

===

요청하신 내용을 반영해 B300 8GPU용 Stage7 재설계 스크립트 패키지를 만들었습니다. 기존 Stage7a~d 코드는 유지하고, 모델별 TP 후보 실험, 주야간 동시 상주 검증, GPU 배분 선택, 프로파일 전환 검증을 추가했습니다.

Stage7 B300 Redesign v2

기존 스크립트 26개 + 신규 설정·검증 스크립트·README

전체 스크립트 ZIP 다운로드

1. 반영한 운영 구성

시간대	모델	검증할 TP 후보
야간	GLM-5.3	FP8 TP8, FP8 TP4, NVFP4 TP4
야간	Qwen3.6-35B-A3B	TP1, TP2
야간	gpt-oss-20b	TP1, TP2
주간	DeepSeek-V4.1-Flash	TP2, TP4, TP8
주간	GLM-5.3-Flash	TP2, TP4, TP8
상시	Docling	Compute 클러스터 CPU 기준

특정 TP를 미리 확정하지 않고 테스트 결과로 선택하도록 했습니다. GLM-5.3의 NVFP4 TP4는 우선 검증 후보이지, 호환성이나 성능이 확인된 구성은 아닙니다.

2. Stage7 최종 구성

Stage	역할	구현
7a	야간 3모델 개별 검증	기존 유지
7b	주간 2모델 개별 검증	기존 유지
7c	Docling 품질·처리량	기존 유지
7d	K8s 모델 재검증	기존 유지
7e	주간 2모델 동시 부하	신규
7f	야간 3모델 동시 부하	신규
7g	주야간 전환 절차	신규 계획 생성
7h	모델 캐시 읽기 성능	신규 기초 측정

모델별 후보는 stage7_cluster_plan.yaml에서 관리합니다.

3. TP 자동 선택 방식

모델별 TP 후보 테스트

적재 · Context · Concurrency · TTFT/ITL

품질 / SLO / Soak / K8s 승인

검증되지 않은 후보 제외

시간대별 GPU 조합 검증

총 8GPU 이내 · GPU 중복 없음 · 동시 상주 증거

합격 후보 중 최소 GPU 구성 선택

동일 GPU 수라면 SLO 여유율 우선

예를 들어 야간에 GLM TP4, Qwen TP1, gpt-oss TP1이 모두 통과하고 동시 실행도 검증되면 6GPU 구성을 선택할 수 있습니다. 반대로 GLM TP8만 합격하면 8GPU 단일 노드의 야간 3모델 동시 운영은 승인되지 않습니다.

4. 실행 예시

먼저 후보별 테스트 계획을 확인합니다.

python3 stage7_variant_runner.py \
  --model glm_5_3 \
  --candidate nvfp4_tp4

실제 GPU 서버에서 테스트하려면 --execute를 추가합니다. 체크포인트 환경변수와 vLLM 실행 환경이 준비되어 있어야 합니다.

python3 stage7_variant_runner.py \
  --model glm_5_3 \
  --candidate nvfp4_tp4 \
  --execute

검증 Evidence가 준비된 후 야간 최종 조합을 선택합니다.

python3 stage7_profile_selector.py \
  --profile night \
  --evidence-dir evidence \
  --out selected/night.json

합격 증거가 없거나 GPU 자원이 충돌하면 자동으로 REVIEW_REQUIRED가 반환됩니다.

5. 구현 범위와 남은 작업

이번 패키지는 Stage7 테스트 및 후보 선택 체계의 실행 가능한 기반입니다. 다음 기능은 실제 인프라와 연결하는 추가 구현이 필요합니다.

DCGM/NVML 기반 Peak HBM 수집 및 합격 판정
TP 외 DP/EP, FP8/NVFP4 품질 비교 자동화
MinIO AIStor와 NVMe의 실제 Cold/Warm 모델 로딩 비교
Argo CD 또는 Kubernetes 기반 자동 전환 실행, drain, 라우팅 및 롤백
Docling 상시 서비스의 동시 부하 합격 판정 자동화

특히 Stage7g는 현재 전환 실행기가 아니라 검토 가능한 전환 계획 생성기입니다. 운영 클러스터를 임의로 변경하지 않도록 구성했습니다.

Python 문법 검사와 후보 Dry-run, 합격 증거 누락 시 차단, 전환 승인 누락 시 차단 테스트는 통과했습니다. 실제 B300 GPU와 Kubernetes에서의 성능 검증은 아직 수행하지 않았습니다.

권장 다음 순서: GLM-5.3의 FP8 TP8·TP4·NVFP4 TP4를 먼저 검증하고, 그 결과를 기준으로 야간 3모델의 GPU 배분을 확정하는 것입니다. 이후 주간 구성과 Docling 상시 운영까지 함께 검증하면 됩니다.

===

기존 Stage7 v2 패키지를 기반으로 요청하신 5개 기능을 추가하겠습니다. 기존 Stage7a~d의 검증 결과를 재사용하고, 실제 측정값과 검증 증거가 있어야만 최종 운영 프로파일을 승인하는 구조로 연결하겠습니다.

운영 조건은 그대로 유지합니다. 야간에는 GLM-5.3·Qwen·gpt-oss, 주간에는 DeepSeek Flash·GLM Flash를 운영하며, Docling은 주야간 모두 상시 실행합니다.

특히 Kubernetes 자동 전환은 GPU 8장 전체를 공유하는 환경이므로, 기존 모델 종료와 신규 모델 시작 사이에 서비스 중단 구간이 생길 수 있습니다. 따라서 전환 실행에는 사전 검증, 요청 차단·drain, GPU 해제 확인, 신규 모델 준비 확인, 라우팅 전환 및 실패 시 복구 절차를 포함하겠습니다.

요청하신 5개 영역을 추가한 Stage7 B300 Redesign v3 패키지를 만들었습니다. 기존 Stage7 스크립트를 포함한 총 46개 파일입니다.

Stage7 B300 Redesign v3

기존 Stage7 + GPU 계측 + 병렬화 검증 + AIStor + K8s 전환 + Docling 검증

전체 스크립트 ZIP 다운로드

1. 추가 구현 내역

요청 기능	주요 스크립트	구현 범위
Peak HBM	`stage7_gpu_monitor.py`	NVML GPU별 메모리 측정, Peak HBM, 여유 메모리 기준 PASS/FAIL
TP/DP/EP	`stage7_parallel_matrix.py`	후보별 vLLM 실행 및 시작 검증
FP8/NVFP4 품질	`stage7_golden_infer.py`, `stage7_quality_compare.py`	Golden 응답 수집, 정규화 텍스트 유사도 비교
AIStor/NVMe	`stage7_aistor_loading.py`	실제 S3 다운로드, NVMe 재사용, 선택적 vLLM 시작시간 비교
K8s 자동 전환	`stage7_k8s_switch.py`	Drain 대기, Deployment 전환, Readiness 확인, 라우팅 변경, 롤백 시도
Docling 동시 부하	`stage7_docling_continuity.py`	동시 요청, 성공률, P95 처리시간
통합 합격 판정	`stage7_combined_gate.py`	LLM SLO + Docling + HBM 결과 통합

2. 주요 실행 흐름

Stage7a/b — 모델별 후보 검증

TP · DP · EP · FP8/NVFP4 · HBM · 품질

Stage7d — Kubernetes 재검증

모델별 성능 · 설정 Fingerprint

Stage7e/f — 시간대별 동시 실행

LLM 간섭 · GPU HBM · Docling 상시 처리

GPU 8장 이내 합격 조합 선택

검증된 후보만 승인

Stage7g — 주야간 프로파일 전환

K8s 실행 · Readiness · 라우팅 · 복구

3. 실행 예시

GPU Peak HBM 측정

python3 stage7_gpu_monitor.py \
  --gpu-ids 0,1,2,3 \
  --duration 600 \
  --max-used-pct 90 \
  --min-free-gib 12 \
  --out results/hbm.json

TP/DP/EP 후보 검증

python3 stage7_parallel_matrix.py \
  --matrix stage7_parallel_matrix_example.yaml \
  --out results/matrix \
  --execute

AIStor 모델 다운로드 측정

python3 stage7_aistor_loading.py \
  --bucket models \
  --prefix glm53/ \
  --cache-root /local-nvme/model-cache \
  --out results/aistor.json \
  --execute

Kubernetes 주간 → 야간 전환

python3 stage7_k8s_switch.py \
  --config stage7_k8s_switch_example.yaml \
  --selected-dir selected \
  --from-profile day \
  --to-profile night \
  --out results/switch.json

기본값은 Dry-run입니다. 실제 실행에는 --apply와 Kubernetes 컨텍스트 확인 옵션이 필요합니다.

4. 실제 운영 적용 전 남은 사항

코드는 작성했지만, 실제 B300·AIStor·Kubernetes 환경에서의 통합 검증이 완료된 것은 아닙니다. 특히 다음 사항은 구분해야 합니다.

NVML: GPU별 Peak HBM 측정은 구현했습니다. DCGM Exporter 자체 배포는 포함하지 않았습니다.
DP/EP: 실행 후보 생성과 시작 검증을 구현했습니다. 전체 성능 자동 최적화까지 완료된 것은 아닙니다.
품질: FP8/NVFP4의 텍스트 유사도 비교는 구현했습니다. 추론 정확도, Tool Calling, 추론 능력 등에 대한 도메인별 품질 평가는 추가 Golden Set이 필요합니다.
AIStor: 실제 S3 다운로드와 모델 시작시간 비교를 지원합니다. OS 페이지 캐시를 제거한 엄밀한 Cold Start나 RDMA 경로 검증은 별도입니다.
K8s 전환: 실행 및 롤백 코드는 있지만, 현재는 단일 HTTPRoute/Service 구성을 전제로 한 통합 프로토타입입니다. Argo CD의 자동 동기화와 충돌하지 않도록 운영 방식에 맞춰야 합니다.
Docling: HTTP 어댑터를 통한 부하 테스트를 구현했습니다. 기존 CLI 기반 Docling 어댑터를 HTTP 서비스로 제공하는 구성은 별도 필요합니다.

Python 문법 검사와 Dry-run, Golden 비교, 증거 누락 시 승인 차단 테스트를 수행했습니다. 실제 GPU 및 클러스터 테스트는 아직 실행하지 않았습니다.

다음 단계는 실제 Kubernetes의 Deployment, Gateway/HTTPRoute, Argo CD 구성에 맞춰 Stage7g 전환기를 연결하는 것입니다. 그 과정에서 주간·야간 GPU 배분, 모델별 API 라우팅, Docling 상시 운영 및 실패 시 복구 정책을 최종 확정하면 됩니다.

===

Stage7 v3 기준으로 Kubernetes Pod를 띄워서 테스트하는 단계는 주로 Stage7d, 7e, 7f, 7g입니다.

반면 Stage7a/b는 기본적으로 GPU 노드에서 vLLM을 직접 실행하는 단독 성능 검증이며, Stage7c는 Docling 실행 환경에 따라 달라집니다.

Stage별 K8s Pod 사용 여부

Stage	검증 내용	K8s Pod 필요 여부	실행 위치
7a	야간 3모델 개별 TP/성능 검증	기본적으로 불필요	GPU 노드 직접 실행
7b	주간 2모델 개별 TP/SLO 검증	기본적으로 불필요	GPU 노드 직접 실행
7c	Docling 품질/처리량	선택적	Compute 노드 또는 K8s Pod
7d	K8s 모델 재검증	필수	GPU 클러스터의 vLLM Pod
7e	주간 2모델 동시 상주/간섭	필수 권장	GPU 클러스터의 vLLM Pod 2종
7f	야간 3모델 동시 상주/간섭	필수 권장	GPU 클러스터의 vLLM Pod 3종
7g	주야간 전환/롤백	필수	GPU 클러스터의 Deployment/Pod
7h	AIStor/NVMe 모델 로딩	선택적	GPU 노드 직접 또는 K8s Pod

여기서 7d와 7g는 실제 K8s 배포·전환 자체가 검증 대상입니다. 7e/f는 스크립트가 이미 실행 중인 모델 엔드포인트에 부하를 보내는 방식이므로, 스크립트 자체가 Pod를 생성하는 것은 아닙니다.

각 Stage에서 실제로 띄우는 Pod

Stage7d — 모델별 K8s Pod 검증

모델 하나씩 Kubernetes Deployment로 실행한 뒤, stage7d_k8s_model_revalidation.sh가 기존 엔드포인트를 대상으로 SLO를 재측정합니다. --external-server를 사용하므로 테스트 스크립트가 직접 vLLM Pod를 생성하지는 않습니다.

Stage7e — 주간 동시 운영

GPU 클러스터에 DeepSeek Flash Pod와 GLM Flash Pod를 함께 실행합니다. 별도 Compute 클러스터의 Docling Pod도 계속 동작해야 합니다.

stage7_co_residency.py로 두 LLM에 동시에 부하를 주고, Docling 연속성 검증을 병행합니다.

Stage7f — 야간 동시 운영

GPU 클러스터에 GLM-5.3, Qwen, gpt-oss Pod를 동시에 실행합니다. 각 Pod가 선택된 TP 수만큼 GPU를 점유하므로 합계가 8GPU 이하여야 합니다.

Docling Pod는 전환 없이 계속 실행됩니다.

Stage7g — Pod 전환 테스트

stage7_k8s_switch.py가 기존 Deployment를 0으로 축소하고, Pod 종료와 GPU 해제를 확인한 뒤, 다음 시간대의 Deployment를 확장하고 Readiness를 검증합니다.

실패 시 이전 구성으로 롤백을 시도합니다. 실제 전환에는 --apply와 Kubernetes Context 확인이 필요합니다.

권장 실행 순서

1. Bare-metal GPU 검증

Stage7a/b + TP/DP/EP + HBM + 품질 + AIStor

2. K8s 단일 모델 검증

Stage7d — 선택된 후보를 Pod로 실행

3. K8s 동시 운영 검증

Stage7e/f — 시간대별 여러 모델 + Docling

4. K8s 운영 전환 검증

Stage7g — 주간 ↔ 야간, 장애 복구

추가로 구분해야 할 점

GPU 측정용 Pod와 모델 서빙 Pod는 별개입니다. DCGM Exporter를 Kubernetes에 배포한다면 GPU 노드마다 모니터링 Pod가 실행되지만, 기존 Stage7의 NVML 계측 스크립트는 직접 실행할 수도 있습니다.

또한 Stage7h의 AIStor/NVMe 테스트는 초기에는 노드에서 직접 실행해도 되지만, 실제 운영 환경의 모델 캐시 볼륨, 네트워크 및 Pod 시작시간까지 검증하려면 K8s Pod 기반 재검증을 추가하는 것이 좋습니다.

결론적으로 Stage7a/b에서 후보를 좁히고, Stage7d부터는 실제 K8s Pod로 운영 가능한지를 검증하는 구조가 가장 적합합니다. 특히 Stage7e/f/g는 단순 성능 테스트가 아니라 최종 GPU 클러스터 운영 아키텍처의 합격 여부를 결정하는 단계입니다.

===

engineer

이전 포스트

26O14m

다음 포스트

26O14a

NVIDIA B300 × 8 기반 멀티모델 vLLM 서빙 구성

1. 먼저 모델 크기를 보면 배분 전략이 달라집니다

2. 권장 GPU 배분안

3. K8s 배포 구조

4. vLLM 초기 설정 예시

5. Docling은 별도로 운영하는 것이 좋습니다

6. Stage7에서 확정할 설정

최종 권장

B300 × 8 멀티모델 vLLM 주간/야간 운영 설계

1. 모델별 정밀도와 HBM 용량 계획

HBM 예산 계산

158.7 GB

86.1 GB

2. 권장 주간/야간 GPU 프로파일

주간: 경량 모델과 Flash 중심

야간: GLM-5.3 고품질 추론 중심

대안: 야간에도 소형 모델 유지

3. 모델별 vLLM 시작 파라미터

4. 공개 체크포인트 기준 HBM 추정 보정

5. Kubernetes 배포 구조

주간/야간 전환 절차

Deployment 템플릿

6. Stage7 검증 순서와 합격 기준

최종 추천 구성

1. Stage7의 7단계와 기존 script7 매핑

2. 부족할 가능성이 높은 검증 항목

3. 제가 권장하는 최종 테스트 구조

1. 기존 Stage7과 이번 7개 Step 매핑

2. Stage7에서 보완해야 할 핵심

3. 권장 Stage7 확장 구조

다음 확인 사항

기존 Stage7 Main 스크립트 분석

1. 기존 Stage7 구성

2. 앞서 제안한 7개 Step과 실제 Main 매핑

3. 파일별 확인 결과와 부족한 부분

4. 권장 보완 구조

5. 추가로 확인해야 할 파일

1. 확정된 주간/야간 모델 구성

2. 기존 Stage7의 실제 구현 수준

3. B300 8GPU에서 확인해야 할 자원 배분

10 / 8

4 / 8

4. 기존 Stage7에서 추가로 발견한 개선점

5. 최종 권장 Stage7 확장

1. B300에서 TP를 얼마나 줄일 수 있을까?

2. 야간 GPU 배분 추천

3. Stage7 변경 사항

1. 반영한 운영 구성

2. Stage7 최종 구성

3. TP 자동 선택 방식

4. 실행 예시

5. 구현 범위와 남은 작업

1. 추가 구현 내역

2. 주요 실행 흐름

3. 실행 예시

GPU Peak HBM 측정

TP/DP/EP 후보 검증

AIStor 모델 다운로드 측정

Kubernetes 주간 → 야간 전환

4. 실제 운영 적용 전 남은 사항

Stage별 K8s Pod 사용 여부

각 Stage에서 실제로 띄우는 Pod

권장 실행 순서

추가로 구분해야 할 점

26O14m

26O14b

0개의 댓글