つまりQwenの語彙には<think>と</think>それぞれに対応する個別のトークンがあります。これは、私が書いたあるアプリが、CoTを選択的に止めるために<|im_start|>assistantの後でこれらのトークンをキャッシュにプッシュしていたことから分かります。すごい。
昨日、いくつかのコーディング用ハーネスをいじっていて、llama-server上で動いているqwen 3.6 A3Bを使っていたのですが、うまくいくことが多かったです。とはいえ、いくつかのケースでは、CoTを単一トークン</think>で終える代わりに、CoTブロックの末尾に複数トークン列の</thinking>をプッシュしていました。言うまでもなく、これだとCoTブロックの終了が検出されず、ハーネスが混乱しました。
もちろんこれはサンプラー/KVキャッシュのレベルで簡単に修正できるでしょう。でも、そうなるとllama-serverをハックするか、私自身でopenai completions APIを実装することになります。私はそれをやる気にはあまりなりません。で、投稿している理由は2つあります：
これってたぶん量子化が原因だったのでは？ その時私は、unquantised cache と recurrent state（つまり、llama-serverへの -ctk/ctv 引数なし）で、iq4_nl のunsloth量子化を使っていました。参考までに、これは任意の n_past の位置で起きていて、16k/128kあたりのかなり低いところでも発生しました。
みなさんの中で同じようなことを見た人はいますか？ ハーネス側では、APIの失敗として現れます（たとえば「モデルがプロンプトへの出力を返さなかった」みたいなもの）あるいはそれに類する症状です。
[link] [comments]
