RKLLMで動くQwen3.5の速度と回答の質

8GBのKiwiPi 5でQwen3.5-0.8Bを動かした公開テストでは、RKLLMによる生成速度は短い入力で毎秒15.01トークンでした。Qwen3.5-2Bは同じ条件で毎秒8.57トークン。

どちらも、Rockchip RK3588Sに内蔵されたNPUを使った結果です。

測定条件やインストール手順は、KiwiPiが公開したRKLLMの実測レポートにまとまっています。ここで気になったのは、小さなモデルで何ができて、どこから確認が必要になるのか、という点です。

小型ボードで動かすためのソフトウェア

RKLLMは、RockchipのNPUで言語モデルを実行するためのソフトウェアです。Rockchip公式SDKでは、モデルを変換・量子化するToolkitと、ボード上で推論を実行するRuntimeが分かれています。

今回参照したテストでは、Ubuntu 24.04.3 LTS、Linux 6.1.141、RKNPUドライバー0.9.8、RKLLM Runtime 1.3.1が使われました。ボードにはヒートシンクとファンを装着し、GNOMEデスクトップとKiwiDropを起動したまま測定しています。

専用の最小構成に絞った環境ではありません。

モデルはQengineeringが公開した変換済みのW8A8形式です。2B版のファイルや対象ハードウェアは、Qwen3.5-2Bの配布ページで確認できます。

元の重みをこの実験で変換したわけではなく、画像用エンコーダーも使っていません。

この区別は、手元で試す場合にも必要です。GGUFファイルや一般的なモデルの重みを、そのまま今回の実行コマンドに渡すことはできません。

試すモデルの形式と、Runtimeの組み合わせを先に確認する必要があります。

毎秒15トークンでも待ち時間は変わる

短い入力では、0.8Bモデルが最初の文字列を返すまでに0.35秒、2Bモデルは0.52秒かかりました。モデルの読み込み時間を除き、推論の呼び出しから最初の空でないテキストが届くまでを測った値です。

入力を746トークンに増やすと、この時間はそれぞれ4.44秒、5.18秒になります。一方、生成速度は0.8Bが毎秒14.52トークン、2Bが毎秒8.25トークンでした。

2つのモデルの測定結果

測定項目	0.8B	2B
生成速度（短い入力）	15.01 tok/s	8.57 tok/s
最初の文字列（短い入力）	0.35秒	0.52秒
生成速度（746トークン入力）	14.52 tok/s	8.25 tok/s
最初の文字列（746トークン入力）	4.44秒	5.18秒
プロセスのピークメモリ	約1153MB	約2235MB

短い入力は39トークン。速度と初回応答時間は各3回の中央値です。メモリ値はRuntimeが報告したプロセス単位のピークで、ボード全体の使用量ではありません。

生成が始まってからの速さだけを見ると、差は小さく見えます。それでも、利用者は文字が出るまで数秒待ちます。

毎回長い資料を添えて質問する使い方では、こちらの待ち時間も確認したいところです。

これらは各条件で3回測った中央値です。コンテキスト容量は2048、新しく生成するトークン数の上限は128。

各リクエストの前にKVキャッシュを消去し、会話履歴も引き継いでいません。長い会話を続けた場合の速度とは条件が異なります。

メモリも、モデルのファイルサイズだけでは判断できません。主な速度測定で報告されたプロセスのピークメモリは、0.8Bが約1153MB、2Bが約2235MBでした。

これはRuntimeが報告したプロセス単位の値で、NPU専用のVRAM容量やボード全体の使用量ではありません。

JSONは返せても説明は間違える

短い処理で確認できたこと

回答の確認では、両モデルとも指定されたキーと値を持つJSONを返しました。3つの数値の最大値を返す短いPython関数も生成し、4通りの限られた確認では正しく動いています。

ただし、この結果だけで「プログラミングに使える」と広げるのは早いでしょう。試した関数は単純で、テストケースも少数です。

小さく条件を絞った処理が動いた、という範囲で読むのが妥当です。

説明文と出力上限の注意点

説明文には、はっきりした誤りもありました。0.8Bは機器が自分の経験から学習するかのように説明し、2Bは処理のオフロードが遅延や過熱を防ぐと述べています。

この実験はモデルの学習を行っておらず、温度や遅延についても、そのような一般化を裏付けていません。

一方、RAM容量とプロセッサーだけを示して筐体の色を尋ねた課題では、どちらも色を作り上げませんでした。与えた情報から答えられない場合に、その限界を示した例です。

算数の課題では、2Bが正しい数の組み合わせを導いたものの、最後の文が出力上限で途切れました。0.8Bは答えに到達する前に終了しています。

この課題の上限は192トークンでした。途中で切れた回答と、十分な長さを与えても誤答するケースは、分けて扱う必要があります。

まず自分の短い課題で確かめる

最終シリーズの58リクエストは、推論エラーなしで完了しました。各モデルで10回続けた別の測定でも生成は継続しています。

ただし、これは短い試験であり、長期間の連続運用を保証する結果ではありません。

最高のサンプル温度はSoCで61.9℃でした。ファン付きの構成で、室温と消費電力は測っていません。

CPUだけで同じモデルを動かした比較もないため、NPUで何倍速くなったか、省電力になったかは、この結果からはわかりません。

試すなら、まず短い指示と、正解を確認できる小さな課題から始めるのがよさそうです。JSONなら必要なキーと値を検証し、説明文なら事実を照合する。

大きいモデルに替える前に、実際に使う入力で何が失敗するかを確かめるほうが、次に必要な変更を決めやすくなります。