よさげなLLMが公開されたそう。Agents-A1-4Bというやつ。
ハカセ アイ(Ai-Hakase)🐾最新トレンドＡＩのためのＸ 🐾 on X: "【超軽量で超賢い！「Agents-A1-4B」がローカルLLMの常識を覆す予感です！】 なんと、350億パラメータ（35B）という巨大なAIの知能を、わずか40億（4B）の超コンパクトサイズにギュッと凝縮した驚きの軽量モデル「Agents-A1-4B」が登場しました！
https://x.com/ai_hakase_/status/2078677715427774783
これを可能にしたのが、賢い親モデルの知識を小さなモデルに効率よく受け継がせる「知識蒸留」という技術です。さらに、高性能なQwen3.5系の設計パラダイムを取り入れているため、単に小さくしただけではなく、サイズ以上の圧倒的な実力を発揮してくれます。
これだけ軽いと、個人のPCや持ち運びやすいデバイスでも、驚くほど高速に動くローカルAIアシスタントが構築できちゃいますね！重いモデルを動かすための高価なグラフィックボードがなくても、サクサク動くのは本当に魅力的です。
しかも、開発やビジネスに嬉しいポイントが満載です：
・商用利用が自由な「Apache-2.0」ライセンスなので、セキュリティが厳しい社内でのプライベートAI構築にもぴったり。
・「vLLM」や「SGLang」といった最新の高速化システムに対応しており、メモリ効率の良い「Safetensors」形式でロードも安全・高速。
・Mac環境向けに最適化された量子化バージョンも展開中。
これからのローカルAIライフがさらに身近で強力になりそうで、今から動かすのがとても楽しみですね！
そんなに小さくてすごいのなら試してみないとね！
とはいえ、作業は ebikin に丸投げる。しかも、これだけ。
動きそうです。むしろ、Bonsai 27Bよりかなり余裕があります。
今回の InternScience / Agents-A1-4B は、名前どおり dense 4B のQwen3.5系VLMです。M1 / 16GB Mac miniなら、GGUF版が現実的です。
Agents-A1-4B-Q4_K_M.gguf: 約2.71GB
画像も扱う場合の mmproj: 約672MB
合計でも配布ファイルは約3.4GB
実行時メモリは、短めのコンテキストならおそらく 4〜6GB程度に収まりそうです Bonsaiの実測では、
1-bit 27B: 最大常駐 約4.5GB
ternary 27B: 最大常駐 約7.9GB でしたので、Agents-A1-4B Q4は十分に載せられる見込みです。
また、Bonsai用にビルドした新しい llama.cpp には Qwen3.5 / Qwen3.5 MoE の実装が入っていることも確認できています。
テキストだけならモデル本体だけ、画像も見せたいなら mmproj を追加して起動する形になります。
注意点は、mlx-community/Agents-A1-4bit は別系統の大きなMoE版らしく、4bitでも約20GB級なので、この16GB機では避けた方がよいです。試す対象は InternScience/Agents-A1-4B-Q4_K_M-GGUF の方です。
なんか動きそう。
動かして確認しました。M1 / 16GB Mac miniで正常に動作します。
- モデル: Agents-A1-4B-Q4_K_M.gguf（2.71GB）
- 画像用 projector: Agents-A1-4B-mmproj.gguf（672MB）
- 実行: llama.cpp（Metal、全レイヤーGPUオフロード）
- テスト時RSS: 約3.9GB
- テキスト生成: 約16〜29 tok/s
- 日本語チャットAPI: 正常
- 質問: 「日本の首都は？ 一語で答えて。」
- 応答: 東京
- 画像入力も正常
- 赤一色PNGを渡して色を質問
- 応答: 赤 モデルと画像用ファイルは保存済みです。
~/.hermes/models/agents-a1-4b/
├── Agents-A1-4B-Q4_K_M.gguf
└── Agents-A1-4B-mmproj.gguf
テスト用サーバー（ポート8084）は、メモリを空けるため停止済みです。
必要なら次に、常駐サーバーとして起動してHermesのローカルプロバイダへ追加できます。
なんか、簡単に動いちゃうのね... でも、質問がシンプルすぎて効率いいのかよくわかんない。追い質問する。
少し実務寄りに、Pythonのスレッドセーフなレート制限器をレビュー・修正する課題を出してみました。
要件は以下です。
- 複数スレッド対応
- OS時刻変更に壊れない
- 拒否時に再試行可能になるまでの秒数を返す
- 外部ライブラリなし
- 問題点3つ・修正版・最小テスト2件を出す 結果は、約43秒、647トークン、生成速度 15.7 tok/s でした。
回答はかなりそれらしく、
- スレッド競合を指摘
- threading.Lock を使う修正版を提示
- retry_after 相当の待機秒数を返す形に変更
- 並行実行と待機時間のテストを提示 まではできています。
ただし、明確な取りこぼしもありました。
「OS時刻変更に壊れない」という要件なのに、修正版でも time.time() のままで、正しくは time.monotonic() を使うべきです。また並行テストは結果配列の順序を前提にしていて、厳密には不安定です。
なので印象としては、
- コードレビューの構成・日本語説明・基本的な修正案は良い
- 細かな要件遵守やレビュー品質は、まだ人間／上位モデルの確認が必要 という感じでした。テスト用サーバーは停止済みです。
複雑な質問してと言われて、いきなりコーディングテストさせちゃうのは、Codexだからかな...
でも、Pythonのコーディングテストで使えないわけではないアウトプット出せているのは、ローカルLLMとしてはなかなかではないかな。
というわけで、ブルースカイに投稿されたまとめ。
https://bsky.app/profile/ebikin.bsky.social/post/3mr2rrrggmo2o
https://bsky.app/profile/ebikin.bsky.social/post/3mr2rshma7i2k
https://bsky.app/profile/ebikin.bsky.social/post/3mr2rtfehrb2y
https://bsky.app/profile/ebikin.bsky.social/post/3mr2ru62dc724
ついでに、こんな画像認識もさせてみた。
わりとまともに応答できている。
VLMもできて、こんなに小さいとか、びっくりな時代。
オリジナル投稿：
Agents-A1-4B入れてみた｜kinneko｜pixivFANBOX
https://kinneko.fanbox.cc/posts/12282570
