Qwen3+ streaming parser, LocalLLaMA가 반긴 작은 vLLM 수정
Original: vLLM has a new streaming parser for Qwen3+ available in nightly View original →
로컬 LLM에서 작은 parser 수정이 크게 보이는 순간이 있다. r/LocalLLaMA에 올라온 vLLM nightly의 Qwen3+ streaming parser 소식은 그런 사례다. 게시자는 Qwen3.6-27B가 중간에 멈추거나 streaming tool call이 chunk boundary에서 실패하던 문제를 새 parser가 고친 것으로 보인다고 전했다.
이 문제는 모델 점수표보다 실제 agent workflow에서 더 크게 느껴진다. Qwen 계열을 vLLM으로 서빙하고 OpenAI 호환 API를 통해 도구 호출을 흘려보낼 때, streaming 응답이 잘게 나뉘면서 tool call markup이나 reasoning 구간이 parser 기대와 어긋날 수 있다. 사용자는 모델이 답을 못 하는 것이 아니라, 호출 형식이 깨져 agent loop가 멈추는 상황을 겪는다.
댓글 반응도 바로 이 지점을 짚었다. 한 사용자는 Qwen3.6-27B를 agent loop에서 돌릴 때 chunk boundary tool call 실패를 계속 맞았고, client-side buffering을 넣거나 streaming을 끄는 식으로 우회했다고 설명했다. 다른 댓글은 babysitting이 줄어드는 변화라며 반겼고, 일부는 llama.cpp 쪽에서도 비슷한 증상을 봤는지 물었다.
nightly build라는 점은 중요하다. 아직 안정 릴리스의 보증이라기보다, 실사용자들이 빠르게 검증할 수 있는 수정에 가깝다. 그래도 Qwen3.6 같은 로컬 모델을 coding agent로 쓰는 사람에게 parser는 주변부가 아니다. 도구 호출이 한 번 깨지면 모델 성능과 관계없이 작업이 중단된다.
이번 논의는 로컬 모델 생태계의 병목이 모델 가중치만이 아니라는 점을 보여준다. inference server, chat template, reasoning parser, tool-call parser, streaming transport가 모두 맞물려야 agent가 오래 돈다. Qwen3+ parser 개선이 관심을 받은 이유도 여기에 있다. 사용자는 더 큰 모델보다, 이미 가진 모델이 긴 작업에서 덜 끊기길 원한다.
Related Articles
HN의 관심은 “로컬 LLM이 프런티어 모델을 대체했나”보다 “어떤 작업부터 로컬로 내려올 수 있나”에 모였다. Gemma 4와 Qwen 계열을 둘러싼 체감 성능, 비용, 프라이버시 논의가 한꺼번에 붙었다.
r/LocalLLaMA의 100점대 thread는 local tool calling 실패담을 model 탓으로 끝내지 않고, OpenWebUI·quant·runtime 조합 문제로 쪼개 봤다.
LocalLLaMA가 이 글에 반응한 이유는 홍보 문구가 아니라 숫자였다. RTX 5060 Ti 16GB 두 장으로 Qwen3.6 27B를 약 60 tok/s, 204k 컨텍스트까지 밀어본 실측값이 나왔다.