先日、Qwythos-9B-Claude-Mythos-5-1MをVRAM 6GB環境で動かし、Q4 / Q5 / Q6の起動、VRAM使用量、速度、日本語文章作成、コード相談、HTMLゲーム生成まで確認しました。
今回はその追加検証として、Q4_K_Mを使い、8K / 16K / 32K context設定で長文を読ませたときにどうなるかを確認します。
元記事はこちらです。
今回確認したこと
見るポイントは、通常の会話や短いコード相談ではなく、長い入力を読ませるときの挙動です。
- 8K / 16K / 32K context設定で完走するか
- 長文内に埋めた合言葉を取得できるか
- prefill、つまり入力を読む速度はどれくらいか
- 回答生成速度はどれくらい落ちるか
- VRAM使用量は6GB内に収まるか
検証には、Qwythos-9B-Claude-Mythos-5-1MのQ4_K_Mを使いました。llama.cpp CLIでctxを8K、16K、32Kに変え、長文の中に合言葉を埋め込み、最後にその合言葉を答えさせています。
8K / 16K / 32Kの結果
| context設定 | Prompt速度 | Generation速度 | VRAM使用量（観測値） | 合言葉取得 | 実行結果 |
|---|---|---|---|---|---|
| 8K | 131.0 t/s | 5.6 t/s | 約4064MiB | 成功 | 完走 |
| 16K | 122.0 t/s | 4.0 t/s | 約4816MiB | 成功 | 完走 |
| 32K | 115.6 t/s | 3.0 t/s | 約4464MiB | 成功 | 完走 |
8K、16K、32Kのいずれも完走し、長文内に埋めた合言葉を取得できました。
prompt処理速度は、8Kの131.0 t/sから32Kの115.6 t/sまで低下しました。ただ、contextを伸ばした割には大きく崩れていません。
一方で、generation速度は8Kの5.6 t/sから32Kの3.0 t/sまで落ちました。長文を読ませたあとの回答生成は、通常の短い質問より重くなります。
VRAM使用量はnvidia-smiで観測した値です。16Kの観測値が32Kより高く出ていますが、これは取得タイミングやllama.cpp側のメモリ確保、OS側の状態によるばらつきも含む値として見ています。今回の環境では、少なくともQ4_K_Mで32K context設定を試すこと自体は可能でした。
今回おもしろかったのは、contextを伸ばしてもprompt処理速度は比較的保たれた一方で、generation速度は段階的に落ちたことです。長文を読む処理そのものより、読ませたあとの回答生成で重さが見えやすい結果になりました。
プロンプト規模と実行条件
| context設定 | LineCount | 行数 | words | characters | ctx | GPU使用率 |
|---|---|---|---|---|---|---|
| 8K | 120 | 122 | 4696 | 31187 | 8192 | 平均約70.7%、最大99% |
| 16K | 240 | 242 | 9376 | 62388 | 16384 | 平均約84.5%、最大99% |
| 32K | 480 | 482 | 18736 | 124788 | 32768 | 平均約88.6%、最大100% |
32K context設定でも合言葉は取得できた
32Kでは、長文内に埋めたBLUE-32K-PREFILL-NOTEを取得できました。
32K用のプロンプトは、482行、18,736 words、124,788 charactersのテキストです。厳密な32K tokens詰め切りではありませんが、短文ではなく、かなり長い入力を読ませた確認にはなっています。
パスフレーズは「BLUE-32K-PREFILL-NOTE」です。これは、長文脈から特定の事実を正確に抽出できるか検証するためのテスト文として挿入されました。
この結果だけで「長文理解が完璧」とは言えませんが、少なくとも今回のように、長い入力の中から特定の情報を取り出すテストは通りました。
16Kでは生成速度が4.0 t/sまで低下
16Kでは、Prompt 122.0 t/s、Generation 4.0 t/sでした。8Kと比べると、入力を読む速度の低下は小さめですが、生成速度は少し重くなっています。
8Kでは警告が出たが、処理は完走
8K実行時には、PowerShell上でCUDA bufferに関するwarningが赤字で表示されました。ただし処理は完走しており、合言葉取得とtiming表示まで確認できたため、今回は警告扱いとしています。
CUDA0 compute buffer size of 125.5000 MiB, does not match expectation of 120.0088 MiB
8Kはキャプチャー取得のために再実行した値を採用しています。初回成功時はPrompt 132.4 t/s、Generation 5.8 t/sで、再実行値とほぼ同等でした。
今回の32K検証で確認した範囲
ここは注意が必要です。
今回確認したのは、llama.cppの-c 32768で実行し、約12.5万文字の長文から合言葉を取り出せるかです。
32K tokensいっぱいまで入力を詰めて、速度や精度を厳密に比較したベンチマークではありません。
また、VRAM使用量はnvidia-smiで観測した値です。測定タイミングやllama.cpp側のメモリ確保、OS側の状態によって多少前後する可能性があります。そのため、今回の表では「厳密な最大VRAM」ではなく「今回の実行で観測した使用量」として扱います。
まとめ
Qwythos-9B-Claude-Mythos-5-1M Q4_K_Mは、今回の環境では8K / 16K / 32K context設定の長文入力を完走できました。
- 8K / 16K / 32Kのいずれも合言葉取得に成功
- prompt処理速度は32Kでも115.6 t/s
- generation速度は32Kで3.0 t/sまで低下
- VRAM使用量は観測上おおむね4GB台
- 32Kは動くが、用途によっては生成速度が気になる
通常の短い会話やコード相談とは違い、長文を読ませると生成速度の重さが見えやすくなります。6GB VRAM環境でも32K context設定を試せたのは面白い結果ですが、実用上は「長い資料を読ませたいのか」「短く何度も相談したいのか」で評価が変わりそうです。
次は、同じ6GB VRAM環境で軽量4Bモデルを最適化ビルドした場合に、どこまで速度が伸びるかも見てみたいところです。
コメント