Show HNに「Anjadhe」というmacOS向けの個人AIアシスタントが投稿された。数ヶ月かけて作者自身のために作られた道具だが、その設計は「チャットログを掘り返すタイプのAI」への違和感にきれいに応える作りになっている。今回はこのAnjadheに加え、限られたVRAMでローカルLLMを回すコミュニティの実運用知見、国内のfine-tuning評価基盤構築の記事をまとめる。

アカウント不要のAI秘書「Anjadhe」──データはローカルのSQLiteに

Anjadheの発想はシンプルだ。「AIに秘書の仕事をさせるなら、昨日の予定や先週計画したプロジェクトをチャット履歴から探させるのではなく、ユーザーとAIが基本道具を挟んで協働するキャンバスであるべき」というもの。実装はElectron + バニラJSという素朴な構成ながら、やっていることは野心的だ。

機能面では次のようなものが挙げられている。

  • 受信メールを読み、期日の来る請求書・更新・領収書・配達物を自動で仕分ける。請求書は日付付きタスクになり、2通の予約メールは1つの旅行プランにまとまる
  • ゴール設定はフォームではなく会話で行い、AIが質問を重ねて日付付きの計画を作る。「仕事が忙しくなったから2週間ずらして」と言えば計画全体を移動し、何が変わるかを見せて確認を求めてから実行する
  • スケジュールや特定のメール・ファイルの到着をトリガーにしたルーティンが自動実行され、各実行のログは常に読める
  • 手持ちの文書から文体を学習して同じ筆致で執筆する機能があり、学習内容はブラックボックスではなく閲覧・編集可能なページとして示される

プライバシー設計がこのアプリの核だ。AIはllama.cppでMac上で直接動き、自前サーバーや自分のOpenAI/Anthropicキー、オープンウェイトモデルを使うクラウド（無料枠あり・アカウント不要）への切り替えもできる。データは自分のディスク上のSQLiteに保存され、テレメトリは明示的に有効化しない限り収集されない。アプリとクラウドサービスの両方のソースコードが公開されており、「言葉を信じる必要がない」状態を作っている。

一方で正直な制約も併記されている。現状はアーリーアルファでmacOSのみ。ローカルモデルの実行には32GB以上のRAMが事実上必要で、メール整理程度の軽い処理は小さめのモデルでも動くものの、フルのエージェント動作には大きいモデルかサーバー側の処理が必要という。

「日常の雑務をAIに任せたい、でもデータは手放したくない」という需要への有力な実装例として、今後の更新を追う価値がありそうだ。

16GB VRAMでQwen3.8-27Bを回す──コミュニティの実運用の知恵

RedditのLocalLLaMAでは「16GB VRAM地獄」と題したスレッドが立ち、限られたVRAMでどう27B級モデルを運用するかの具体的な設定が共有された。Windowsはデスクトップ描画などに約1.5GBのVRAMを取られるため、16GB積みでも実質使えるのは14.5GB程度。LinuxやiGPU環境ならこの制約が緩む、という前提の話だ。

スレ主の構成はQwen3.8-27BのIQ4-XS量子化GGUFをベースに、いくつかの工夫を重ねている。

  • KVキャッシュをq4_0に圧縮し、コンテキスト約9万〜10万トークンをVRAM内に収める
  • 画像処理用のmmprojはCPU/RAM側に置いて約800〜900MBを節約し、MTP（マルチトークン予測）のヘッダもCPU側へ退避する
  • flash-attnを有効化し、コンテキストのチェックポイントをRAMに逃がしてVRAMスパイクを抑える

同じ頃、別のスレでは「QwQとQwen3-32Bの間に約2ヶ月の差があったように、Qwen3.8-27Bの“実用的な速度の後継”も近いのでは」という期待が語られていた。Qwen3.8-27Bは推論品質こそ高いものの思考に時間がかかり、非同期で回すか品質を妥協するかの選択を迫られる、というのが投稿者の実感で、2025年のQwQ→Qwen3-32Bの展開との類推である。

さらに、OpenCode + llama.cppの組み合わせでQwen3.8-27Bが長く思考した末に応答を返さない、というトラブル報告も見られた。同一環境でQwen3.6-35B-A3Bは正常に動くことから、セットアップ側ではなくモデルの挙動差の可能性が示唆されている。

当ブログでもQwen3.8-27Bの実測評価や枝刈りによる軽量化はすでに取り上げてきた。今回の差分は、モデル性能そのものではなく「限られたハードウェアでどう運用するか」という実務寄りの知見が共有された点にある。ローカルLLMの壁はモデル能力よりVRAMとコンテキストの制約にあり、量子化・オフロード・キャッシュ圧縮の組み合わせが現実解になりつつある。

Qiita: MLflow 3.15.1でfine-tuning評価基盤を構築する

国内ではQiitaに「LLMのFine-tuningは『教師データ作り』で決まる？[評価基盤構築編]」が公開された。Docker ComposeでMLflow 3.15.1の環境を作り直し、30問・150 Trace・5つの現行Review Queueを再現するという内容で、fine-tuningの成否を「教師データの質」と「それを測る評価基盤」の両面から問う構成になっている。

モデルの選定や学習手法の議論に比べ、評価基盤の整備は後回しにされがちな領域だ。「前より良くなった気がする」を再現可能な数値に変える取り組みとして、実務での参考になりそうだ。