폐쇄망 GPU 서버 로컬 LLM 구축·운영

고객사 사내망(외부 인터넷이 막힌 고객 사내 네트워크) 개발서버(V100 32GB × 2)에 드라이버·컨테이너 런타임·추론 서버를 반입 파일만으로 세우고 로컬 LLM 추론 서버로 운영했다. 사용률을 관리해야 하는 운영 조건에 맞춘 유휴 부하·사용률 대시보드와 런타임 보안 패치까지 다뤘다. 서버는 운영 중이지만 본편 부하 서비스는 정지 상태이고, 후속 패치는 현장 적용 전이다.

• 인터넷이 없어 드라이버·도커·Container Toolkit·CUDA 런타임을 전부 반입 파일로 설치해야 했다.
• 최신 CUDA·서빙 프레임워크 조합이 Volta(sm70) 세대를 조용히 뺄 수 있었다.
• 평균 사용률을 관리해야 해서, 쓰지 않는 시간에도 사용률을 유지하고 증빙해야 했다.
• 보안 수정판이 나와도 런타임 교체를 파일 반입과 재시작으로만 할 수 있었고, 같은 서버의 대시보드·부하 서비스가 그 런타임 위에서 돌았다.

설치 스크립트·패치 묶음·따라하기·결과서 초안은 AI 에이전트(Claude Code 실행·Codex 검증)가 만들었다. 아래는 본인 행동 기록이 있는 것이다.

• 서버 직접 작업: 2026.08 드라이버·컨테이너 런타임·툴킷·간이 부하·CUDA 추론 배포를 서버에서 직접 실행하고 결과를 사진 판독으로 기록했다. 2026.10에는 상태 점검·추가 서비스 설치·런타임 보안 패치 적용을 직접 실행했다.
• 결정: 사용률 운용 목표를 확정했고, 대시보드 전체를 GPU 서버 한 대에 두기로 했다. 후보 모델(Qwen3.8) 배포 방식 8건을 정했고, 이후 그 반입 묶음을 지우기로 결정했다.
• 문서: 서버 사용 기간 연장을 요청하는 문서 초안을 썼다.

1. 런타임은 GPU 세대가 먼저 정한다 — V100(sm70)은 일부 서빙 프레임워크의 커널이 없거나 지원이 제한돼, llama.cpp CUDA로 26B q4_0 모델을 2장에 layer split으로 나눠 올렸다(문맥 65,536·병렬 2). 설치 단계마다 「무엇이 보이면 통과인지」를 미리 적은 판독 게이트로 확인했다.
2. 기준이 평균 사용률이면 유휴 부하로 유지한다 — 100% 부하로 기준을 잡은 뒤 실행·휴지 비율로 목표 범위에 맞추고, 그 값을 실측으로 확인했다. 이어 앱 트래픽과 중재하는 본편 부하를 설계했고, 실서버에 적용됐다.
3. 대시보드는 먼저 GPU 서버 한 대에 — 앱 서버가 발급되기 전에 대시보드를 운영해야 해서 수집·관측·화면을 GPU 서버에 모았고, 나중에 화면만 옮길 수 있게 코드 변경 없이 설정만 바꾸는 구조로 했다(본인 결정).
4. 런타임 교체는 「대상만 정지 · 현재 판 확인 · 자동 복구」 묶음으로 — 교체 절차에 현재 버전 확인과 자동 복구를 보강했다. 대상 서비스만 잠시 멈추고, 켜져 있던 서비스만 다시 켜고, 일정 시간 지켜본 뒤 실패하면 스스로 되돌린다. 후속 패치는 사전 연습까지 확인했으며 현장 적용 기록은 없다.

• 준비(2026.08): 서버 사양과 사용률 기준이 정리됐고, 드라이버를 패키지 대신 .run으로 직접 설치하는 방안이 검토됐다.
• 설치(2026.08, 이틀): 파일 3개(276MB)를 한 번에 반입해 기반 확인 → 드라이버 → 도커·툴킷 → 컨테이너 안 GPU 실증 → 간이 부하 → llama.cpp CUDA 배포 → 판독 게이트 순으로 진행했다.
• 운영 확장(2026.09): 대시보드 배치 결정 → 대시보드·본편 부하 실서버 적용 → 후보 모델 배포 계획 → 사용기간 연장 요청 초안.
• 10월 운영: 상태 점검 → 추가 서비스 설치 → 런타임 보안 패치 적용 → 후속 패치 준비(연습 환경에서 교체·되돌리기·고장 상황 연습 통과).

• 생성 속도 85.9 tok/s(26B q4_0, 2장 layer split), 슬라이드 판독 정답 확인(실측).
• 반입 파일 3개·276MB로 설치 5단계를 이틀에 완료(2026.08).
• 상태 점검(2026.10)에서 두 GPU에 모델이 나뉘어 적재돼 있고 추론 서버가 정상 응답함을 확인했다(실측).
• 사용자 효과는 근거가 없다.

• 유휴 시간을 포함한 평균 사용률을 유지했다는 증빙은 아직 정리되지 않았다.
• 런타임 교체 절차의 보강분(현재 판 확인·자동 복구)은 아직 연습 환경에서만 동작이 확인됐다.
• 대시보드 파생 지표를 실제 nvidia-smi 값으로 검증하지 않았다.
• 후보 모델(Qwen3.8)은 서버에서 시험하지 않았다 — 반입 묶음을 지웠고, 기대 속도는 다른 환경 수치에서 환산한 값뿐이다.

• OS·GPU: Rocky Linux 9, V100 SXM2 32GB × 2(NVLink, compute 7.0), NVIDIA 드라이버(.run 직접 설치)
• 컨테이너: Docker·compose, NVIDIA Container Toolkit(CDI)
• 추론: llama.cpp(CUDA), Gemma 4 26B q4_0 + mmproj, --split-mode layer
• 운영: 간이 부하 스크립트(실행·휴지 비율 조정), systemd 서비스, Next.js 대시보드, bash 교체·되돌리기 스크립트(해시·문법 검사·자동 복구)

• 도구가 한 일: Claude Code가 설치 스크립트·패치 묶음·「따라하기 → 결과」 문서 쌍·결과서 초안을 만들고, Codex가 검증했다. 패치 묶음은 연습 호스트에서 교체·되돌리기·고장 상황을 돌린 뒤 파일 하나로 반입하는 형태가 됐다.
• 본인이 한 일: 서버 앞에서 명령을 실행하고 결과를 사진·로그 판독으로 남겼다. 사용률 목표·대시보드 배치·모델 배포를 결정했다.
• 절차로 남긴 것: 이 서버 작업은 「서버 실측 → GPU 세대 확인 → 사용률 기준 확인 → 메모리 계산 → 단계별 판독 게이트 → 속도 실측 → 유휴 부하 → 구간 평균 관측 → 인계 문서 2종」 순서의 절차서로 정리됐다.