Пользователь сообщил о проблемах с Qwen3.6‑27B в vLLM по сравнению с llama.cpp

Пользователь сообщества r/LocalLLaMA (Reddit) рассказал о различиях в работе модели Qwen3.6‑27B при запуске через llama.cpp и vLLM. По его словам, система с двумя GPU RTX 5060Ti и суммарными 32GB VRAM ранее использовала llama.cpp, который «отлично работает» при одном пользователе, но при одновременной работе двух человек возникают проблемы: кэш одного пользователя часто инвалидируется, когда второй отправляет запрос.

Чтобы улучшить многопользовательскую работу, автор попробовал перейти на vLLM. Он запустил контейнер vllm/vllm-openai:v0.23.0 и использовал модель cyankiwi/Qwen3.6-27B-AWQ-INT4, отмечая, что по размеру весов она примерно сопоставима с Qwen3.6-27B-UD-Q5_K_XL.gguf, применявшейся ранее в llama.cpp. Конфигурация включала параметры вроде --max-model-len 100000, --max-num-seqs 4, kv-cache-dtype fp8, gpu-memory-utilization 0.79 и speculative-config с методом mtp и num_speculative_tokens 3.

Однако, по его наблюдениям, в vLLM модель вела себя значительно хуже: в ряде случаев она была «практически лоботомизирована». Аналогичные проблемы возникали и при использовании QuantTrio/Qwen3.6-27B-AWQ, sakamakismile/Qwen3.6-27B-Text-NVFP4-MTP и Lorbus/Qwen3.6-27B-int4-AutoRound. Модель часто допускала ошибки при tool‑вызовах, могла зависать, а при использовании стандартного Pi без расширений tool calls оказывались сломанными как минимум в 60% случаев уже с первого сообщения в диалоге.

В итоге автор создал собственный Python‑парсер, который перехватывает типичные ошибки модели. Среди наиболее частых, пропуск угловых скобок и нарушения синтаксиса, например когда вместо конструкции <function=edit><parameter=content> модель генерирует <parameter=edit>. По его словам, такие исправления помогли частично стабилизировать работу системы.