정전에 대비해 GB10 4대를 스크립트로 순차 정지하고, IoT 플러그로 전원을 다시 넣어 자동 부팅→서빙 복구까지 해 봤다. 정지 2분, 서빙 복구 약 16분. 서빙은 멀쩡히 돌아왔지만 4대 중 3대는 부팅이 끝나지 않은 상태였다 — 그래픽 부팅 스플래시가 한 시간 넘게 멈춰 있었고, 그 뒤에 걸린 클럭 설정 유닛들이 노드마다 다르게 실행됐다. CPU 캡은 10분마다 다시 쓰이고 있었지만 실제로는 아무 효과가 없었다.
GB10 4대 TP=4로 서빙 중인 GLM-5.3-Flash NVFP4를 밤새 재 봤다. 한국어 실프롬프트 처리량 sweep, 드래프터 k=7→3 비교, lm-eval 9종(MMLU 87.9 / KMMLU 64.5 / KorMedMCQA 85.4 / GSM8K 94.5 / HumanEval 75.0), 그리고 첫 토큰 logit만 읽어 결정을 내리는 ‘jevlike’ 실험 — TypeSafe Jev의 독립 벤치와 같은 데이터셋에서 비교했다.
node1의 GPU 클럭 캡이 조용히 풀려 SoC가 93℃까지 올랐다. 원인을 잡은 김에 uncapped / GPU 캡 / GPU+CPU 캡 세 조건을 동시성 32와 단일스트림 두 구간에서 측정했다. 결론: GPU 캡은 무손실로 전력 45%를 깎는 필수 레버, CPU 캡은 어느 구간에서도 속도만 잃는 함정이었다.
앞 글에서 GB10의 NVFP4를 ‘에뮬레이션’이라고 쓴 것은 틀렸다. 하드웨어도 빌드도 FP4를 지원하고, marlin은 레시피의 선택이었다. 그래서 FP4 텐서코어 경로로 바꿔 재봤더니 전 구간 같거나 느렸다. 왜 그런지, 그리고 flashinfer 경로는 왜 부팅조차 못 했는지.
같은 모델·같은 TP=4로 5,718 tok/s를 찍은 트윗을 보고 우리 클러스터의 max-num-seqs를 6에서 64로 올려 실험했다. 합산 처리량 90→305 tok/s. 남은 20배 차이는 설정이 아니라 하드웨어다.
사인이 매번 다른 크래시를 더는 쫓지 않기로 했다. 대신 죽어 있는 시간을 없앴다. 워치독을 만들고, 배포 직후 그 워치독 때문에 더 망가지고, 고쳐서 첫 자동 소생을 보기까지.
추론 서버를 세 번 죽인 범인은 커널 버그가 아니라 같은 GPU를 탐낸 두 번째 프로그램이었다. 그리고 그 두 번째 프로그램은 또 다른 AI 에이전트였다.
정상 종료 코드로 죽은 추론 서버, TileLang 대체 경로로의 우회, 그리고 ‘조용한 모니터링 장애’까지 — 4노드 클러스터 장애 하나를 끝까지 따라간 기록
MikroTik CRS804 브레이크아웃 설정, CX-7 인터페이스 매핑, NCCL/vLLM 파라미터, 실측 성능과 단계별 소요시간
DGX Spark 4대를 200G 네트워크로 묶어 320B 모델(GLM-5.3-Flash)을 서빙하기까지, 용어 사전과 함께 쉽게 풀어 쓴 기록