"Benchmark qwen/qwq-32b - она может и больше! Итак, новая qwen/qwq-32b на моем reasoning бенчмарке показала себя лучше, чем qwen-2.5-72b-instruct и предыдущие 32B версии от Qwen. ``` ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━┓ ┃ Model ┃ Score ┃ ┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━┩ │ openai/o3-mini-2025-01-31 │ 76% │ │ anthropic/claude-3.7-sonne… │ 70% │ │ openai/o1-2024-12-17 │ 70% │ │ deepseek/deepseek-r1 │ 66% │ │ deepseek/deepseek-r1-disti… │ 60% │ │ .... │ │ │ >> qwen/qwq-32b << │ 40% │ │ qwen/qwen-2.5-72b-instruct │ 39% │ │ qwen/qwen2.5-32b-instruct │ 36% │ │ qwen/qwen-2.5-coder-32b-in… │ 36% │ ``` Это уже очень хорошо. Но есть нюанс - эта модель может больше, если бы ей не мешал разброд и шатание с интерфейсами вокруг reasoning моделей. Смотрите, для простоты бенчмарка, я преимущественно тестирую модели через OpenRouter через интерфейс OpenAI SDK. Этот подход работает прекрасно для обычных моделей. Можно даже использовать Fireworks провайдера, который поддерживает нормальный Structured Output. В теории - подаем промпт в OpenAI SDK вместе с ожидаемой схемой и получаем ответ в виде объекта. OpenRouter передаст все в Fireworks и вернет ответ. На практике же все взрывается с ошибкой `Error: 'NoneType' object is not iterable` в глубине OpenAI SDK. А все почему? Да провайдеры не могут договориться и определиться, как нужно получать у модели reasoning, а как результаты вычислений. Более того, они просто не знают, чего ожидать от своей модели. В итоге, когда я просил reasoning модель подумать и ответить в виде схемы (и отправлял схему), причем в схеме уже было место для Chain of Thought, то qwen/qwq-32b просто выдавала свои размышления с ответом в `think`, а сам `response` оставляла пустым. Прослойка в виде OpenRouter/Fireworks такого не ожидала. В итоге мне приходил такой ответ: ``` { ""choices"": [ { ""finish_reason"": ""stop"", ""index"": 0, ""logprobs"": null, ""message"": { ""content"": """", ""reasoning"": ""{ \""chain_of_thought\"": [ \""To determine how many ..."", ""refusal"": null, ""role"": ""assistant"" }, ""native_finish_reason"": ""stop"" } ], ``` Ну а текущая OpenAI SDK не знает про поле `reasoning`, она ждет `content` по схеме. Пришлось переписывать клиента, чтобы автоматически разрешать такие проблемы. А почему я говорю, что модель могла бы и лучше? Да потому, что в паре простых вопросов мне приходил ответ, где внезапно reasoning текстом, а content - это не StructuredOutput, а markdown. То есть тут поведение не только нестабильное, но и constrained decoding не пахнет. ``` { ""choices"": [ { ""finish_reason"": ""stop"", ""index"": 0, ""logprobs"": null, ""message"": { ""content"": ""```json\n{\n \""short_thought_steps...```"", ""reasoning"": ""Okay, let me figure..."", ""refusal"": null, ""role"": ""assistant"" }, ""native_finish_reason"": ""stop"" } ], ``` Возможно новый стандарт ResponseAPI от OpenAI позволит исправить этот бардак и задать нормальный стандарт работы с reasoning моделями и SO. Но это займет какое-то время. А пока можно только порадоваться за qwen/qwq-32b, которая подняла планку качества 32B моделей невзирая на путаницу в интерфейсах. Ваш, @llm_under_hood 🤗 PS: А вот как эта модель правильно отработала задачку про код (закидав проблему токенами). Sonnet 3.5 и 3.7 (без thinking) именно с этой задачкой не справился: Chain of thought."