[GPU] TKE/TI-ONE 연동과 운영/장애 대응 체크리스트

개요

이전 글에서 GPU 구성별 처리시간과 완성 1편당 비용을 실측했습니다. 이번 글은 그렇게 검증한 배포를 실제 운영 체계로 편입하는 단계를 다룹니다. CVD 한 대를 손으로 붙잡고 있는 상태에서 벗어나, Kubernetes 기반 클러스터(TKE)나 학습/추론 작업 스케줄러(TI-ONE)에 자원으로 등록하는 절차와, 그 전에 반드시 짚어야 하는 학습(training) 범위 구분, 그리고 서비스를 공개하기 전 점검해야 할 장애 대응 체크리스트를 정리합니다.

CVD는 어디까지나 실행 자원입니다. TKE와 TI-ONE은 그 자원을 관리하고 작업을 배치하는 계층이고, 이 계층에 연결한다고 해서 GPU가 추가로 생기는 것은 아닙니다. 등록 전에 기존 워크로드, 런타임, 드라이버 변경이 미치는 영향부터 검토해야 합니다.

TKE와 TI-ONE, 어느 쪽에 등록할 것인가

두 관리 계층은 목적이 다릅니다.

선택	적합한 목적	연결 형태
TKE	Kubernetes 배포, GPU Pod, 기존 클러스터 운영	CVD를 등록 노드로 편입
TI-ONE	학습/추론 작업과 자원 그룹 관리	외부 서버 형태로 CVD 등록

중요한 건 GPU 자원 관리 주체를 하나로 고정해야 한다는 점입니다. 기존 systemd/Docker 기반 모델 서비스(앞선 글들에서 다룬 DeepSeek의 systemd, GLM의 Docker, SGLang 서비스)와 클러스터 스케줄러가 같은 GPU를 동시에 쓰면 충돌합니다. TKE와 TI-ONE 양쪽에 같은 GPU를 독립적으로 할당하는 구성도 피해야 합니다.

TKE 등록 노드로 편입하기

등록 흐름은 네 단계입니다.

OS/망 정합: CVD와 클러스터 설정을 일치시킵니다.
등록 노드 풀: 등록 기능과 연결 방식을 선택합니다.
초기화: 해당 클러스터 전용 스크립트를 실행합니다.
GPU 검증: Ready 상태와 nvidia.com/gpu 자원 노출을 확인합니다.

CVD 운영체제 준비

지원되는 조합은 [G6] TencentOS Server 3.1 64-bit 또는 [G6] Ubuntu Server 22.04 LTS 64-bit입니다. TencentOS 이미지나 등록 기능 자체가 보이지 않는다면 계정의 제공 조건부터 확인해야 합니다.

TKE 쪽 운영체제 선택은 CVD와 반드시 맞춰야 합니다. 같은 Linux 계열이라는 이유로 Ubuntu와 TencentOS를 섞어 등록하지 않습니다.

네트워크와 노드 풀 설정

같은 VPC 또는 라우팅 가능한 사설망으로 구성하고, 관리 엔드포인트/이미지 저장소/노드 간 필요한 통신을 확인합니다. 클러스터의 등록 노드 기능에서 사설 연결 유형을 선택하고 등록 노드 기반의 노드 풀을 생성합니다. 일반 CVM 신규 노드나 서버리스 노드와는 구분되는 경로입니다.

GPU 노드 초기화 화면에서 사설망 다운로드 경로를 선택하면, 클러스터별 주소/노드 풀 ID/토큰이 포함된 초기화 명령이 발급됩니다.

초기화 스크립트 실행과 등록 확인

bash

# 콘솔에서 발급한 다운로드 명령을 CVD에서 실행한 뒤,
# 아래 파일명을 실제 생성된 이름으로 바꿉니다.
./add2tkectl-CLUSTER_ID-NODEPOOL_ID check
./add2tkectl-CLUSTER_ID-NODEPOOL_ID install

파일명은 자리표시자입니다. 공통 토큰이나 다른 클러스터의 등록 명령을 재사용해서는 안 됩니다. root 권한이 필요하며, 명령의 다운로드 대상과 스크립트 내용을 확인한 뒤 해당 노드에만 실행해야 합니다. 기존 클러스터에 속했던 노드는 kubelet 상태/iptables/CNI 설정이 남아있을 수 있으므로, 기존 업무를 백업하고 신규 노드로 준비하는 편이 안전합니다. 초기화나 재설치는 데이터 삭제 가능성을 검토한 뒤 진행합니다.

등록 후에는 노드 Ready 상태뿐 아니라 실제 GPU 자원 노출까지 확인해야 합니다.

bash

kubectl get nodes -o wide
kubectl get pods -A -o wide
kubectl get node CVD_NODE_NAME -o jsonpath='{.status.allocatable.nvidia\.com/gpu}'
kubectl describe node CVD_NODE_NAME

CVD_NODE_NAME은 실제 노드 이름으로 바꿉니다. Ready인데 GPU 자원이 비어 있다면 드라이버/컨테이너 런타임/device plugin을 의심해야 합니다. nvidia-device-plugin, CNI, kube-proxy, 모니터링 에이전트가 정상인지 확인하고, GPU limit을 요청하는 작은 검증 Pod로 실제 디바이스 접근까지 점검하는 게 안전합니다. Pod를 조회할 수 있는 RBAC 권한이 있어야 이 확인 자체가 가능하다는 점도 미리 챙겨야 합니다.

TI-ONE 외부 자원 그룹으로 연결하기

TI-ONE 쪽은 CVD를 외부 서버로 등록하는 방식입니다.

외부 서버 등록 기능 확인: 해당 계정에서 외부 서버 기반 자원 그룹을 생성할 수 있는지 먼저 확인합니다.
자원 그룹 생성: 플랫폼 관리 → 자원 그룹 관리에서 그룹을 만들고 서버 출처를 외부 서버로 선택합니다.
VPC와 서브넷 설정: CVD의 SSH 및 필요한 관리 통신에 도달할 수 있는 네트워크를 선택합니다. OS 배포판 이름만이 아니라 커널/드라이버/런타임 지원 조건도 함께 확인합니다.
노드 추가: GPU 유형(NVIDIA), CVD IP, 실제 SSH 포트, Linux 로그인 사용자와 인증정보를 입력합니다. 전용 관리 계정과 필요한 권한만 사용합니다.
자원 확인: 등록 후 노드 상태, GPU 종류/수/메모리가 예상과 같은지 확인합니다. 작업 공간, 자원 할당과 스케줄링 정책을 설정하고 작은 작업부터 실행합니다.

스케줄링 정책은 자원 그룹 단위 JSON으로 지정합니다.

json

{
  "Version": "1.0",
  "ResourceRule": {
    "DefaultPriority": 0,
    "DefaultQueue": 0,
    "Preempted": 1
  },
  "TaskRules":
}

이건 정책 형식의 예시일 뿐입니다. 우선순위/대기열/선점 값이 실제 제품에서 어떤 의미이고 업무에 어떤 영향을 주는지 확인하고 적용해야 합니다. 특히 실행 중인 학습이나 장시간 걸리는 생성 작업이 선점될 수 있는 정책인지는 반드시 사전에 확인해야 할 항목입니다.

이 시리즈는 추론이지 학습이 아닙니다

지금까지 이 시리즈에서 다룬 DeepSeek/GLM 배포, MiniMax H3 영상 생성, SGLang 최적화는 전부 가중치를 불러와 결과를 만드는 **추론(inference)**입니다. H3의 Turbo LoRA 적용 명령도 학습 명령이 아니라 이미 학습된 가속 가중치를 불러오는 것뿐입니다. 학습은 완전히 다른 자원 요구사항을 가진 별도 범위입니다.

작업	변경되는 것	추가로 필요한 준비
추론	가중치는 유지하고 결과 생성	모델/추론 엔진/요청 처리
LoRA / QLoRA 미세조정	일부 어댑터 파라미터 학습	학습 데이터, 정답 형식, 학습 코드, 평가 세트
전체 미세조정	기존 모델의 많은 또는 모든 가중치 학습	옵티마이저 상태/gradient/activation 메모리
프롬스크래치 학습	초기 가중치부터 모델 학습	대규모 데이터/연산/분산 학습/긴 검증 과정

추론에 겨우 들어가는 모델이 같은 장비에서 전체 학습까지 되는 건 아닙니다. 학습에는 가중치 외에도 gradient, optimizer state, activation을 위한 메모리가 추가로 필요하기 때문입니다. CVD에서 미세조정 작업을 실행할 수 있는지, 특정 모델이 특정 GPU 구성에서 학습 가능한지는 이 시리즈와는 별도로 검증해야 합니다.

사용 사례	검토할 도구	먼저 볼 병목
7B–13B 계열 LoRA / QLoRA	LLaMA-Factory, Transformers, DeepSpeed	시퀀스 길이/배치/양자화 지원/activation
이미지 LoRA / DreamBooth / ControlNet	Diffusers, Kohya 계열 학습 도구	해상도/이미지 수/캐시/GPU 메모리
멀티모달/영상 미세조정	해당 모델의 학습 구현	프레임 수/공간 텐서/입력 디코딩/체크포인트
분산 학습	DDP / FSDP / ZeRO / pipeline	GPU 간 통신/호스트 RAM/저장소 대역폭

학습 환경은 추론 환경과 분리하는 게 원칙입니다. 별도의 이미지나 인스턴스로 준비하고, 데이터 라이선스/모델 라이선스/재현 가능한 버전/checkpoint 보관을 먼저 설계해야 합니다. 검증 순서도 정해져 있습니다. 작업과 데이터 형식을 정하고 재배포/학습 권한을 확인한 뒤, 평가용 데이터를 분리해서 소량으로 전처리와 데이터 로더를 검증합니다. 모델이 지원하는 GPU 아키텍처와 학습 정밀도 조합을 확인하고, 단일 GPU/작은 배치로 forward/backward, optimizer step, checkpoint 저장/복구를 검증한 다음에야 GPU 수를 늘려 처리량과 통신 시간을 측정합니다. NVLink가 없는 구성에서는 통신 비중이 큰 학습이 기대만큼 잘 늘어나지 않을 수 있습니다. 품질/비용/실패 복구까지 만족한 설정만 자원 그룹이나 클러스터 작업으로 운영해야 합니다.

운영 및 장애 대응

GPU 사용률 하나만으로 서비스 정상 여부를 판단하지 않습니다. 접속/모델 준비/대기열/후처리/파일 보관을 나누어 확인해야 합니다. 지금까지 실측 과정에서 실제로 마주쳤던(또는 마주칠 수 있는) 증상과 대응은 다음과 같습니다.

증상	먼저 확인	다음 조치
SSH 연결 불가	NAT EIP, DNAT 포트, 라우팅, 허용 CIDR, sshd	콘솔 접속 후 호스트 RAM과 잠금 메모리 확인
CLI command not found	모델 전용 이미지 여부, PATH	선택한 이미지의 초기화 상태 확인
API 연결 거부	명령 실행 위치, SSH 터널, 실제 listen 포트	`ss -ltnp`, 올바른 서비스 관리자 확인
서비스가 계속 준비 중	cold load와 JIT 로그 진행 여부	디스크 속도/메모리/worker 종료/포트 충돌 분석
GLM 설정 변경이 반영 안 됨	`docker inspect`의 기존 Args	restart가 아니라 설정을 보관한 뒤 재생성
LLM 최종 답이 null	`finish_reason=length`, 추론 토큰 사용	출력 예산 증가 또는 추론 강도 조정
LoRA가 빨라지지 않음	applied to 로그, `num_inference_steps`	가중치 형식/실제 병합 모드/요청 단계 확인
2 GPU가 예상보다 느림	VAE offload와 text_encoder 옵션	CPU↔GPU 전송, 동시 실행 부하 측정
단일 GPU 시작 OOM	FP8 전환 전 BF16 로딩 피크	단일 GPU용 CPU offload 구성 유지
ping은 되지만 SSH 불가	mlock과 호스트 메모리 고갈	콘솔에서 상태 확인. 재부팅 전 작업 영향/로그 확보
400 / 409 발생	`error.code`와 원하는 모드, ready	입력 오류는 수정, 모델 로딩은 대기
GPU는 한가한데 running	MPS 후처리/대기열/의존 서비스	Agent 상태와 외부 후처리 실패 여부 확인
MP4 다운로드가 안 됨	completed 여부, 만료, 리다이렉트	`curl -L`, 로컬 파일 유실/CDN 만료 확인

읽기 전용 진단 명령

호스트와 서비스 상태를 건드리지 않고 확인할 수 있는 명령들입니다.

bash

nvidia-smi
free -h
df -h
ss -ltnp
systemctl status deepseek-v4-flash
journalctl -u deepseek-v4-flash -n 100 --no-pager
docker ps -a
docker logs --tail 100 glm53-flash
sudo docker -H unix:///run/docker-sglang.sock ps -a
h3-use status
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8000/health
curl -sS http://127.0.0.1:7002/healthz
curl -sS http://127.0.0.1:7002/v1/partition

설치된 모델에 해당하는 명령만 실행해야 합니다. 없는 서비스에 대한 오류는 이 CVD가 해당 이미지가 아니라는 의미일 수 있습니다. 진단 로그에는 프롬프트/파일 경로/인증정보가 포함될 수 있으므로, 공유하기 전 민감한 내용을 반드시 제거해야 합니다.

서비스 공개 전 점검

모델 이미지, 가중치, Docker digest와 실행 인수를 기록했다.
GPU 수/VRAM/디스크 여유를 실제 인스턴스에서 확인했다.
최대 길이/해상도/동시성에서 메모리 피크와 p95 지연을 측정했다.
API 인증/TLS/접근 출처/요청 크기/속도 제한을 설정했다.
외부 URL 입력에 SSRF 방어, 다운로드 크기/시간 제한을 적용했다.
영상 생성 POST의 중복 접수를 피하고 작업 ID를 보관한다.
실패/취소/제한시간 초과/429/503을 처리한다.
모델 전환/컨테이너 재생성 전에 진행 작업을 정리한다.
결과 만료 전 보관하고 실제 MP4의 해상도/길이/재생을 검사한다.
인스턴스 외에 NAT/저장/전송/MPS 비용을 포함해 계산했다.
TKE 또는 TI-ONE과 기존 서비스가 같은 GPU를 이중 점유하지 않는다.
중단/복구/백업/버전 롤백 절차를 준비했다.

모델이 한 번 응답하는 것으로 운영 준비가 끝나는 게 아닙니다. 반복 요청이 쌓이고, 입력 파일이 잘못 들어오고, 후처리가 늦어지고, 서버가 다시 시작되어도 비용과 상태를 설명할 수 있어야 서비스로 운영할 수 있는 상태입니다.

정리

CVD는 실행 자원이고, TKE와 TI-ONE은 그 자원을 관리/배치하는 계층입니다. 연결한다고 GPU가 추가로 생기지 않으며, 기존 systemd/Docker 서비스와 클러스터 스케줄러가 같은 GPU를 동시에 점유하지 않도록 자원 관리 주체를 하나로 정해야 합니다.
TKE 등록은 OS/망 정합 → 등록 노드 풀 생성 → 클러스터 전용 초기화 스크립트 실행 → Ready와 nvidia.com/gpu 노출 확인 순서로 진행합니다. 등록 명령은 자리표시자이며 공통 토큰이나 다른 클러스터 명령을 재사용하지 않습니다.
TI-ONE은 CVD를 외부 서버로 등록하는 방식이며, 스케줄링 정책의 우선순위/대기열/선점 값이 실행 중인 작업에 미치는 영향을 반드시 사전에 확인해야 합니다.
이 시리즈에서 다룬 모든 배포는 추론이며, 학습(LoRA/QLoRA, 전체 미세조정, 분산 학습)은 gradient/optimizer state/activation을 위한 별도 메모리와 별도 검증 절차가 필요한 다른 범위입니다.
서비스 공개 전에는 GPU 사용률 하나가 아니라 접속/모델 준비/대기열/후처리/파일 보관을 나눠서 점검해야 하고, 이 글의 진단 명령과 체크리스트가 그 기준이 됩니다.

이 시리즈는 CVD GPU 워크스페이스 구축(1편)에서 시작해, DeepSeek과 GLM 자체 배포(2편, 3편), MiniMax H3 영상 생성과 ComfyUI 워크플로(4편), SGLang 추론 최적화(5편), Agent API와 클라이언트 구현(6편), 성능/비용 실측(7편)을 거쳐 이번 클러스터 연동과 운영 체크리스트로 마무리됩니다.

[GPU] TKE/TI-ONE 연동과 운영/장애 대응 체크리스트 ​

개요 ​

TKE와 TI-ONE, 어느 쪽에 등록할 것인가 ​

TKE 등록 노드로 편입하기 ​

CVD 운영체제 준비 ​

네트워크와 노드 풀 설정 ​

초기화 스크립트 실행과 등록 확인 ​

TI-ONE 외부 자원 그룹으로 연결하기 ​

이 시리즈는 추론이지 학습이 아닙니다 ​

운영 및 장애 대응 ​

읽기 전용 진단 명령 ​

서비스 공개 전 점검 ​

정리 ​

[GPU] TKE/TI-ONE 연동과 운영/장애 대응 체크리스트

개요

TKE와 TI-ONE, 어느 쪽에 등록할 것인가

TKE 등록 노드로 편입하기

CVD 운영체제 준비

네트워크와 노드 풀 설정

초기화 스크립트 실행과 등록 확인

TI-ONE 외부 자원 그룹으로 연결하기

이 시리즈는 추론이지 학습이 아닙니다

운영 및 장애 대응

읽기 전용 진단 명령

서비스 공개 전 점검

정리