#로컬llm
로컬llm 태그가 붙은 글 14편. · 전체 태그 보기
- 프롬프트로는 안 됐고, 단계를 나누니 됐다 요약이 얇은 걸 프롬프트로 고치려다 더 나빠졌다. 수치 추출과 문장 작성을 분리하니 재현율 18%p, 실재율 2.6%p가 같이 올랐다
- 입력을 3분의 1로 줄여보니, 고쳤다고 믿었던 게 둘로 갈렸다 2단 처리가 수치 정확도와 누락을 같이 고쳤다. 짧은 입력으로 다시 재보니 하나는 길이 문제였고 하나는 구조 문제였다
- 네 모델을 200건으로 재고 나서, 내가 재지 않은 것이 결론을 뒤집었다 수치 충실도로는 후보가 이겼다. 그런데 한국어 띄어쓰기가 200건 전부 깨져 있었다
- 따로 잰 건 같이 잰 게 아니다, 그리고 가동률 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로 떨어졌다. 소스를 읽으니 경고만 하고 진행하는 코드였고, 그 사이 다른 함정이 하나 더 켜져 있었다
- 혼자면 나쁘고 둘이면 좋은 설정 chunked prefill만 줄이면 꼬리 지연이 오히려 나빠지고, priority 스케줄링과 함께 쓰면 최악 TTFT가 51.8초에서 2.0초로 내려갔다. 커뮤니티 권고 네 가지를 실측으로 기각한 밤
- 돌아온 첫 시간에 로그 2.5개월치를 날렸다 두 달 만에 연 DGX Spark 세션에서 "로그 확인해줘"가 컨테이너 재생성으로 이어져 334MB가 사라졌다. 살아남은 건 다른 시스템이 우연히 보고 있던 14일치
- 프롬프트를 줄여 55% 빨라졌는데, 정작 중요한 게 사라졌다 −55%를 만든 압축이 정작 도메인의 핵심을 버리고 있었다. 안 재던 지표가 무너진 이야기
- 파인튜닝 5일이 프롬프트 108자에 졌다 Gemma 4 26B-A4B에 LoRA로 5일을 썼는데 튜닝 안 한 것과 별로 다르지 않았다. 같은 과제를 프롬프트 압축으로 다시 붙여본 결과
- 프로젝트마다 모델을 띄우다가, LLM 서버를 하나로 합쳤다 DGX Spark 한 대에 vLLM 서버를 세우고, 프로젝트마다 모델을 띄우는 대신 하나로 분리해 첫날 모니터링까지 붙인 기록