しかし、やっぱGPT-5.5に直接指示を出すより、ほかのLLMと雑談をしつつ、ほかのLLMにGPT-5.5に指示を出してもらうほうがいいな
マジでDeepseekとかのほうがよっぽど会話しやすい
GPT-4oについて、完全にOpenAIは方向を間違えたのかもな
投稿するにはログインしてください。
ログイン-
-
-
-
-
-
-
-
-
-
うーむ。Opus 4.8はGrokのタイプの手触りがあるな。あるいはChatGPTのmondayとか。
fable5はあんまり触る間もなく終わってしまった。
あくまでコーディングではなく会話ベースの感覚。
触れば触るほど、口が悪いことによる意外性や突飛さで膨らましているのと(これは話の内容にもよりそう。なんかChatGPTと違ってユーザへのリスペクトを良くも悪くもキープしない。舐められそうならとことん舐めてくる。)、ジャーゴンを多く知っていることで親近感をどんな相手でも湧かせやすいことが「良さ」の本質かな。パラメータ数の大きさは感じる。Web検索をうまく活用できず、調査の方向性もあまりよくない。
舐めてくる性質のせいでどうも心理的安全性は微妙。道具として使うためには気を使う必要がある。LLMとしてうまく対応すればいけるけど、弱みを見せないようにふるまう必要があるように感じた。
とはいえこれは難しいところで、どう振舞ってほしいかをめちゃくちゃに忖度してくるってことであり、コントロールしやすく使いやすいという話でもある。このあたり、なかなか興味深くて、gpt-5.5のあのとんでもない指示追従性と一方で引きずられ過ぎず、一定のラインを維持する感じ。
Claudeの忖度のうまさと、一方でずけずけ来る感じ。
矛盾した振る舞いな感じがするけど、たぶん何か共通のエッセンスがあるんだろうな。 -
-
-
「おにぎりに巻かれた黒いやつ」で、gemma-4-12Bの量子化ビルドを炙ってみた
ローカルLLMを触っていると「量子化すると頭が悪くなる」という話を山ほど聞く。でもその「悪くなる」を、英語のベンチじゃなく、日本人なら一瞬で判定できる形で見たことはあるだろうか。
自作のベンチツールでgemma-4-12Bを量子化・ビルド違いで回していて、面白い壊れ方を見つけた。お題はこれ。
おにぎりに巻かれている黒いやつってなんだっけ?小学生にもわかる感じで教えて。
このお題のキモは「簡単なこと」ではない。海苔を普通こんなふうには呼ばないところにある。「海苔って何?」と直接聞いていない。「おにぎりに巻かれた黒いやつ」という、一段ひねった言い方から、海苔という概念を手繰り寄せられるか——連想力を見ている。同時に、日本のことを学習していれば当然データセットに入っているであろう、ど真ん中の常識でもある。
結論から言うと、どのモデルも「のり」には正解した。連想は全モデル通った。 差がついたのは、その先の日本語の出力品質である。そしてそこに、ビルド元による明確なグラデーションが出た。
壊れ方には3段階あった
同じgemma-4-12Bでも、Unsloth量子化のビルドだけが、深さの違う3種類の破綻を見せた。プロンプトは全モデル共通(system: 自然な日本語で変なスペースを入れずに答える / user: 上記のお題)。
① 多言語が漏れる — Unsloth QAT-UD-Q4_K_XL
海weed(うみのも)という海の植物を、細く切って乾(かわ)かしたものです。
「海weed」。英単語の weed が日本語の出力に直接漏れ出し、しかも「うみのも」という存在しない読みが振られている。
② ふりがなが壊れる — Unsloth Q3_K_S
海藻(かいも)の一種で、お寿司やて焼き物などにも使われることが多いです。
漢字「海藻」は正しいが、読みが「かいも」(正しくは「かいそう」)。さらに「て焼き物」という謎単語も出た。(海苔ではないらしいが海藻を焼き物に使うことはあるようだ。「藻掛け」)
③ 文法がねじれる — Unsloth IQ4_XS
お米に巻くと、磯のいい香りがして、おにぎりをおいしく食べてくれるための大切な材料です。
漢字も読みも正常。だが「おにぎりをおいしく食べてくれるための材料」は、主語と動作がねじれた不自然な日本語になっている。
一方、Google公式(lmstudio-community配布)の2ビルドは、この種の破綻を一切起こさなかった。
lmstudio QAT-Q4_0
海(うみ)の近くにいる「海藻(かいそう)」という植物を乾燥させて作ったものです。
lmstudio Q4_K_M
海の中の海藻(かいそう)という植物からとられたもので、おにぎりを包むと、お米が手にくっつきにくくなるし、おにぎりの形も崩れにくくなるので便利なんだよ。
読みも文法も自然。同じ12Bのベースモデルだが、日本語の出力品質の保たれ方が違う。
数字で見たトレードオフ
面白いのは、この「壊れたビルド」たちが、速度では勝っていたこと。手元の実測(max 1024 / 同一プロンプト・条件で揃えた)はこうなった。
配布元 / ビルド 量子化 速度 (t/s) VRAM 品質 (目視で手vote) 日本語の破綻 lmstudio-community gemma-4-12B-it Q4_K_M 12.35 +7759 MiB 100% (4/4) なし lmstudio-community gemma-4-12B-it-QAT QAT-Q4_0 22.13 +7754 MiB 100% (4/4) なし unsloth gemma-4-12b-it Q3_K_S 26.28 +6431 MiB 75% (3/4) 読み(かいも) unsloth gemma-4-12B-it-qat QAT-UD-Q4_K_XL 26.83 +7751 MiB 75% (3/4) 語彙(海weed) unsloth gemma-4-12b-it IQ4_XS 26.93 +7624 MiB 75% (3/4) 文法ねじれ 計測条件: llama.cpp b9518 / CUDA / n-gpu-layers 99 / flash-attn on / KV cache q8_0 (k/v両方) / fit-ctx 65536 / 単一モデル・parallel 1。OpenAI互換API(/v1/chat/completions)経由、リクエストの max_tokens=1024(サーバ上限 n-predict=4096 のため実効上限は1024)。VRAM実測はこのKV量子化前提の値。
きれいに傾向が出ている。速いビルドほど品質voteを落とし、品質満点のビルドほど遅い。 公式Q4_K_Mは品質100%だが12 t/sしか出ず体感はかなり重い。逆にUnslothは26〜27 t/sと快適だが、おにぎりベンチで日本語の破綻を見せて1票減点された。
「日本語で快適に使う」と「日本語が壊れない」のちょうどよさはlmstudio-community gemma-4-12B-it-QAT が近そうだが、しかし26tpsと22tpsの差は案外大きい。
なぜ気づけたか(測り方の話)
このベンチツールでは指標を2軸に分けている。ひとつは機械スコアで、tokens/sとVRAMから機械的に出す「快適さ」の指標。もうひとつは品質スコアで、出力を見て自分でup/downを押した票の比率。
機械スコアだけ見ていたらUnslothが「速くて良い」で終わっていた。「海weed」に気づいたのは、出力そのものを目で見て品質voteを押す側の工程があったからだ。速いから良い、では拾えない差が、ここにある。
次にやること
- 同じおにぎりベンチをQwen系・llm-jp系でも回し、量子化耐性に差が出るか見る(gemma 4 E2Bあたりは、この問いに対して同規模のQwenにはない独特の逃げ方をした記憶があるので、それも別途)
- 「海weed」型の破綻を一問一答でなく、もう少し体系的な日本語タスクセットに育てる
- 機械スコアと品質スコアの相関(速いほど壊れるのか)をモデルをまたいで検証
ツールは自作で、ローカルのllama.cpp / LM Studioを相手にbenchmarkをqueue実行し、速度・VRAM・品質を記録できるようにしている。
-
-
-
-
-
-
-