目次

アリババの淘宝MNNチームが公開した MNN-Pocket-0.3B は、モバイルアプリ内の小さな処理を想定した 300Mパラメータの中国語・英語指示モデルだ。MNNのGitHub Newsは 2026年11月4日付で、32Kコンテキスト、約173MBのINT4配備パッケージ、Apache 2.0ライセンスを案内している。注目点はクラウド大型モデルとの置き換えではなく、限定的な言語処理を端末内に収められるかどうかにある。

短いメモを分類する処理と、ソフトウェア開発全体を計画する処理では、必要な能力が違う。モデルカードは端末内アシスタント、データ抽出、軽量なエージェント型パイプラインを用途に挙げる一方、重い推論や長期的なコード生成は推奨していない。まず候補になるのは、出力をアプリ側で検査できる狭いタスクだ。

オフラインで評価候補になる三つの用途

操作範囲を限定したアプリ内アシスタント。 中国語または英語の依頼を、保存済みメモの検索、既知の画面の表示、端末にある文章からの短い返答など、少数の意図へ分類する使い方が考えられる。これはタスク設計の例であり、重みに完成済みの機能が付属するという意味ではない。画面、利用可能な操作、ローカルデータへの接続、実行条件はアプリ側の仕事になる。操作名の生成と、安全な操作実行は別だ。

文章からの項目抽出。 メモやメッセージから日付、分類、指定された少数の項目を取り出す処理が候補になる。前提は、入力がすでにテキストとして得られていることだ。項目の欠落、曖昧な日付、形式が崩れた出力には、アプリ側の処理が必要になる。形式が固定された入力なら通常の解析ルールのほうが簡単な場合もある。表現は変わるが出力項目は少ない、という場面が評価しやすい。

軽量なエージェント処理の一段階。 分類、短い書き換え、許可された候補から次の処理を選ぶ作業などが考えられる。モデルが無制限のワークフロー全体を管理する必要はない。操作候補を絞り、各段階の出力を検査する構成なら、モデルカードの想定用途に近づく。これらは評価を始める場所の例であって、成功率を測定済みの機能一覧ではない。

オフラインかどうかは、モデルの置き場所だけでは決まらない。モデルファイルとMNNランタイムが端末にあれば端末内推論が可能だが、その後に外部検索や遠隔サービスを呼ぶ構成なら、処理全体はオフラインではない。ローカル推論だけでプライバシー保護まで確定するわけでもなく、通信、ログ、権限、保存方法は別に設計される。

苦手な仕事と対応言語

Hugging Faceモデルカードは、高等数学のような重い推論や、長期的なコード生成を推奨しないと明記している。短い指示や項目抽出と、長い推論の連鎖、リポジトリ全体の変更、自律的なツール操作では、失敗の広がりが異なる。クラウド大型モデルを一般的に代替する製品としての位置付けではない。

32Kコンテキストも、その制約を解消する数字ではない。対応する入力容量を示すのであって、全文にわたる正確な推論を保証しない。アーキテクチャ表には別途 40,960 positions と記載され、配備時の対応は 32K とされている。端末上での利用を考える際の公開値は後者であり、長文の理解精度や全端末での実用上限は別の評価項目になる。

言語については、公式は中英のみ、すなわち Chinese, English としている。日本語対応は公式に宣言されていない。日本語の入力、日英混在の項目抽出、日本語での応答を保証するリリースではないため、ここで挙げる用途も中国語・英語を前提とする。日本語で紹介記事があることと、モデルが日本語対応であることは別だ。

約173MBは実行時メモリではない

モバイル向け配備成果物 MNN-Pocket-0.3B-MNN は、INT4 W4A16の量子化対応学習（QAT）を採用する。W4A16は重み4ビット、活性値16ビットを表す。配備リポジトリの説明では合計約 173MBで、llm.mnn.weight が約 171MB、残りはグラフ、トークナイザー、設定などのファイルだ。

この数値は 配備ファイルの容量であり、実行時の総メモリやピークRAMではない。実行にはランタイムや中間バッファー、コンテキスト長に応じたKVキャッシュが必要になり、アプリ本体や他の機能もメモリを使う。保存容量としてパッケージが収まることと、アシスタント全体が安定して動作することは同じではない。

ファイル容量だけでは、電池消費、持続的な発熱、応答開始までの時間も分からない。私たちは、このモデルを組み込んだアプリでの実機動作をまだ試していない。 ここで扱う数値は公開元のGitHub発表とHugging Faceモデルカードによるもので、DigIntoAIの測定結果ではない。導入経験はサイト下部の運営者連絡先から共有できる。

デコード速度には測定条件がある

11月4日のGitHub Newsは、iPhone 18 Proで約350 tok/sのデコード速度を報告する。一方、Hugging Faceの速度表は INT4、512トークンのコンテキストという条件で、iPad Pro M5のMetalが466 decode tok/s、CPUが231、Snapdragon 8 Gen 5のOpenCLが138、CPUが251としている。

いずれも 公開元による報告値で、全端末への共通保証ではない。同じ表でもSnapdragonではCPUがOpenCLを上回り、GPU系バックエンドが常に最速とは限らない。iPhoneの値はGitHub発表、iPadとSnapdragonの値はモデルカードの速度表に由来し、それぞれの条件と合わせて理解する必要がある。

デコード速度は入力処理後にトークンを生成する速さであり、最初のトークンまでの待ち時間、リクエスト全体の遅延、エージェント全体の処理時間とは異なる。入力長、バックエンド、端末状態、アプリへの組み込み方で体感は変わる。短い返答が速いことだけでは、長時間の連続利用も同じ速さとは判断できない。

品質面では、公開元はGemma-3-270Mなどとの比較で、中英11タスクの平均50.00、INT4では49.59と報告している。これは公開元のベンチマークの要約であり、DigIntoAIによる再測定でも、個別アプリの抽出精度を保証する値でもない。実際のタスクでは、誤りを検出し処理できるかが重要になる。

入手先とアプリ組み込みの違い

公式の三つの入口には役割がある。Alibaba MNNのGitHubリポジトリは発表とランタイムの開発先、MNN-Pocket-0.3BのHugging Faceモデルカードは指示モデルの構成、用途、評価の説明、MNN-Pocket-0.3B-MNNはモバイル配備成果物の取得先だ。ファミリーにはBase、SFT、指示主モデル、GGUF、MNN、Decが並ぶが、ここで扱う配備経路はMNNのINT4パッケージとなる。

配備カードは MNNランタイムを使うAndroid、iOS、HarmonyOSとエッジ端末を挙げている。ファイル取得だけで完成したスマートフォン用アシスタントになるわけではない。対応ランタイムへの組み込み、設定とトークナイザー、入出力画面、不正な出力への対処が必要になる。Apache 2.0は再利用の許諾条件を示すもので、そのアプリ機能まで提供するものではない。

最初の評価は、中国語または英語の代表的な入力、短い期待出力、明確な失敗例に絞れる。項目抽出では欠落と架空の値を確認し、操作選択では許可リストと重要な操作の確認手順を設ける。最大の公開tok/sや最小の容量を選ぶより、対象端末で実際の入力長を使った評価が有用だ。

関連するローカルモデルの記事

Cline Desktop が Ollama／LM Studio でローカルモデル管理に対応はデスクトップアプリのローカルモデル経路を扱い、MNNのモバイル組み込みとは異なる。Deep PrincipleがGLM-5.3ベースのHydrogen-1.0を公開、許可開放はすぐ使える意味ではないとAtria Dawn 正式版ウェイト公開：Hugging Face で 512K コンテキストは、規模と配備条件が異なる公開ウェイトの事例だ。OpenBMBがMiniCPM-OCRをオープンソース化：解析と結果検証のセットが扱う文書認識は、抽出済みテキストを指示モデルで処理する段階とは別になる。

MNN-Pocket-0.3Bの中心的な候補用途は、ローカルアプリ内で結果を検査できる、小さな中国語・英語の言語処理だ。コンパクトな配備ファイルと公開されたデコード速度は評価の動機になるが、実行時メモリ、日本語対応、アシスタント全体の信頼性まで確定する数字ではない。