k16em8 min read

おれのAI環境2026秋

記事は読まねえ設定を見せろ

https://github.com/k16em/homelab/tree/main/ansibleにいろいろ記述してます。

services/llm.yaml と services/openchamber.yaml から辿ると読みやすいと思われます。

これはなんだ

以前の記事でGMKTek EVO-X2にローカルLLM環境を構築している、と書いた。

5月時点から構成を変えたので、スナップショット的に書いておく。

モデル

いま使っているモデル

メインはdeepseekを使っていて、馬力が必要なときにSolを使う、という形を取っている。

qwenはdeepseekの1.8〜2.3倍くらいのtok/sがprefil, 生成で出ているが、出力が安定しないので出動率が下がった。具体的にどう安定しないかというと、英語では問題なく、日本語のときに中国語が高頻度で混ざる。「日本語で応答して」と入力する虚無の時間が発生するのがちょっと耐えがたいので、最近はtok/sを妥協してdeepseekを使っている。deepseekはいまのところ安定している。また、tool callやタスクの進め方もdeepseekのほうが好みだった。

Luna Fastは要約やセッションタイトルの生成など、どうでもいいが必須の処理を投げている。

使わなくなったモデル

Claude系のモデルはまるっと使わなくなった。

モデル性能の観点もありつつ、サブスクプランだとサードパーティの取り回しが悪いことが理由としては大きい。Opusのtok/s改善とOpenAI互換のAPIをサブスクで叩けるようになったら利用を再開するかも。そんな未来が来るとは思えないが……。

あとgemma4。gpt-ossと同じく、出力の雰囲気が気にいらないという理不尽な理由でクビ！(暴君)

モデルを使うためのツール

いま使っているツール

クライアント側はOpenCodeに一本化した。プロバイダごとにクライアントを切り替えるのがあほくさすぎるから。移行を済ませた直後にClaude CodeがAGENTS.mdにようやく対応して悲しい。

あとPC立ち上げるほどじゃないな、というとき用にOpenChamberインスタンスを立ち上げてスマホからある程度のことをできるようにしている。OpenCodeでできることに加えてワークスペース管理やTTS/SST、cronjobといった機能がついてきてよい。専用インスタンスが用意できるならOpenChamberはかなりよいのでみんな使おう。

サーバ側はllama-swapを前段に置くところは変えず、起動するものはllama.cpp(HIP)からGufoに変更している。Redditを見ているとモデルやGPUに特化した推論エンジンを作る/使う流れができていそう。Strataとかもこの流れっぽい。自分はStrix Halo環境なのでGufoと、ときどきhalo-box/strix-llama.cppを選択している。

使わなくなったツール

すごく厳密に言うとcodexはまだ生きているが、これは認証情報をOpenCodeに渡すため。CLIとしては一切起動していない。

変えた運用

ローカルLLMの稼働率を上げた

世間より2ヶ月ほど遅れたが、日常のあれこれはDeepSeekで十分だな……と実感できたので、基本DeepSeekに寄せ、複雑なもののみSolに投げる運用にした。

結果リセット権を2回自然消滅させているので、うまく回せているような、すごく損をしているような、不思議な状態となった。

memoryとskillを撤去した

自分の好みを自然言語で記述しておいて、以降指示を出すときに横着できる 機能と考えるとこんなものは百害あって一理なしだと気づいたため……というのは言いすぎかもしれないけど。CI/CDとかhookとか一切整備しないで、「本番リリース前は必ずテストを実施して、手順書に従ってデプロイしてください」みたいなお願いベース運用そのものでしかない。〈無人化すべきである〉。

とはいえ同じ環境で作業する以上、AIのためだけに、人間様の効率を落とすようなもろもろを仕込むのもよろしくない。cdするたびに大量の処理が走るとかいやですからね。

というわけで、現状はといえば、

  • 都度厳密に指示を出す
  • 自明すぎて自分ですら忘れることのみAGENTS.mdに書く

という運用になっている。

効率の観点は計測していないのでなんとも言えないが、「ごめんなさい、skillを無視していました」と言われたり、変なmemoryを引いてきて /new させられたりがなくなったので、精神衛生にはとてもよい。

TTS/STTを入れた

さすがに音声入力やっておくべきだろう、ということで、TTSにはVOICEVOX(nemo)を、STTにはwhisperを入れた。

一番大きいモデルを使っているだけあってwhisperの精度はいいのだけど、喋り方をチューニングしないと認識が甘くなってしまう。英語だと多少マシ。実用というよりはお遊びでしばらくSTTを使うだろうけど、年内には飽きていそう。

TTSのほうはかなりよい。応答をすべて読み上げるようにしているので、指示を投げたら別の仮想デスクトップで他の作業をして、喋り出したら戻る、という運用ができる。通知と違って鳴ったその瞬間聞き漏らしたら終わりではなく、喋り続けてくれるのがいい。微妙な点は辞書が甘く、英単語をちゃんと辞書登録しないとアルファベットをそのまま読んでしまう(たとえば、redirect を アールイーディーアイアールイーシーティー のように読む)点だけ。無料ツールにそんな高望みはしない。

TTS導入に際して、Aratako/Irodori-TTSも検討したけど、こちらは入れなかった。機械には機械みたいに喋ってほしいため(変にそれっぽいと時々微妙な出力したときいやに気になる、という理由もある)。

hermes-agentをやめた

OpenClawみたいなやつ。最近だとGrok BotとかOpenAI Dotsとかああいうやつ。

メールやらなんやら以前に、リマインダーやスケジューラとして使うのすらちょっと抵抗があっていまいち活用できていなかった。結果、ローカルLLMをVPN張らずにDiscordやSlackから叩けるツールと化していた。tailscaleがあるのでそれだけで存在意義が確保できるわけもなく、あえなく爆発四散となった。

それってAIほんとにいる？ 電力や計算量もったいなくない？ みたいになってしまう人にいらないツールすぎた。

AIにまともな文章を期待しなくなった

技術文書とどうでもいいポエムを足したような文章はどうやっても出てくるので、すぐdiffを見たり参考資料の方を読んだりして、なるべくAIの出力は読まないようにしている。AIに書かせたPRもdescriptionを読まずにCIが通っていたらOK、くらいの運用にしている。

あんなん読んでたらおかしくなる。

とはいえなんもしてないわけではなく、最低限のルールだけ書いてはいる。

## Terminology
- Prefer original English IT terminology over unnatural Japanese translations.
- Keep proper nouns in their original-language form.
- Describe effects and outcomes concretely using wording equivalent to "applied", "reflected", or "affects", rather than vague phrasing.

課題

web search

Claude CodeやCodexを使わなくなって困っているのが、web search。

これまでのようにOpenAIやAnthropic側に実行を押し付けられなくなってしまったので、rate limitやらなんやらを気にしてゴリゴリ調査しづらくなってしまった。こういうのを使うべきかもしれないと思いつつ、でもそれだけのためになあ、という気持ちもある。

使うドキュメントをローカルにどんどん溜め込んでいくべきなのかもしれない。

適度なスモールモデル

OpenCode, OpenChamber, Open WebUIなどのツールはセッションの最初の入力からセッションタイトルを設定したり、無操作が続くとセッションの要約を出したりする。

ローカルモデルでこれを適切に処理できる軽いモデルがなかなか見つからない。タイトルを決めたり要約をしたりする程度のタスクで重いモデルをロードしたくない。セッションで使っているモデルに処理を投げるとロード問題は解決するが、tok/sの問題もあるし、クライアントによってはセッションと混線してメインのコンテキストを汚してしまう(おまえはタイトル生成機だ！ をコンテキストにねじこまれて、セッションが死ぬ)。

なので現状はLuna Fastに投げているが、実質これのために20USD/月かあ、という気持ちが湧いてきてしまっている。

まとめ

  • EVO-X2しばらく使ってない人はgufo試すといいかも
  • OpenChamberいいよ

日記

突如としてすべてを破壊して組み直したような期間だった。Claudeはもう勢いのままに解約までしてしまったし、Codexもそろそろ解約かな、というレベルで見直している。

というのも、DGX Sparkで盛り上がっていたNvidia勢に続いて、ROCm勢も追いかけるように盛り上がってきたからだ。Strix Halo上で動かすローカルLLMはモデルの規模も出力速度も上がっており、その恩恵としてこの秋はローカルLLM環境をかなり整えることができた。

当然ClaudeやCodexを契約したほうがコスパが圧倒的にいい現状は変わらない。ローカルLLMの実行環境を揃えるだけでどれくらいサブスクできたのか……。ダリオ・アモデイもサム・アルトマンもイーロン・マスクも平等に嫌いなので金落としたくないぜ！ という気持ちがあるのは横に置いておく。

あともろもろ設定や構成を見直していて思ったけど、自分はLLMをワークフロー実行装置として使わないといけないのがなんか気持ち悪いしもったいないなと思っているな。本当にLLMが必要な瞬間ってそんなに多くないはずなので、現状のとりあえずLLMを主体としてなんかさせる構造から、GitHub Actions的なワークフローの中の本当に必要なときだけ呼び出す感じのなんかが実現できないかなー、というのが直近なんとなく考えていること。っていうかとりあえずLLMを主体になんかさせるの危なすぎる。とくにSaaSのやつ。

Continue reading