vLLM 0.31의 제약 디코딩이 도구 호출 스키마 정확도를 100%로 끌어올린다

vLLM 0.31에 서버 플래그 형태로 들어간 제약 디코딩(constrained decoding)을 켜면 도구 호출의 스키마 준수율을 100%까지 끌어올릴 수 있다. 오픈 웨이트 모델을 에이전트 백엔드로 서빙할 때 가장 성가신 문제 중 하나인 "가끔 형식이 깨진 인자를 뱉는" 현상을 구조적으로 걷어낼 수 있게 된 셈이다.

수치로 보면 차이가 분명하다. Ubicloud가 Kimi K2.6을 vLLM 0.28로 서빙했을 때, 기대한 도구 호출 스키마를 만족한 비율은 92%였다. 25번 중 2번은 형식이 어긋난 호출이었다는 뜻이다. 최신 Kimi와 DeepSeek 모델에 제약 디코딩을 적용하면 이 수치가 100%가 된다.

도구 호출은 두 단계로 이뤄진다. 먼저 에이전트 하네스(예: OpenCode)가 사용 가능한 도구 목록을 JSON 배열로 모델에 전달한다. 각 항목에는 도구 이름과 설명, 파라미터 타입, 필수 여부 같은 스키마 정보가 담긴다. 추론 엔진은 이 JSON을 모델이 학습 단계에서 인식하도록 훈련된 특수 토큰으로 감싸 프롬프트에 넣는다. 모델이 응답을 내놓으면 서버 파서가 다시 특수 토큰을 걷어내고 JSON 객체로 복원해 하네스에 돌려준다.

문제는 모델이 컴파일러나 타입 체커가 아니라는 점이다. 다음 토큰을 확률적으로 고르는 과정에서 프롬프트가 아무리 명확해도 형식이 어긋나는 출력이 나온다. 학습 데이터와 실제 서빙 환경 사이의 미세한 불일치도 원인이 된다. 한 번 깨진 호출은 에러 메시지로 컨텍스트 윈도우를 오염시키고, 재시도 비용을 발생시키며, 멀티턴 세션이 긴 에이전트 워크로드에서 전체 품질을 갉아먹는다.

Moonshot AI는 이 문제를 측정 가능한 형태로 만들기 위해 K2VV ToolCall 벤치마크를 공개했다. 2000개의 요청으로 구성되며 두 가지 지표를 본다. 트리거 유사도는 도구 호출을 발생시켜야 할 시점을 원본 서비스와 얼마나 비슷하게 판단하는지를, 스키마 정확도는 생성된 호출 가운데 실제로 실행 가능한 비율을 나타낸다. 서빙 사업자가 자사 품질을 원본과 비교해 검증할 수 있도록 만든 장치다.

개발자 입장에서 달라지는 것은 분명하다. 그동안은 도구 호출 실패를 프롬프트 엔지니어링이나 재시도 로직으로 덮는 경우가 많았다. 제약 디코딩을 켜면 그 방어 코드의 상당 부분을 서버 설정 한 줄로 대체할 수 있다. 에이전트 파이프라인의 토큰 비용과 지연 시간이 함께 줄어드는 효과도 따라온다.

주의할 지점도 있다. 제약 디코딩은 문법적 형식을 보장할 뿐, 인자 값의 의미가 옳다는 것까지 보장하지는 않는다. 잘못된 URL이나 존재하지 않는 파라미터 값을 형식에 맞게 출력할 수 있다는 뜻이다. 또한 이 기능이 효과를 내려면 모델과 서빙 스택이 해당 방식을 지원해야 하며, 원문에서 확인된 100% 수치는 최신 Kimi·DeepSeek 모델 조합에 한정된 결과다.