#vllm
vllm 태그가 붙은 글 10편. · 전체 태그 보기
- 따로 잰 건 같이 잰 게 아니다, 그리고 가동률 3% 띵킹을 오프라인 세트로 재고 효과 없음이라 결론 냈다가 다단계 세트에서 역전. 그 사이 측정한 적 없는 조합이 프로덕션에 들어갔다. max_tokens 상한은 예산이 아니라 차단기였고, 넉 달 튜닝한 장비의 가동률은 3%였다
- 채점기가 모델보다 자주 틀렸다 자는 동안 800회 넘게 검증을 돌리고 아침에 실패 목록을 보니 8건 이상이 측정 도구 결함이었다. 도구를 고치고 나서 남은 진짜 결함으로 설정 실험 1,000회. 넘은 것 셋, 벽 넷
- 장비를 처음부터 다시 재기로 했다 sm_121이라는 고아 번호, 6:0으로 이기던 SGLang이 투기 디코딩을 켜자 뒤집힌 표, 공개 벤치 1등이 자체 라벨 데이터에서 진 결과. DGX Spark를 칩·엔진·모델 세 층에서 다시 잰 하루
- 게이트웨이를 지우고 배선을 고쳤다 이틀 전에 세운 게이트웨이가 요리 질문에까지 증시 개장일을 붙이고 있었다. 4월에 제지당한 패턴을 그대로 반복했고, 지우고 나니 채팅 품질 문제의 대부분은 모델이 아니라 조용히 무시되는 설정이었다
- 나눗셈 한 번으로 모델 후보 절반을 걸렀다 DGX Spark의 메모리 대역폭을 실측하니 231GB/s. 활성 파라미터로 나누면 디코드 상한이 나오고, dense 모델은 계산만으로 전부 탈락했다
- 커뮤니티 말을 믿고 디코드를 절반으로 깎았다 "투기 디코딩과 멀티모달은 양립 불가"를 믿고 MTP를 껐더니 42.8t/s가 19.4t/s로 떨어졌다. 소스를 읽으니 경고만 하고 진행하는 코드였고, 그 사이 다른 함정이 하나 더 켜져 있었다
- "6주"를 0.06으로 읽은 로컬 LLM 자동매매 봇의 데일리 LLM 역할을 자가호스팅 모델로 옮기다 만난 오독 버그를 DB 원문 재현과 A/B 실측으로 잡은 기록
- 혼자면 나쁘고 둘이면 좋은 설정 chunked prefill만 줄이면 꼬리 지연이 오히려 나빠지고, priority 스케줄링과 함께 쓰면 최악 TTFT가 51.8초에서 2.0초로 내려갔다. 커뮤니티 권고 네 가지를 실측으로 기각한 밤
- 돌아온 첫 시간에 로그 2.5개월치를 날렸다 두 달 만에 연 DGX Spark 세션에서 "로그 확인해줘"가 컨테이너 재생성으로 이어져 334MB가 사라졌다. 살아남은 건 다른 시스템이 우연히 보고 있던 14일치
- 프로젝트마다 모델을 띄우다가, LLM 서버를 하나로 합쳤다 DGX Spark 한 대에 vLLM 서버를 세우고, 프로젝트마다 모델을 띄우는 대신 하나로 분리해 첫날 모니터링까지 붙인 기록