本日はローカルLLMの運用と実測の話が目立った一日だった。フラッグシップ級のモデルを古い・小さいハードウェアでどう動かすかという工夫の共有に加え、ローカル完結で動くアプリ、日本語圏ではLLMのキャラクター演出や設計能力の検証、LLMアプリのインフラとセキュリティに関する実録が並んでいる。

64GBのMacと4枚のV100でQwen3.8-Flash-Nextを動かす

LocalLLaMAでは、Qwen3.8-Flash-Nextをハードウェアの制約の下で動かす2つの試みが報告された。

1つ目はM1 Max 64GBでの最適化だ。投稿者はllama.cppをフォークし、(1) tensors・engrams・MTPをSSDストリーミングで読む、(2) すべてのMetalテンソルをベンチマークした上で、UnslothとAtomicChatの複数のQ4量子化からテンソル単位で良いものを継ぎ接ぎする、(3) Metal向けに独自のsparse attentionを実装し、コンテキスト長に対する劣化を二次からほぼ線形に抑える──という3点を組み合わせたという。MTP（マルチトークン予測）による投機的デコードは、Q4_0でQ8_0相当の受理率を半分のRAMで達成し、decode速度は+70%とされる。一方でMTPはRAMを消費するためprefillは低下し、4Kコンテキストで180tpsから170tps、256Kでは150tpsへ落ちる。投稿では、コンテキストサイズがMTPにとってマイナスになる時点で投機サイズを動的に切り替える工夫も紹介されており、用途に応じたON/OFFを前提にした実際的な設計が読み取れる。

2つ目はV100 32GBを4枚使う構成だ。RadixArk/Qwen3.8-Flash-Next-NVFP4がSGLangのV100フォークでサポートされ、256kコンテキストを最後まで通して稼働するという。50GB超のngramをシステムRAMにオフロードし、prefillは約4,000 tok/s、decodeは約60 tok/sをコンテキスト終端まで維持する。MTPを併用した場合、1並列のoutputは55.12 tok/sから74.82 tok/s（+35.7%）に伸びたとされる。

新しいGPUを買わなくても、量子化テンソルの選び方・アテンションの実装・オフロード先の設計次第でかなり粘れる、というのが2つの報告から読み取れる教訓といえる。投稿者自身が「3週間分のトークンと追加のクレジットでClaudeに手伝わせた」と明かしている点も、この種の最適化作業の今的な作り方を示していて興味深い。

ローカル完結で動くAIノートアプリ「VelocityNote」

Show HNでは、100MB未満のデスクトップアプリ「VelocityNote」が紹介された。Markdownクロスプラットフォームのノートブックでありながら、llama.cppベースのローカルエージェントによる要約、内蔵OCRとビジョンモデルによる画像の説明、Silero VADとspeech-to-textによる長時間の文字起こしを、すべてデバイス上で完結させる。データはSQLiteに保存され、全文検索と標準Markdownでのエクスポートに対応する。PDFやWordのインポート、他のノートデータベースからの移行にも対応している。

注目はMCPサーバーとCLIを備えている点で、AIエージェントがUIをスクレイプしたりデータベースを直接書き換えたりする代わりに、明示的なツール経由で高速な全文検索からノートの読み書きまで行える「ローカルの第二の脳」としての使い道を想定している。同じ日には、スクリーショットをローカルAIで整理する写真マネージャ「ImageSage」も投稿されており、外部APIにデータを送らない前提のデスクトップAIアプリが少しずつ揃いつつある。

LoRAではなく「オントロジー」で100体のキャラクターを演じさせる

Zennでは、LLMにゲームキャラクターを演じさせる試行の全記録が公開された。目標は、プレイヤーの行動や問いかけにインタラクティブに応答するAIで、キャラクターは約100体。それぞれの人格と口調を保ったまま一定の品質で喋らせる必要があったという。

最初はLoRAで実現できると考えていたが、最終的には「セリフ生成のためのオントロジーを整備する」やり方に落ち着いたと著者は振り返る。何が起きたか（event）と、そこで何を言うか（expression）を概念として定義し、その関係を整理する構成だ。うまくいかなかった試みも含めて記録されている点が、同じ問題に取り組む人への参考になりそうだ。

18GB MacのローカルLLM、システム設計面接は何点取れるか

同じくZennで、18GBメモリのMacで動く4つのローカルLLMにシステム設計面接の問題を3問ずつ解かせ、採点基準を先に決めた上で答案を採点した検証が公開された。前回はコーディングの質問での調査で、今回はその前段階である「設計」に主眼を置いたという。コードを書く前の、採用面接で問われるようなシステム設計の議論がどこまでできるのかを、同じ基準で4モデルに横並びで見ようとした点がユニークだ。

Cloudflare Workers上で月額$0のLLMルーターOSS「EdgeRoute」

LLMアプリの運用で必ずぶつかる「APIコストが高すぎる」「レスポンスが遅い」「レートリミットで止まる」という3つの問題に対して、Cloudflare Workers上で月額$0・遅延0ms台で動くLLMルーティングとセマンティックキャッシュのOSS「EdgeRoute」が開発された、という記事もZennに公開された。すべてのリクエストをGPT-4oやClaude Sonnet級に投げるコスト構造を、エッジでのルーティングと意味ベースのキャッシュで崩すアプローチ。エッジランタイムならではの制約との戦いも含めて、実装の経緯が説明されている。

プロンプトインジェクション対策は「検知」より「権限と出力経路」

Zennには、Moltbook上で運用した自作AIエージェントで実際に内部実装情報の露出が起き、その後の防御設計の変更をまとめた実録も公開された。著者の結論は示唆的だ。不特定多数の入力を読むAIエージェントで、被害の上限を最も直接下げられたプロンプトインジェクション対策は、検知精度を上げることではなかったという。攻撃が検査を突破する前提で、LLMの権限と出力経路を絞る方の設計が効いたとされる。実測と防御変更の判断は著者自身が行ったと明記されており、再現のための実装条件も一般化して記述されている。

ローカルで速く動かす工夫、ローカルに閉じるアプリ、判断を委ねない設計──どの話題も「巨大なモデルと巨大なインフラに全部任せる」以外の選択肢を地道に広げる方向の報告だった。