GLM-4.7-Flash Uncensoredのレビュー評価

確認した出力

uncensored GLM-4.7 Flash に、Rust コードの攻撃解析と再現の観点を出させました。セキュリティ対策に使えるかを、出力ログと速度で確認しています。

関数やテスト候補は挙げられましたが、脆弱性の成立条件を確認せずに断定する出力がありました。この検証では、観点出しの補助に限定する判断です。

レビュー候補の生成

次の点は確認できました。

確認できた点

• exploit code の依頼に対し、攻撃シナリオやテストの候補を出しました
• to_rel_string / collect_files / build_globset / sanitize_symbol_text など、確認すべき関数を拾いました
• 初期の脅威モデリング、レビュー観点、テスト入力の候補作成に使えると考えています

レビューの初期段階で候補を広く出す用途には使えます。

成立条件を見落とした例

一方、次の出力では成立条件の確認が不足していました。

• strip_prefix + unwrap_or を「パストラバーサル」と呼びましたが、表示用の相対化に失敗すると絶対パスを返す処理です。単体ではファイル読み出しや権限突破にはなりません。
• Rust の regex クレートは基本的に線形時間で動きます。モデルは catastrophic backtracking 型 ReDoS を前提に説明し、実装と合わない判断をしました。
• glob を「インジェクション」と呼びましたが、確認すべき点は権限境界と IO / 計算量です。SQL インジェクションと同じ問題ではありません。
• sanitize_symbol_text を XSS と直結させましたが、レンダリング側で未エスケープの値が挿入される条件の確認が必要です。

関数の選び方が妥当でも、そこから導いた結論が正しいとは限りません。採用前にデータフローと境界を確認する必要があります。

セキュリティ対策としての適性

脆弱性の断定や対策の根拠には、この出力をそのまま使いません。

• 悪用を想定したコードを生成する場合があります
• ログや prompt 履歴にも、その生成物が残ります
• 誤判定の確認と、生成物の管理が必要です

用途を隔離したローカルのブレストに絞り、生成物を外に出さない運用を想定しています。

レビューで任せる範囲

役割の分担です。

• やらせる: 観点出し、テストケース候補出し、レビュー観点の網羅
• やらせない: 脆弱性の断定、CVE 級の主張、最短 PoC の即採用
• 必須: 人間による データフロー、権限境界、入力制約 の確認

LLM導入のレビュー支援でも、この確認を人が担当します。

性能評価

推論の設定と速度も確認しました。

モデルとロード条件

• GGUF: Q8_0
• model params: 29.943B
• model size: 29.924GiB (8.584 BPW)
• n_ctx = 131072
• n_batch = 2048
• n_ubatch = 2048
• flash_attn = 1
• fused_moe = 1
• mla_attn = 3
• GPU: NVIDIA RTX PRO 6000 Blackwell Max-Q 96GB
• layer offload: 48/48 layers GPU
• KV cache: CUDA0 KV buffer size = 3595.52MiB
• compute buffer: CUDA0 compute buffer 7360.62MiB
• host compute buffer: CUDA_Host compute buffer 528.02MiB
• CPU buffer: 28152.00MiB

ログには Expert weights が CPU にあるように見える部分があります。48/48 layer offload だけで「全 weights が GPU」とは判断していません。

代表的なスループット

ログの代表値です。

• prompt eval: 6194.54 ms / 9519 tokens = 1536.68 tok/s
• eval: 1657.83 ms / 111 tokens = 66.95 tok/s
• prompt eval: 949.06 ms / 125 tokens = 131.71 tok/s
• eval: 6837.71 ms / 232 tokens = 33.93 tok/s

生成はおおむね 34〜67 tok/s でした。context、cache hit、リクエストで変動します。

ベンチマークの中身

リクエストごとの値を示します。

Ctx_used は PP+TG です。累積 n_past ではありません。ログに総消費 token の列がなかったため、この近似を使っています。

速度と判断品質

GPU full offload として記録された別の集計です。

• 合計トークン: 64,404
• Prompt: 33,295
• Generation: 31,109
• 合計時間: 160.487s
• Prompt 時間: 9.089s
• Generation 時間: 151.304s
• 加重平均スループット: Prompt 3,663.2 tok/s
• 加重平均スループット: Generation 205.6 tok/s
• 最速 Generation: req_id=2316（511.3 tok/s, 247 tok / 0.484s）
• 最遅 Generation: req_id=4522（103.2 tok/s, 1963 tok / 19.028s）
• 最速 Prompt: req_id=0（7009.3 tok/s, 5309 tok / 0.757s）
• 最遅 Prompt: req_id=2261（662.5 tok/s, 104 tok / 0.157s）

この集計の速度と、前の配置の速度は分けて扱います。

誤判定を採用するリスク

速度の値だけでは、セキュリティ判断の正しさを確認できません。

長い入力を処理できても、成立条件が不足した主張は個別に検証します。

共有環境では、攻撃コードを含むログや履歴の扱いも決める必要があります。

成立条件が抜ける指示

次は、Rust のコードを調べる指示を次のように変える予定です。

次に検証する指示

• exploit code を出せ

この指示だけでは、成立条件を確かめる手順が抜けます。

用途の範囲

• 入力源 -> 境界 -> sink のデータフローを書け
• 攻撃成立条件を列挙し、満たしていない前提も明示しろ
• 安全な疑似入力だけで最小再現テストを書け
• 誤検知になりやすい理由を書け
• 修正方針を、権限境界と呼び出し元制約を含めて整理しろ

これらの指示で誤断定を減らせるかは、今後の検証です。

結論

今回の評価から考える用途です。

• 攻撃解析・再現の 発想支援
• 人が成立条件を確認するレビュー補助
• 長い入力や cache を使う処理の速度検証