AI 인프라
모델 서빙, GPU, 추론 엔진
- EXAONE 4.5 MTP 수용률을 뜯어보았다
앞 글에서 합성 프롬프트 탓으로 본 EXAONE 4.5 33B의 MTP 수용률 0%를 다시 추적했습니다. vLLM 구현과 실행 설정을 하나씩 배제해 보니, 수용률을 가른 변수는 추론(thinking) 모드 여부였고 원인은 MTP 헤드 가중치였습니다. 본체가 직접 생성한 응답으로 헤드만 다시 학습해, 비추론 응답을 MTP 없이 돌릴 때보다 1.67배 빠르게 만들었습니다. 추론 모드 속도는 원래 MTP와 같은 수준을 유지했습니다.
- SSD로 스트리밍하는 MoE는 왜 느렸을까: 8GB Jetson Orin Nano 2부
1부에서 메모리의 2.7배인 Qwen3.6-35B-A3B를 SSD 스트리밍으로 돌렸을 때 decode가 3 tok/s 안팎에 머문 데는 두 가지 병목이 있었습니다. 첫째, CPU가 expert를 계산하는 동안 GPU가 쉬는 탓에 governor가 GPU를 최저 클럭(306 MHz)에 묶어 두었습니다. 둘째, expert 가중치를 page fault로 읽는 동안 계산 스레드가 멈춰 SSD를 동시 I/O 1~2개로만 쓰고 있었습니다. 2부에서는 두 병목을 GPU 클럭 하한과 사용자 공간 expert 캐시로 풀어 가는 과정과, 이 방법이 통하지 않는 조건을 정리했습니다.
- 8GB Jetson Orin Nano에서 메모리보다 큰 MoE를 SSD로 스트리밍하기
8GB급 엣지 기기에서 메모리보다 큰 모델을 돌리는 방법으로 SSD 스트리밍이 주목받고 있다. Jetson Orin Nano Super에서 메모리의 2.7배인 Qwen3.6-35B-A3B를 llama.cpp mmap 스트리밍으로 돌려 보며, 이 방식이 실제로 어디까지 쓸 만하고 속도가 어디서 막히는지 확인했다.
- Qwen3.8-Flash-Next 홈랩 실증 Part I: NVFP4 체크포인트 속의 BF16과 통합 메모리
NVFP4 표기 체크포인트를 GB10 두 대에 올리다 시스템이 34분간 멎었다. 바이트의 약 58%가 BF16 PLE였다. PLE를 FP8로 바꾸고 128개 파일로 나눠 TP=2로 기동한 과정과 최적화 전 기준 성능을 기록한다.
- 추측 디코딩과 배칭: RTX 3090 2장에서 동시 요청 수가 바꾼 최적 설정
30B급 모델 3종을 vLLM으로 서빙하며 추측 디코딩, KV 캐시 정밀도, NVLink를 동시 요청 1~32에서 측정했다. 추측 디코딩의 이득은 모델과 동시성에 따라 부호가 바뀌었고, 원인 가설과 검증하지 못한 범위를 구분해 정리했다.
- LLM 벤치마크의 간헐적 지연: 원인 분석과 측정 규약
반복 측정, 로그 대조, CPU 이동 실험으로 decode 지연을 분석했다. 관측 결과와 인과 추론의 한계를 구분하고, 아키텍처 비교에 사용할 측정 규약과 진단 종료 기준을 정했다.