vLLM 0.31 제한 디코딩으로 Kimi·DeepSeek 도구 호출 스키마 정확도 100% 확보
- vLLM 0.31에 제한 디코딩(constrained decoding)이 들어가면서 최신 Kimi와 DeepSeek 모델의 도구 호출 스키마 정확도를 100%로 맞출 수 있게 됨. Ubicloud는 그전까지 100% 정확도를 맞추려고 자체 vLLM 포크를 유지했음.
- 도구 호출이 부정확하면 모델이 말이 안 되는 컨텍스트를 쌓아 올려 이후 출력 품질이 무너짐.
- Moonshot AI는 Kimi를 서빙할 때 제한 디코딩을 기본으로 켜라고 권고하고 실제로 그렇게 서빙함. OpenAI의 최신 Responses API도 기본 활성화 상태임.
- 제한 디코딩은 모델이 뱉는 토큰 분포를 바꾸므로 품질에 영향을 줄 수 있음. 이번 글은 1차 제공자와 동작이 얼마나 비슷한지에 초점을 맞췄고 품질 비교 수치는 내지 않았음.
Hacker News 의견들
글 쓴 사람인데, LLM이랑 서빙 엔진, 제한 디코딩 구현을 맞물리게 짜서 원하는 출력과 품질을 뽑아내는 데는 테스트를 꽤 많이 돌려야 했음. 궁금한 거 있으면 물어봐.
<||> 문법은 대체 어디서 나온 거야? 기존 마크업 두고 저걸 쓴 이유도 그렇고, 검색해도 자료가 거의 없던데.
그러니까 도구 호출을 실제로 하는 건 모델이 아니라 엔진이 유효한 토큰만 남기게 걸러주는 거네. 샘플러 쪽을 건드려서 출력을 조종하는 방식이면 가중치는 그대로 둬도 통제가 되겠는데.
DFlash나 MTP 같은 추론 최적화랑 같이 써도 되나? 느려지는 게 심하면 그냥 재시도하는 편이 나을 수도 있을 것 같은데.
transformers.js에도 지난달에 제한 디코딩 들어갔음. 브라우저에서 구조화 출력 뽑는 용도고 도구 호출에도 씀.
문법 규칙만 주면 코드 문법에 맞는 출력도 강제할 수 있지. llama.cpp에 문법 제약 디코딩 설명이 잘 돼 있고, 나도 text-to-SQL로 SQL 생성 실험을 돌려봤음.
근데 코드 문법 오류가 실제로 그렇게 자주 나오나? Codex나 Claude Code 같은 걸로 쓰면서 그런 걸 겪어본 적이 별로 없는데.
vLLM에서 이 기능 작업했는데, 제한 디코딩은 AR 모델을 /v1/systemone 엔드포인트로 바꿀 때 쓰는 방식이랑 같음. 도구가 실행 중간에 추가되는 경우도 있어서 업계가 아직 OpenAI 형식으로 통일되지도 않았고.
실행 중간에 도구를 추가한다고? 모델이 컨텍스트 어디에 도구가 있든 크게 상관하진 않을 텐데, 그게 실제로 되나.
잘못된 도구 호출이랑 에러 메시지를 컨텍스트에서 걷어내는 건 어떤가 싶었는데, KV 캐시를 다시 만들어야 해서 손해가 있고, 드물게 일어나면 감당할 만할지도.
Qwen 3.8에서도 되나?
Qwen 3.8도 vLLM에서 제한 디코딩이 될 거임. 다만 문법은 보장해도 품질은 따로 봐야 함. Kimi는 제작사가 켜라고 권고하지만 Qwen은 그런 얘기가 없음.
품질 영향 수치를 안 냈다는 게 아쉬움. 제한 디코딩은 출력 분포를 바꾸니까, 실패하면 되돌아가 재시도하는 방식이랑 비교해보고 싶음. 글에 나온 23/25 성공률이면 재시도에 토큰 9% 더 쓰는 정도라.
재시도 방식이 분포를 똑같이 재조정하는 건가? 토큰 단위로 막는 것보다 도구 호출 전체를 다시 하는 게 나을 수도 있겠다는 생각도 들고, 모델이 처음에 잘못 골라서 상태를 망치면 복구를 못 하니까.
품질 쪽은 다음 글에서 다룰 수도 있음. 이번엔 1차 제공자랑 동작이 얼마나 비슷한지에 초점을 맞췄고, Moonshot은 Kimi를 제한 디코딩 켜서 서빙하며 OpenAI Responses API도 기본으로 켜져 있음. 제한 디코딩이 품질을 떨어뜨린다는 연구도 있는데 모델마다 다름.
이런 거 진짜 반가움. 프롬프트당 도구 호출 300번씩 돌리는 작업이 있어서 2024년부터 OpenAI, Anthropic에 묶여 있었음. 그 둘의 해자 중 하나가 제한 디코딩으로 100% 도구 호출 정확도 맞춘 것이랑 프롬프트 캐싱임.
llama.cpp는 이거 진작부터 했음. vLLM 쓰면서 이 기능이 없다는 게 신기했는데 이제 들어갔네.