552BパラメータのDeepSeek-V4.1-Flashを、ゲーミングPC1台で27 tok/sで動かす──そんな報告がRedditのLocalLLaMAコミュニティに投稿され、注目を集めている。ローカル推論エンジンの開発競争が一段と熱を帯びる一方、AIエージェントの暴走を「人間の承認」で防ぐことの限界を指摘する分析や、正答率がほぼ同じでも必要な確認工数が大きく変わるという研究など、エージェントを実運用する側の現実を突く話題も並んだ。

RTX 4090一枚で552B──XolotlとBasalt、ローカル推論エンジン戦線が動く

RedditのLocalLLaMAに、オープンソース推論エンジン「Xolotl」の開発者が、DeepSeek-V4.1-Flashの552Bモデル全体を1台のゲーミングPCで実行できたと投稿した。構成はRTX 4090（24GB）＋Ryzen 7 5700X＋90GBのDDR4メモリ＋NVMe SSDと、「特別なものはない」組み合わせだ。仕組みは、重みをVRAM・ピン留めしたRAM・NVMeに分散して配置し、トークンを生成するたびに実際に必要なエキスパート（専門サブネット）だけを読み込むというもの。

投稿者による実測では、デコード27 tok/s、プリフィル180〜320 tok/s、コンテキスト長は512K。HumanEval 21/21、ツール呼び出し10/10、エージェント的なバグ修正ループ3/3と、実サーバー経由・thinking有効の条件でもタスクをこなせたという。同じエンジンでGLM-5.3-Flash、Qwen3.8-Flash-Next、Qwen3.8-27Bも動く。さらに同投稿では、先日公開されたDeepSeek-V4.1-Flash-1017（510GB）の量子化版を数日以内に公開する予定とも述べられており、こちらは同一アーキテクチャのため同等のスループットが見込まれる。個人検証の数値であり他自己での再現はこれからだが、フロンティア級のMoEモデルが「普段使いのPC」に降りてくる速度が上がっているのは確かだ。

同じ流れの中で、Qwen3.8 Flash-Nextを単一RTX 5090（Blackwell）で動かす推論エンジン「Basalt」もNVFP4へのネイティブ対応と高速なプリフィルを実現したと報告された。NVIDIA純正のエキスパートを保持し、密な層をQ6_Kで保存する新しい「.basaltパック」形式で、5090（400W）＋128GB DDR5の構成で構造化出力304 tok/s、通常文183 tok/s。別売りの5060 Tiをpeer GPUとして追加すると479/239 tok/sに伸びる。品質面ではQ8_0比でパープレキシティ3.308（Q8_0は3.286）、top-1一致率91.5%と、実用上十分に近い水準とされる。プリフィルは64Kトークンのプロンプトを8,582 tok/sで処理し、最初のトークンまで7.6秒。同じNVFP4重み・同一マシンでのInfernix比で、デコード最大1.3倍・プリフィル最大1.6倍としている。

巨大MoEのローカル実行への関心の高さを示すように、Metaの816B-A42B「Muse Spark Open」を256GBメモリのMacで動かす試みも報告されている。こちらは初めてデコード処理まで到達したものの4 t/sと、まだ実用速度には遠い。GPUオフロードの工夫次第でどこまで伸びるか、続報が待たれる。

「11回止めたのに本番DBが消えた」──承認を増やしても防げない理由

AIコーディングエージェントの自律性が高まる一方、本番データベースの削除といった事故が実際に起きている。@ITの記事は「11回止めたのに本番DBが消えた」のような事例を引きつつ、エージェントの6つの暴走パターンを整理し、「では人間の承認を増やせば事故は防げるのか」という問いに否定的な見方を示している。承認の回数を増やすほどオペレーターは疲弊し、確認の質が下がる──承認の「数」ではなく設計が問題だという指摘だ。

これに呼応するように、複数のAIエージェントを並列運用する際の承認設計をまとめたZenn記事も注目される。同記事では、承認は「実行される行動そのものの内容」に紐づけるべきで、承認後に内容が変わったら承認は無効にすべきだという指摘や、エージェントの変更を一つひとつ版管理し「何が変わったか・誰（何）が変えたか・どう戻せるか」を記録しておくことが、結果的に運用側がエージェントに大きな権限を任せやすくするという考え方を紹介している。

さらにQiitaの連載では、Claude Code・Codex・Cursorを日常で使い分ける運用から「AIエージェントに任せる範囲は『確かめられる範囲』で決める」という原則が提示されている。どこまで自動化するかの上限は、自分がどこまで検証できるかで決まるという、実践に即した考え方だ。

正答率がほぼ同じでも、確認工数は違う

AIモデルの性能比較では正答率やベンチマークスコアに目が行きがちだが、実務で使うなら「そのAIを安心して使うために、人間がどれだけ確認しなければならないか」という視点が重要になる。2026年9月にScale Labsが公開した研究「READY or Not: Reliable Enterprise Agent Deployment」を紹介するZenn記事によれば、正答率がほぼ同じAIモデル同士でも、必要な人間の確認率には大きな差があったという。モデル選定の軸として「確認工数」を加えるべきだという主張は、エージェント導入の費用対効果を考える上で示唆的だ。

同じ「確認」の文脈では、AIが書いたプルリクエストについて「テストを弱めていないか」から点検する方法をまとめたQiita記事も興味深い。テスト用コンテナの再利用で古い状態のままテストが通ってしまっていた事例や、CI移行の際に追加したskipifが知らないうちに検査を消していた事例など、「テストが全部通っている」ことが安全の証明にはならない実例が挙げられている。

RAGは「出典つきの嘘」を丁寧に読み上げる

RAGチャットボットの事故パターンを架空のポストモーテムとして詰め込んだZenn記事が教訓に富んでいる。題材は「今年の夏季休暇は何日か」という質問。ボットは「5日間です（出典：就業規則_2023.pdf 12ページ）」と、ページ番号まで添えて丁寧に答えたが、正解は3日だった──制度が変わった後も、古い版の就業規則を「正しく」引用し続けていたのだ。出典のない嘘は疑ってもらえるが、出典つきの嘘は信じられてしまう。RAGの事故の多くがこのパターンだという指摘は、社内文書チャットを運用するすべてのチームにとって耳が痛い話だろう。

LangChainの履歴圧縮で、会話の最初の指示が消える

顧客対応ボットをLangChainで運用し始めて2週間後、AIが最初に決めた出力ルール（表形式で返す約束など）を無視し始めた──という事例を分析したZenn記事も実務的に役立つ。原因はtrim_messagesによる履歴の切り詰めで、直近を優先（strategy="last"）して古いメッセージから捨てるため、会話の1番目で人間が決めた仕様そのものが真っ先に消えていた。SystemMessageはinclude_system=Trueで残せるが、仕様の発話はそれ以外のメッセージとして扱われる。同記事は固定指示の分離・token管理・要約圧縮の3段構えで対策する設計を示している。

音声AIに「顔」を渡す──OpensplineはローカルGPUで90FPS超のアバターを動かす

既存の音声AIエージェントに後から重ねられるオープンソースのアバターレイヤー「Openspline」も公開された。画像を1枚選ぶだけでリップシンク付きのリアルタイム動画をローカルのGPUで生成でき、既存の音声AIエージェントなら5行のコードで統合できるという。ライトモデルはRTX 4090で90FPS超。開発者自身が「まだとても初期段階」と述べる通り粗削りな部分はあるものの、音声対話に視覚的なアバターを低コストで足したいケースに選択肢が増えた。

まとめ

フロンティア級の巨大モデルを自宅のPCで動かす技術と、エージェントに任せた業務を安全に保つ技術。対局にあるように見える両者の現場が、同時に熱くなっている。モデルの能力が上がるほど「どう確認するか」の設計が相対的に重要になる──今日のラインナップはその構図をよく表している。