Qwen 3.5 2B：確認済みの仕様とモバイル検証の境界

公式資料から分かること、分からないこと

Qwen 3.5 2B はQwenチームが公開したオープンウェイトモデルです。公式Qwen3.5-2Bリポジトリはタスクをimage-text-to-textと記載し、ライセンス欄にApache 2.0、モデル規模に2Bと示しています。公式設定ファイルの max_position_embeddings は262,144です。これらは特定のモデルリポジトリと設定について確認できる事実です。

一方、これらの情報だけでは、スマートフォンで動くこと、コミュニティ作成のGGUFが公式ファイルと同じこと、量子化ファイルの大きさ、最低RAM、生成速度は分かりません。以前のページにあったこうした端末・性能の断定は、対応する実機記録がなかったため削除しました。モバイル利用は検証する価値がありますが、モデルカードから推測するのではなく、正確なファイルと実行環境で再現可能なテストを行う必要があります。

公式リポジトリにはモデルカード、設定、トークナイザー関連ファイル、Transformers形式の重みが掲載されています。モデルカードには個別のタスクと条件に基づく評価表や、vLLM、SGLangなどのサーバー向け実行例もあります。これらの評価値は各ページに書かれた条件に対するもので、Android端末の測定結果ではありません。「モデル系列」「ダウンロードした正確なファイル」「それを動かすランタイムと端末」の3層を分けて確認してください。

「262Kコンテキスト」はスマートフォンの容量保証ではない

コンテキスト値はモデルまたは設定上の境界であり、アプリが無条件に使える保証ではありません。システム指示、ユーザー入力、会話履歴、書式トークン、画像などのマルチモーダル入力が枠を消費し、生成する回答にも領域が必要です。実行環境がより小さな上限を設定する場合もあり、変換方式やバックエンドによって受け付けられる入力が変わることもあります。

長い入力ではメモリ需要も変わります。重みファイルだけでなく、ランタイムバッファ、KV cache、トークン化後の入力、画像テンソル、アロケーター、OSの余裕が関わります。そのため「2BモデルだからRAMが何GB必要」とパラメータ数だけから推定することはできません。AndroidのMemory Profilerはアプリの実メモリ観察に使えますが、結果には対象ファイル、ランタイム、端末、OS、タスク、計測点を記録してください。

アプリ側では「モデル公表上限」「ランタイム設定」「実際に受け付けた入力」「最後まで完了したタスク」を別々に記録しましょう。長い入力を処理し始めても、途中でメモリ不足になったり切り詰められたりした場合、約束したタスクが完了したとは言えません。サーバーフレームワークのコマンドにモデルカードの数値を設定できても、それはそのサーバー構成の話であり、Android端末の結果ではありません。繰り返しトークンを詰めるだけでなく、実際のプロンプト構成と出力長で試してください。

GGUFには個別の来歴確認が必要

GGUFはllama.cppなどが利用するモデルファイル形式であり、「Qwen公式のスマートフォン版」と同じ意味ではありません。Qwen公式ページには量子化モデルへの導線がありますが、変換または再パッケージされたファイルはそれぞれ別リポジトリに存在します。公開者、固定リビジョン、変換スクリプト、量子化タイプ、トークナイザー、チャットテンプレート、マルチモーダル用ファイル、ライセンスを個別に確認してください。同じモデル名でも精度、同梱ファイル、互換性が異なることがあります。

モバイル用GGUFを選ぶ前に、次の情報を記録します。

• 変更可能な main だけでなく、正確なリポジトリと固定revision。
• ファイル名、正確なバイト数、量子化ラベル、公開者が提供する場合はハッシュ。
• 変換元、トークナイザー、テンプレート、および画像機能に必要な付属ファイル。
• 使用するllama.cppのリリースまたはcommit、ビルド設定、実行バックエンド。
• 端末、OS、入力、メモリ記録、成功・失敗を含む全結果。

公開者がファイルダイジェストを提供している場合は、取得したデータと照合しましょう。提供されていないときにハッシュを作り、発行元が検証したかのように書いてはいけません。Qwenの公式モデルリポジトリはTransformers形式です。GGUFは独自の変換元に結び付け、同じ公式ファイルのように説明しないでください。より詳細な手順はQwen 3.5 2B GGUF評価計画（英語）を参照してください。

再現可能な端末評価シナリオ

あるチームが、特定のAndroid端末でQwen3.5-2BのGGUFを使い、モデル準備後にネット接続を切って長文を要約できるか調べるとします。これは判断用シナリオであり、Coveや特定機種が既に合格したという意味ではありません。

1. 候補を固定する。 GGUFのrevision、ファイル、トークナイザーとテンプレート、量子化、llama.cpp commit、アプリ、端末、OSを特定します。出典URLと利用可能なチェックサムを台帳に残します。比較時は一度に複数条件を変えないでください。
2. 測る前に合格条件を決める。 個人情報を含まない文書と、レビュー済みの要約例を用意します。氏名、日付、否定、引用など保持すべき内容、言語、プロンプト、入力と出力の長さ、失敗時の扱いを前もって定義します。
3. 短い基準タスクを実行する。 ファイルをロードし、正しい形式の回答を生成し、閉じた時に解放できるか確認します。意図したバックエンドが初期化されたのか、アプリが別の実行経路に切り替えたのかも記録してください。端末にGPUやNPUがあるだけでは、そのモデルが使用した証拠になりません。
4. 入力長を段階的に増やす。 固定した長さ別の入力を使い、トークナイザーの実数と設定値を記録します。システム指示、タスク、生成設定、出力目標を揃えてください。失敗、切り詰め、品質不足、メモリ圧迫が初めて起きたケースも、必ずデータに残します。
5. ライフサイクル全体を観測する。 コールドロード、初回、後続リクエスト、キャンセル、アプリのバックグラウンド移行、解放など同じ確認点でメモリを観察します。固定ワークロードを繰り返し、時間の経過で結果が変化するか見ます。失敗を平均で隠さないでください。
6. オフラインと復旧を試す。 リソース準備後にネットを無効化し、コールドスタートからタスクを完了します。可能なら再起動後も試し、その後接続を戻して更新やリモートフォールバックを確認します。
7. 限定した結論だけを公開する。 正確なファイル、ランタイム、端末、タスク、入力長を記載します。速度、互換性、RAM、オフラインの主張は、元データを保存してからにしてください。一度の成功はその環境の結果であり、端末対応一覧ではありません。

このページで言えること、言えないこと

公式カードには、Qwen3.5-2Bが評価対象になる理由があります。2Bパラメータ、image-text-to-textのタスク、Apache 2.0、262,144トークンのネイティブコンテキストです。条件を明記したモデル評価表もあります。これらは調査の出発点であり、スマートフォンで検証済みである証拠ではありません。サーバー向けの例でもフレームワークによって効率が変わると説明されています。モデル系列の一般紹介、第三者GGUF、1回のデモは、端末測定の代わりになりません。

このページはCoveがQwenを使っているとは述べません。公開モデルページの記載はCoveの統合や配布発表ではありません。また、「オープンウェイト」「Apache 2.0」「オフライン」は別の問いに答えます。ライセンスは対象リポジトリで確認し、ローカル実行は準備後にネットを切って検証し、プライバシーはアプリの通信も調べる必要があります。1回の機内モード試験だけで、ダウンロード、分析、バックアップ、同期が常に通信しないとは証明できません。

編集状態：本ページは2026-09-24にQwen公式カードと設定に基づき更新。英語版と中国語版はサイト所有者の確認待ちです。