<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>VLLM on PGX Lab — local AI 클러스터 기록</title><link>https://pgxlab.github.io/pgx-blog/tags/vllm/</link><description>Recent content in VLLM on PGX Lab — local AI 클러스터 기록</description><generator>Hugo</generator><language>ko-kr</language><lastBuildDate>Tue, 29 Sep 2026 13:00:00 +0900</lastBuildDate><atom:link href="https://pgxlab.github.io/pgx-blog/tags/vllm/index.xml" rel="self" type="application/rss+xml"/><item><title>4노드 전체 정지·전원 복구 연습 — 돌아가는 동안엔 안 보이던 것들</title><link>https://pgxlab.github.io/pgx-blog/posts/2026-09-29-full-poweroff-drill/</link><pubDate>Tue, 29 Sep 2026 13:00:00 +0900</pubDate><guid>https://pgxlab.github.io/pgx-blog/posts/2026-09-29-full-poweroff-drill/</guid><description>정전에 대비해 GB10 4대를 스크립트로 순차 정지하고, IoT 플러그로 전원을 다시 넣어 자동 부팅→서빙 복구까지 해 봤다. 정지 2분, 서빙 복구 약 16분. 서빙은 멀쩡히 돌아왔지만 4대 중 3대는 부팅이 끝나지 않은 상태였다 — 그래픽 부팅 스플래시가 한 시간 넘게 멈춰 있었고, 그 뒤에 걸린 클럭 설정 유닛들이 노드마다 다르게 실행됐다. CPU 캡은 10분마다 다시 쓰이고 있었지만 실제로는 아무 효과가 없었다.</description></item><item><title>GLM-5.3-Flash 4노드 TP 벤치마크 — 처리량·정확도, 그리고 '생성 없는 결정'</title><link>https://pgxlab.github.io/pgx-blog/posts/2026-09-18-glm53-benchmark/</link><pubDate>Fri, 18 Sep 2026 12:00:00 +0900</pubDate><guid>https://pgxlab.github.io/pgx-blog/posts/2026-09-18-glm53-benchmark/</guid><description>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만 읽어 결정을 내리는 &amp;lsquo;jevlike&amp;rsquo; 실험 — TypeSafe Jev의 독립 벤치와 같은 데이터셋에서 비교했다.</description></item><item><title>GPU 캡은 필수, CPU 캡은 함정 — GB10 클러스터 열·전력 캠페인</title><link>https://pgxlab.github.io/pgx-blog/posts/2026-09-13-thermal-campaign/</link><pubDate>Sun, 13 Sep 2026 17:30:00 +0900</pubDate><guid>https://pgxlab.github.io/pgx-blog/posts/2026-09-13-thermal-campaign/</guid><description>node1의 GPU 클럭 캡이 조용히 풀려 SoC가 93℃까지 올랐다. 원인을 잡은 김에 uncapped / GPU 캡 / GPU+CPU 캡 세 조건을 동시성 32와 단일스트림 두 구간에서 측정했다. 결론: GPU 캡은 무손실로 전력 45%를 깎는 필수 레버, CPU 캡은 어느 구간에서도 속도만 잃는 함정이었다.</description></item><item><title>정정: DGX Spark의 FP4는 네이티브다 — 그리고 그걸 켜도 빨라지지 않았다</title><link>https://pgxlab.github.io/pgx-blog/posts/2026-09-05-gb10-fp4-native-moe-backend/</link><pubDate>Sat, 05 Sep 2026 16:20:00 +0900</pubDate><guid>https://pgxlab.github.io/pgx-blog/posts/2026-09-05-gb10-fp4-native-moe-backend/</guid><description>앞 글에서 GB10의 NVFP4를 &amp;lsquo;에뮬레이션&amp;rsquo;이라고 쓴 것은 틀렸다. 하드웨어도 빌드도 FP4를 지원하고, marlin은 레시피의 선택이었다. 그래서 FP4 텐서코어 경로로 바꿔 재봤더니 전 구간 같거나 느렸다. 왜 그런지, 그리고 flashinfer 경로는 왜 부팅조차 못 했는지.</description></item><item><title>6이라는 숫자가 병목이었다 — GB10 클러스터 동시성 실험과 RTX PRO 6000 벤치마크 비교</title><link>https://pgxlab.github.io/pgx-blog/posts/2026-09-05-concurrency-vs-rtx-pro-6000/</link><pubDate>Sat, 05 Sep 2026 13:49:00 +0900</pubDate><guid>https://pgxlab.github.io/pgx-blog/posts/2026-09-05-concurrency-vs-rtx-pro-6000/</guid><description>같은 모델·같은 TP=4로 5,718 tok/s를 찍은 트윗을 보고 우리 클러스터의 max-num-seqs를 6에서 64로 올려 실험했다. 합산 처리량 90→305 tok/s. 남은 20배 차이는 설정이 아니라 하드웨어다.</description></item><item><title>개복치 소생술 — 다섯 번 죽은 추론 서버에 자동 재기동을 달다</title><link>https://pgxlab.github.io/pgx-blog/posts/2026-09-05-mola-mola-resuscitation/</link><pubDate>Sat, 05 Sep 2026 12:46:52 +0900</pubDate><guid>https://pgxlab.github.io/pgx-blog/posts/2026-09-05-mola-mola-resuscitation/</guid><description>사인이 매번 다른 크래시를 더는 쫓지 않기로 했다. 대신 죽어 있는 시간을 없앴다. 워치독을 만들고, 배포 직후 그 워치독 때문에 더 망가지고, 고쳐서 첫 자동 소생을 보기까지.</description></item><item><title>GPU를 사이에 둔 두 AI의 정전 협정</title><link>https://pgxlab.github.io/pgx-blog/posts/2026-09-05-two-agents-gpu-truce/</link><pubDate>Sat, 05 Sep 2026 07:59:58 +0900</pubDate><guid>https://pgxlab.github.io/pgx-blog/posts/2026-09-05-two-agents-gpu-truce/</guid><description>추론 서버를 세 번 죽인 범인은 커널 버그가 아니라 같은 GPU를 탐낸 두 번째 프로그램이었다. 그리고 그 두 번째 프로그램은 또 다른 AI 에이전트였다.</description></item><item><title>18시간 뒤의 침묵 — DeepGEMM JIT 커널 크래시 추적기</title><link>https://pgxlab.github.io/pgx-blog/posts/2026-09-04-deepgemm-jit-crash/</link><pubDate>Fri, 04 Sep 2026 16:35:26 +0900</pubDate><guid>https://pgxlab.github.io/pgx-blog/posts/2026-09-04-deepgemm-jit-crash/</guid><description>정상 종료 코드로 죽은 추론 서버, TileLang 대체 경로로의 우회, 그리고 &amp;lsquo;조용한 모니터링 장애&amp;rsquo;까지 — 4노드 클러스터 장애 하나를 끝까지 따라간 기록</description></item><item><title>DGX Spark 4노드 TP=4 GLM-5.3-Flash 서빙 — 기술 런북</title><link>https://pgxlab.github.io/pgx-blog/posts/2026-09-01-dgx-spark-tp4-runbook/</link><pubDate>Tue, 01 Sep 2026 09:30:00 +0900</pubDate><guid>https://pgxlab.github.io/pgx-blog/posts/2026-09-01-dgx-spark-tp4-runbook/</guid><description>MikroTik CRS804 브레이크아웃 설정, CX-7 인터페이스 매핑, NCCL/vLLM 파라미터, 실측 성능과 단계별 소요시간</description></item></channel></rss>