2026년 Kimi K3 vLLM 시작 실패, 드라이버를 올릴까

증상: r575 호스트에서 Kimi K3 전용 cu130 이미지가 초기화 단계에서 실패합니다.
가장 빠른 해법: 유지 보수 창이 있으면 r580 이상 드라이버로 올리고, 공유 클러스터를 바꿀 수 없으면 격리된 호환 환경으로 먼저 검증을 재개합니다.

이 판단은 오류 원인이 CUDA 13과 r575의 호환성 충돌로 확인된 경우에 적용됩니다. 단순한 모델 경로, 권한, 통신 설정 오류라면 드라이버부터 바꾸면 안 됩니다.

이 글은 현재 r575 클러스터에서 Kimi K3를 올리는 인프라 엔지니어, 공유 GPU 변경 승인을 담당하는 플랫폼 책임자, Agent 연동을 빨리 재개해야 하는 개발팀을 위한 실행 순서입니다.

마지막 업데이트: 2026년 8월 5일. 데이터는 2026년 8월 3일 갱신된 공식 Kimi K3 레시피와 2026년 7월 27일 vLLM 공식 글, NVIDIA 호환성 문서를 기준으로 확인했습니다.

실패 직후의 현장 보존

Kimi K3 vLLM 시작 실패가 발생하면 먼저 컨테이너를 여러 번 다시 실행하지 마십시오. 재시도할수록 최초 오류와 후속 오류가 섞입니다.

다음 정보를 한 번에 보존합니다.

• 사용한 이미지 이름과 태그
• vLLM이 이미지에 포함된 버전인지, 직접 빌드한 버전인지
• nvidia-smi의 드라이버 버전과 브랜치
• GPU 목록과 노드 이름
• 전체 컨테이너 실행 명령
• 엔진 초기화부터 종료까지의 원본 로그
• 컨테이너 런타임, NCCL, RDMA 사용 여부
• 모델 파일 경로와 마운트 권한

공식 레시피는 현재 Kimi K3 전용 이미지가 CUDA 13, 즉 cu130 빌드만 제공한다고 명시합니다. 같은 문서에는 호스트에 r580 이상 NVIDIA 드라이버가 필요하며, CUDA 12.9 기반 r575 호스트에서는 드라이버 업그레이드나 Kimi K3 브랜치의 직접 빌드가 필요하다고 적혀 있습니다. (recipes.vllm.ai)

따라서 다음과 같은 로그가 보이면 먼저 호환성 문제를 의심합니다.

• CUDA 초기화 실패
• 드라이버가 필요한 CUDA 버전을 지원하지 않는다는 메시지
• 커널 또는 런타임 초기화 단계의 오류
• 모델 가중치를 읽기 전 프로세스 종료

반대로 모델 파일을 읽은 뒤 발생하는 메모리 부족, 잘못된 채팅 형식, 도구 호출 파서 오류는 별도 흐름으로 분리해야 합니다. cu130과 r575의 충돌을 모든 문제의 원인으로 취급하면 불필요한 드라이버 변경이 시작됩니다.

첫 번째 판정: 버전 문턱인가

Kimi K3의 cu130 이미지가 r575에서 실행되는지 묻는다면, 현재 공식 기준으로는 실행을 전제로 잡으면 안 됩니다. NVIDIA의 CUDA 호환성 표는 CUDA 13 계열에 r580 이상이 필요하다고 설명합니다. CUDA 12 계열의 기준은 r525 이상이지만, CUDA 13 이미지에 그대로 적용할 수 없습니다. (docs.nvidia.com)

먼저 아래처럼 현재 상태를 기록합니다.

nvidia-smi
docker image inspect vllm/vllm-openai:kimi-k3
docker version

이미지 내부의 CUDA 정보도 확인합니다.

docker run --rm --gpus all vllm/vllm-openai:kimi-k3 \
  bash -lc 'python - << "PY"
import torch
print(torch.version.cuda)
print(torch.cuda.is_available())
PY'

이 결과를 다음 기준으로 나눕니다.

공식 레시피는 Kimi K3에 vLLM 0.27.0 이상을 요구하고, NVIDIA 환경의 기본 권장 하드웨어로 8개의 GB300을 제시합니다. 이 수치는 모든 테스트 환경의 절대 조건이 아니라 공식 레시피의 기준입니다. (recipes.vllm.ai)

당일 복구 경로의 선택

세 경로를 모두 시도하는 방식은 빠르지 않습니다. 변경 가능한 범위와 복구 목표를 먼저 정해야 합니다.

배포 환경을 바꿀지, vLLM을 다시 빌드할지 어떻게 정합니까?

공식 cu130 이미지가 원인으로 확인되고 유지 보수 창이 있다면 드라이버 업그레이드를 우선합니다. 직접 cu129를 빌드하는 경로는 임시 우회로만 봅니다. 빌드 스크립트, PyTorch, FlashInfer, vLLM 커밋을 고정하고 재현할 수 없다면 운영 경로로 승격하지 않습니다.

공유 GPU 클러스터를 바꿀 수 없다면 원래 노드에서 계속 수정하지 마십시오. 격리된 환경에 같은 요청 형식과 같은 모델 버전을 올려 애플리케이션 검증을 먼저 진행합니다. 임시 환경에서의 검증 결과는 이후 드라이버 변경 승인 자료로도 사용할 수 있습니다.

변경 창의 준비와 회귀 차단

드라이버를 바꾸기 전에는 GPU만 확인하면 부족합니다. 다음 항목을 기준선으로 남깁니다.

• 현재 노드의 GPU 상태와 실행 중인 작업
• 컨테이너 런타임 버전과 권한 설정
• NCCL 버전과 통신 방식
• RDMA 장치와 네트워크 인터페이스
• 기존 모델의 시작과 짧은 요청 성공 여부
• 롤백할 드라이버 패키지와 커널
• 변경 대상 노드와 제외할 노드

NVIDIA 문서는 새 드라이버가 이전 CUDA로 빌드된 애플리케이션과의 하위 호환성을 제공하지만, 새 CUDA가 요구하는 최소 드라이버 조건은 별도로 충족해야 한다고 설명합니다. 따라서 “새 드라이버는 예전 모델을 깨뜨린다” 또는 “컨테이너가 알아서 해결한다”처럼 단정하면 안 됩니다. (docs.nvidia.com)

주의: 공유 클러스터에서 노드 일부만 바꾸면 드라이버 문제가 NCCL, RDMA, 노드 간 토폴로지 문제로 보일 수 있습니다. 첫 검증은 서비스 트래픽이 없는 격리 노드에서 진행하십시오.

권장 변경 순서는 다음과 같습니다.

• [ ] 기준선 로그와 작업 목록을 저장합니다.
• [ ] 서비스 트래픽이 없는 단일 노드를 선택합니다.
• [ ] 해당 플랫폼의 공식 절차로 r580 이상 드라이버를 적용합니다.
• [ ] 노드 재부팅 후 nvidia-smi와 GPU 인식 상태를 확인합니다.
• [ ] Kimi K3 컨테이너의 엔진 초기화를 먼저 확인합니다.
• [ ] 짧은 텍스트 요청과 멀티모달 요청을 각각 실행합니다.
• [ ] NCCL 또는 RDMA를 사용하는 다중 노드 테스트를 별도로 진행합니다.
• [ ] 기존 모델의 회귀 테스트가 끝난 뒤 대상 노드를 한 대씩 늘립니다.
• [ ] 실패 시 원래 드라이버와 노드 상태로 되돌리는 절차를 실행합니다.

업그레이드 전후 기준선은 GPU 테스트 환경 변경 전 점검 안내처럼 운영 문서에 남겨야 합니다. 팀 내 승인 기록이 없다면 나중에 같은 장애가 발생했을 때 원인과 변경 시점을 다시 찾기 어렵습니다.

시작 뒤의 캐시 재검증

프로세스가 시작됐다고 마이그레이션이 끝난 것은 아닙니다. vLLM 공식 실행 예시는 Kimi K3에 --enable-prefix-caching을 명시합니다. 공식 블로그도 Kimi K3의 하이브리드 캐시 구조를 설명하면서 캐시 사용을 실행 옵션과 보존 정책으로 나누어 다룹니다. (vllm.ai)

Kimi K3 서비스가 시작됐는데 prefix caching이 작동하지 않는 이유는 무엇입니까?

먼저 세 가지를 분리합니다.

1. 실행 옵션 자체가 빠졌습니다.
2. 두 요청의 공통 접두사가 실제로 같지 않습니다.
3. 캐시 보존 정책이 해당 위치의 상태를 남기지 않았습니다.

서비스를 다시 올린 뒤에는 동일한 시스템 지침, 동일한 도구 정의, 동일한 앞부분을 포함한 요청을 반복합니다. 사용자 질문만 바꾸고 접두사를 유지해야 비교가 됩니다. 요청마다 시간, 무작위 식별자, 다른 도구 목록을 앞부분에 넣으면 캐시 적중을 기대하기 어렵습니다.

다음 항목을 함께 확인합니다.

캐시가 보이지 않는다고 바로 드라이버 업그레이드 실패로 결론 내리면 안 됩니다. Kimi K3는 반복 상태와 일반 KV 캐시를 함께 다루므로, 요청 경계와 보존 정책이 결과에 영향을 줍니다. vLLM 공식 글은 프롬프트 끝 지점 보존과 선택적 보존을 구분합니다. (vllm.ai)

첫 부하에서 분리할 병목

환경을 바꾼 직후에는 부하를 한 번에 올리지 마십시오. 다음 순서로 범위를 넓힙니다.

1. 모델 적재만 확인합니다.
2. 짧은 텍스트 요청을 보냅니다.
3. 목표 컨텍스트 길이에 가까운 요청을 보냅니다.
4. 단일 동시 요청에서 여러 동시 요청으로 늘립니다.
5. 멀티모달 입력과 도구 호출을 추가합니다.
6. 마지막에 다중 노드 통신과 RDMA를 켭니다.

모델 적재 단계의 메모리 부족은 하드웨어 용량이나 모델 배치 문제입니다. 요청이 늘어난 뒤 발생하는 메모리 부족은 컨텍스트, 배치, 캐시 정책 문제일 수 있습니다. 다중 노드에서만 실패하면 NCCL, RDMA, all-to-all 백엔드를 별도로 봐야 합니다. 공식 레시피도 노드 간 통신에 사용할 백엔드와 RDMA 환경 변수를 따로 제시합니다. (recipes.vllm.ai)

이 단계에서 유지할 로그는 다음과 같습니다.

• 요청별 컨텍스트와 동시성
• GPU 메모리 사용량
• 엔진 초기화 시간
• 첫 토큰과 전체 응답 시간
• NCCL 오류와 네트워크 오류
• 도구 호출의 형식 오류
• 캐시 적중과 재사용 기록

Kimi K3는 공식 자료에서 최대 1M 토큰 컨텍스트를 지원하는 모델로 설명되지만, 이것이 모든 하드웨어와 동시성에서 그대로 운영 가능하다는 뜻은 아닙니다. 컨텍스트 목표와 실제 배치 조건을 분리해 검증해야 합니다. (recipes.vllm.ai)

관찰 기간 뒤의 장기 결정

격리 환경을 임시로 사용했다면 다음 네 가지를 비교해 결정 기록을 남깁니다.

• 같은 시작 오류가 다시 발생하는가
• 동일한 접두사에서 prefix caching이 재현되는가
• Agent의 도구 호출과 구조화 응답이 정상인가
• 새 환경의 드라이버와 의존성 유지 부담이 감당 가능한가

다음 조건이면 새 드라이버 경로를 원래 클러스터로 확대할 수 있습니다.

• 단일 격리 노드에서 엔진 초기화가 반복 성공합니다.
• 기존 모델의 회귀 테스트가 통과합니다.
• 짧은 요청과 목표 컨텍스트 요청이 모두 성공합니다.
• 다중 노드 통신 오류가 재현되지 않습니다.
• 롤백 패키지와 변경 승인 기록이 준비되어 있습니다.

반대로 공유 클러스터의 변경 승인 자체가 어렵거나, 기존 업무가 중단될 위험이 크면 격리 환경을 유지하는 편이 낫습니다. 직접 빌드한 cu129 경로는 빌드 결과를 여러 번 재현하고 의존성 보안과 업데이트를 계속 관리할 수 있을 때만 다음 단계로 올립니다.

현재 환경이 r575 공유 클러스터라면 원래 방식은 cu130 이미지와 충돌할 수 있고, 원인 분석 중 기존 작업을 건드릴 위험도 있습니다. 반면 MacHTML의 격리형 Mac 환경은 공유 GPU 드라이버를 바꾸지 않고 모델 연동과 Agent 요청을 먼저 확인하는 선택지가 될 수 있습니다. 다만 장기적인 대규모 상시 부하나 특정 물리 인터페이스가 필요한 경우에는 기존 GPU 클러스터나 자체 장비가 더 적합합니다. 임시 검증 범위와 회귀 기록을 정한 뒤 MacHTML 콘솔 사용 안내와 환경 지원 문서를 확인하는 방식이 안전합니다.

목표는 무조건 드라이버를 올리는 것이 아닙니다. 공식 호환 경로를 유지할 수 있으면 업그레이드하고, 공유 환경을 건드릴 수 없으면 격리 환경에서 검증을 계속하며, 직접 빌드는 유지 관리 책임을 감당할 때만 선택하는 것입니다.

더 읽기: Kimi K3 로컬 배치에 필요한 메모리와 장비 조건 살펴보기 맥과 가속기 서버를 나누는 대형 모델 배포 구성 점검하기 직접 배치가 어려울 때 사용할 추론 경로와 예비 공급자 구성하기