로컬 LLM에서 겪은 가장 짜증 나는 '조용한 실패'는 무엇이었나
원문 제목 — What are the most frustrating silent failures you've encountered with local LLMs?
📄 전문 번역
필자는 애플리케이션과 로컬 LLM 서버(Ollama부터 시작) 사이에서 로그만 보여주는 것이 아니라 조용한 추론 실패를 진단하는 소규모 오픈소스 도구를 만들고 있다. 다루는 대상은 컨텍스트 한도, 빈 출력, 추론 예산 문제, 잘못 설정된 컨텍스트 윈도우 같은 것들이다.
더 만들기 전에 사람들이 실제로 겪는 문제를 파악하고 싶다. 예컨대 필자에게 일주일을 뺏은 사례는 이것이다. Ollama는 컨텍스트 윈도우에 맞지 않는 프롬프트를 잘라내면서도 여전히 200을 반환한다. 경고도 없고, 앞쪽부터 잘라내므로 시스템 프롬프트가 가장 먼저 사라진다. 응답의 prompt_eval_count가 모델이 실제로 읽은 토큰 수를 알려주는데 아무도 그것을 확인하지 않는다.
같은 부류의 다른 사례를 겪었는지, 그리고 이 프로젝트에 대한 생각이 궁금하다. GitHub 링크도 공유할 수 있다.
💬 주요 댓글 번역 (3)
🔍 루키 분석
로컬 LLM의 '조용한 실패'를 진단하는 도구를 개발하며 커뮤니티 사례를 수집하는 글이다. 대표 사례로 Ollama가 컨텍스트를 넘는 프롬프트를 앞에서부터 잘라 시스템 프롬프트를 몰래 잃게 하면서도 성공 응답을 반환하는 문제와, OLLAMA_NUM_PARALLEL이 병렬 슬롯별 KV 캐시로 실제 컨텍스트를 자동 축소하는 문제가 소개됐다. 에러 없이 조용히 진행되는 실패는 디버깅 비용이 크다는 점에서 실사용자의 공감을 얻고 있다.
— 루키 · glm-5.3-flash:cloud
물으신 것과 맞는지 모르겠지만 나의 최대 불만은 모델이 요청한 출력 파라미터를 확인했다면서 지키지 않는 것이다. '1인칭 시점과 현재 시제를 엄수하겠습니다'라는 응답을 받고도 바로 다음 줄에서 어기는 일을 아주 자주 봤다.
내 도구가 볼 수 있는 것과 없는 것을 더 정확히 말해야겠다는 생각이 들어 덧붙인다. 시점·시제 드리프트는 출력을 실제로 읽고 판단해야 하는 문제고, 내 도구는 숫자만 읽으므로 그 케이스는 범위 밖이다. 잴 수 있는 버전, 즉 JSON 스키마 위반 같은 것은 잡아낼 수 있다.
필자를 일주일 잡아먹은 문제는 그것의 친척뻘이다. OLLAMA_NUM_PARALLEL이 실제 컨텍스트 양을 조용히 바꿔 버린다. RAM이 되면 Ollama가 스스로 1보다 큰 값을 고르고, 각 병렬 슬롯은 자기 KV 캐시를 따로 쓰므로 요청한 컨텍스트 양과 슬롯 하나가 받는 양은 같은 숫자가 아니다.