MiniCPM LES、専門家を制限せずに35B MoEをスマートフォンへ
MiniCPMによれば、LESスケジューリング技術により、350億パラメータのモデルがiPhone 18 Pro Maxで毎秒20.51トークンを生成できるという。MiniCPM LESが取り組むのは、モデルのどの部分を実行に参加させるかを制限せずに、モデルの重みを十分な速さでメモリへ移動するという具体的な課題だ。
これは、各トークンでモデル全体を使うのではなく、選択されたパラメータ群を有効化するアーキテクチャであるMoE（mixture of experts）において重要な違いとなる。MiniCPM-V 4.7の35B-A3Bという表記は、総パラメータ数が約350億、アクティブなパラメータ数が30億であることを示す。アクティブな計算量が少なくても、残りの重みを保存し、アクセスする必要がなくなるわけではない。
本質的な競争は、動的な専門家選択を維持することと、読み込み遅延を減らすことの間にある。Appleによる過去のフラッシュベース推論研究は、有用な参照点を示している。ストレージは限られたメモリを補えるが、データ移動には慎重な管理が必要だ。MiniCPMの貢献は、このより広い問題の中で専門家のスケジューリングを対象としている。公開された結果についても、慎重な帰属が求められる。スマートフォンでの最高速度は複数の最適化を組み合わせたものであり、「lossless」は見出しが示唆するほど広い意味には解釈できない。
MiniCPM LES、専門家の読み込みをスケジューリング問題へ転換
重要な変化は、モデル本来の専門家選択を維持しつつ、その重みを待つ時間を減らそうとする点にある。
チームの35Bモデルカードでは、生成されるトークンごとに専門家を選ぶトークン単位のルーティングを維持するデプロイ手法が説明されている。また、約3 GBのメモリを使用し、iPhone 17 Pro Maxで毎秒13トークン超を達成した別の結果も報告している。
この先行するスマートフォンでの結果は、新しいiPhone 18 Pro Maxのベンチマークとは区別して扱うべきだ。対象となるデバイスと文書化された構成が異なるためである。両者を同一視すれば、公開された証拠が実際に裏付ける内容が不明瞭になる。
LESはLookahead Expert Schedulingの略で、次のモデル層が必要とする専門家を予測するシステムだ。その目的は、読み込み作業を前倒しすることにある。この予測は計算の段取りに役立つが、モデルによる最終的な専門家選択を置き換えるものではない。
アプリケーション開発者の観点から、このデプロイ上の問題を考えてみよう。アシスタントには回答を生成するのに十分な計算能力があっても、次の処理に必要な重みがなければ遅くなり得る。計算処理がデータ待ちになっている場合、演算を高速化しても効果は小さい。
すべての専門家を作業メモリに保持すれば、その種の遅延は避けられるが、より多くのメモリが必要になる。重みをストレージに置けば常駐メモリは減るが、読み込み作業が発生する。利用可能な専門家を制限すればアクセスは単純化される一方、回答を生み出す計算を変えてしまう可能性がある。
MiniCPMが提案する方法は、専門家プール全体へのアクセスを維持し、重みが届くタイミングを管理するものだ。これにより、異なるエンジニアリング上の目標が生まれる。すでに進行中の計算の間に、必要なデータを十分に到着させられるかが問われる。
このため、このスケジューリング発表はモデルサイズの見出しを超えて注目に値する。スマートフォン上の大きなパラメータ数だけでは、応答性についてほとんど何も語れない。読み込みと実行の配置が、その能力を対話型アプリケーションで活用できるかを左右する。
ユーザーにとって、この違いは出力の連続性として現れる。テキストの生成を始めた後に何度も停止する回答は、より安定して出力される回答とは異なる印象を与える。平均生成速度はその体験の一部を捉えるが、遅延の連なりも重要だ。
したがって実用上の意義は、モデルを実行するソフトウェアであるランタイムにかかっている。モデルの重みだけでは、すべての互換アプリケーションが同じ動作を再現することは示せない。関連するデプロイは、モデル、ストレージ構成、スケジューリング実装、数値構成を組み合わせたものとなる。
この複合システムこそが、主張の実際の対象だ。リリースに付随するあらゆる最上級表現を受け入れずとも、検証の具体的な基盤を提供する。
専門家選択の維持がモバイルデプロイの近道に圧力
直接的な圧力は、利用可能な専門家プールを狭めることで速度を得るデプロイ戦略にかかる。
メモリと読み込み時間がアプリケーションの制約を支配する場合、専門家の制限は魅力的に見えることがある。利用可能な重みが少なければ、必要になり得る読み込みも少なくなる。難しいのは、専門家の利用可能性に影響する最適化が、モデルの振る舞いにも影響し得ることだ。
このため開発者は、明示的な判断を行う必要がある。元のモデルが実行される方法を最適化しているのか、それとも変更された計算経路をデプロイしているのか。どちらの手法も評価に値するが、品質に関する主張には異なる証拠が必要となる。
スケジューリングシステムは、有用な分離を約束する。開発者は、モデルの選択メカニズムをそのまま維持しながら、実行効率を検証できる。これにより、変更が速度、回答品質、あるいはその両方に影響するかを特定しやすくなる。
また、小型モデルとの比較も変わる。メモリに常駐できるコンパクトなモデルは、より単純なデプロイ経路を提供できる。より大きなストリーミングモデルは、関連タスクでのより良い結果によって、追加のストレージとランタイムの複雑さを正当化する必要がある。
どちらの方法も、パラメータ数だけで優位に立つわけではない。見慣れた文書から短い項目を抽出するアプリケーションでは、より広範な推論能力よりも予測可能なレイテンシーが有益かもしれない。未知の図表を解釈するシステムでは、回答品質がより重視される可能性がある。
これらはデプロイのシナリオであり、MiniCPMについて検証済みの顧客成果ではない。同じベンチマークが異なる製品判断を支え得る理由を示している。価値は、ユーザーが何を尋ね、アプリケーションがどのような失敗を許容できるかに左右される。
歴史的な比較も示唆に富む。Appleのフラッシュベース推論研究は、選択的な読み込みとより効率的なストレージアクセスを通じ、利用可能な作業メモリを超えるモデルを実行する方法を検討した。その手法はLESとは異なるが、共通する制約はデータ移動にある。
この先例は、新規性の主張を適切に限定する。フラッシュストレージを用いてより大きなモデルを支える方法には、確立された研究の歴史がある。ここで検討される具体的な貢献は、専門家の必要性を予測し、その実行を調整する点にある。
モバイルハードウェアチームにとって、この枠組みは注意をメモリとストレージの経路全体へと向け直す。計算能力は引き続き重要だが、デプロイは演算能力の限界に達する前に停止することがある。プロセッサを単独で評価すると、その可能性を見落とす。
アプリケーションチームにとっては、調達上の問いが生じる。計算仕様が魅力的なデバイスでも、意図したランタイムとワークロードに対するテストが必要だ。ストレージの挙動、利用可能なメモリ、動作条件が、アプリケーションの性能特性の一部となる。
したがって競争上の含意は、宣言された市場での勝利ではなく、エンジニアリング上の要求である。代替案は、同等の条件下で品質、応答性、リソース使用量をどのように両立させるかを示す必要がある。MiniCPMにも同じ基準が求められる。
このスケジューリング手法が信頼性高く再現されるなら、専門家の制限を自動的な必然として正当化することは難しくなる。それは、品質コストと性能上の利点を可視化すべき設計上の選択であり続ける。
MiniCPM LES、読み込み遅延を隠しながらルーティングを維持する仕組み
LESは予測を使って計算を準備する一方、実際に実行する専門家の選択はルーターが引き続き担う。
公式の専門家スケジューリング文書では、層をまたぐ予測に続いてプリフェッチを行い、実行が必要な重みに到達する前に、必要となる可能性が高い重みを読み込む仕組みが説明されている。正しく予測された専門家は先に実行される。その他に必要な専門家は、その計算と並行して読み込まれる。
したがって予測を外した場合に生じるのは、必要な専門家を省略する許可ではなく、追加の待ち時間だ。この違いが、チームによるlosslessスケジューリングの主張を説明する。それは、予測が常に最終的な選択と一致すると仮定することではなく、専門家の参加を維持することに関する主張である。
文書では、重みを連続的に配置すること、散在する読み取りを減らすこと、層ごとに混合精度を適用することも説明されている。数値精度を下げた表現で重みを扱う量子化は、ストレージと転送の需要を抑える。これらの変更は、読み込み問題の異なる部分に対処する。
この仕組みはいくつかの有用な示唆を与えるが、実際のデプロイで測定する必要がある。予測精度だけでは、総合的な効果を決められない。正しい予測でも、到着が遅すぎれば待ち時間をほとんど減らせない可能性がある。
同様に、適切な重みを早く読み込むことが役立つのは、デバイスが有用な作業を重ね合わせられる場合に限られる。別のリソースが制約要因になれば、同じスケジューラーでも得られる効果は異なる。性能は、完全な実行環境に属するものだ。
不正確な予測にも注意が必要だ。不要なものをプリフェッチすれば、専門家の選択を変えなくてもリソースを消費する。有用な問いは、代表的なリクエスト全体で、回避できた遅延がその追加作業を上回るかどうかである。
このため、ワークロードの選定が評価の中心となる。ベンチマークでは、スケジューリングがうまく機能する状況と、苦戦する状況の両方を明らかにすべきだ。こうした分布を示さない平均値は、アプリケーションの信頼性に影響するパターンを隠してしまう可能性がある。
たとえば、文書アシスタントは、あるセッションでは見慣れたレイアウトに遭遇し、別のセッションでは珍しい視覚構造に遭遇するかもしれない。評価者は、こうした変化が応答性を変えるかを調べるべきだ。この仕組みは、その問いを立てる理由を与えるが、答えを確立するものではない。
このアプローチは、読者が容易に混同し得る二つの予測も分けている。専門家のプリフェッチは、今後の計算がどの重みを必要とするかを予測する。後の検証のために出力トークン候補を下書きする投機的デコーディングは、生成プロセスそのものに関わる。
MiniCPMは、投機的コンポーネントとしてDSparkを統合している。これによりスループットを改善する別の機会が生まれるが、帰属の重要性も増す。LES全体に広く帰される高速化には、スケジューリング、ストレージアクセス、数値表現、トークンの下書きによる寄与が含まれている可能性がある。
開発者にとって、概念的な利点は十分に検証可能だ。必要な作業を維持したうえで、準備と実行を再配置し、アイドル時間を減らす。実務上の課題は、その再配置をデバイスの実際の制約下で有益なものにすることにある。
これは、大きなモデルが小さなメモリ割り当てに単に収まるという主張よりも、強く具体的な提案だ。実装が対象とする待ち時間と、それが維持するとするモデルの振る舞いを特定している。
毎秒20.51トークンという結果は複数の最適化を組み合わせたもの
公開されたスマートフォンでの結果は、先読みスケジューリング単独ではなく、最適化スタック全体に属する。
OpenBMBのオンデバイス・ベンチマークでは、iPhone 18 Pro Maxのデバイスメモリは12 GBと記載されている。詳細な結果では、ベースラインは毎秒3.38トークンから始まる。先読みスケジューリングでは6.57に達し、さらにスケジューリングと読み込みに変更を加えると11.34に達する。
混合精度量子化により、報告値は毎秒17.16トークンへ上昇する。DSparkを追加すると毎秒20.51トークン、すなわちベースラインの6.07倍となる。対応する完全最適化済みのiPad Pro M4での結果は、毎秒17.39トークンである。
これらの数値は、複数の段階が結果に寄与しているという具体的な解釈を裏付ける。一方で、加速のすべてを専門家予測だけの単独効果として説明する根拠にはならない。見出しの数値を再現しようとする開発者には、各段階に関する設定情報が必要となる。
ベースラインにも同等の検証が必要である。これらの最適化を含まない実装との比較は、その実装に対する改善を示す。しかし、それだけであらゆる代替ランタイムやデプロイ方法より優れていることが自動的に確立されるわけではない。
これはシステム・ベンチマークでよくある解釈上の問題である。大きな相対的改善は、控えめな出発点と両立し得る。読者には絶対値の結果と、何が変更されたのかを明確に説明することの両方が必要だ。
端末の総メモリは、モデルが報告する動作メモリ使用量とは別の問いに答える。デバイス容量はハードウェア環境を示す。アプリケーションメモリは、測定方法に左右されつつ、その環境内で消費されるリソースを示す。
永続ストレージは別の観点を加える。公式の量子化モデルファイルでは、Q4_K_Mバリアントは21.2 GBと記載されている。この記載は、常駐メモリ使用量が小さいという主張を、同じく小さいダウンロード容量だと解釈すべきでない理由を示している。
ファイル一覧は、この正確なアーティファクトが公開済みのすべてのベンチマークを生み出したことを立証するものではない。ベンチマークと正確な重みファイルを対応付ける作業は依然として必要だ。そうしなければ、開発者は同じモデル名のもとで異なる数値表現を比較するリスクがある。
この区別は製品に直接的な影響を及ぼす。モバイルアプリケーションは、インストール、モデル更新、利用可能なストレージ、起動時の挙動を考慮しなければならない。準備完了後に効率よく生成できる構成でも、生成開始前の体験が許容可能である必要がある。
デコード速度は、デコードが始まった後の出力生成を測る指標である。画像を送信してから有用な回答を受け取るまでの全時間として扱うべきではない。入力処理と準備には、それぞれ別の測定が必要となる。
同様に、トークンは固定数の英単語ではなく、モデルが用いる単位である。スループットの数値は、明示された条件下での技術的比較を提供する。それが普遍的な読書体験や会話体験に直接変換されるわけではない。
したがって、報告された結果には意味がある一方で、適用範囲には限界がある。これは、チームが指定ハードウェア上で自らの統合実装が到達すると述べる性能を示している。現実的なアプリケーションセッションへどの程度転用できるかは、独立検証によって判断されるべきだ。
「ロスレス」には明確な基準点が必要
専門家ルーティングの維持は限定的な技術的主張を支えるが、あらゆる精度設定、タスク、デバイスにおいて同一の挙動を保証するものではない。
スケジューリングの説明から導ける最も強い解釈は、選択に関するものである。必要な専門家は引き続き選択対象となり、予測の失敗によって計算から除外されることはない。この特性は、利用可能な専門家プールを制限することで生じる特定の品質リスクに対応する。
完全なモバイルデプロイメントは、さらに別の問いを生む。量子化は重みの表現を変える。そのため適切な品質比較では、どの参照モデルと数値構成をベースラインとして定義するかを明らかにする必要がある。
ルーティングを維持するという主張を、高精度モデルのあらゆる出力と一致するという主張に暗黙のうちに置き換えるべきではない。これらは異なる性質に関する主張である。評価者には、それぞれに適した証拠が必要だ。
同様に、生成手順を維持することは、その回答が正しいことを確立するものではない。モデルは意図どおりに動作していても、グラフを読み違えたり、要求を誤解したり、詳細を作り出したりする可能性がある。ランタイムの忠実性とタスク精度には、別個の評価が必要となる。
本分析で検討した情報源を通じて、見出しとなったスマートフォン・ベンチマークの独立再現は確認されなかった。この制約は報告結果を無効にするものではない。ただし、読者がそこからどの程度自信を持って一般化できるかを左右する。
同じ注意は、同社による「初」の表現にも当てはまる。優先性を確立するには、定義された比較対象と一貫した定義が必要だ。スムーズ、リアルタイム、ロスレスといった用語は、普遍的な順位付けを支える前に測定可能な境界を必要とする。
リアルタイム性は特にアプリケーションに依存する。ストリーミングされる文章回答では、ライブ対話を妨げるような遅延でも許容される場合がある。技術的なスループット閾値だけで、すべてのインターフェースへの適合性を確立することはできない。
より長いセッションでは、別の重要なテストが必要になる。評価者は、繰り返しの要求、変化するデバイス状態、競合するアプリケーションの活動を測定すべきだ。これらは運用上の持続性に関する問いであり、報告された実装が必ず劣化することの証拠ではない。
回答品質のテストには、ユーザーが認識できる失敗を含めるべきである。仮想的な経費ワークフローでは、抽出された項目が領収書と一致するかを確認することになる。文書分析では、説明が提供されたページに根拠を置き続けているかを確認することを意味する。
より広い知識ワークフローには、回答に関連する保存済み資料を選ぶプロセスである検索も加わる。パーソナルナレッジベースを比較する読者は、この層をモデル生成速度とは分けて評価すべきだ。誤ったソース文書を選べば、出力が速くても補うことはできない。
ローカル実行にも慎重な解釈が必要である。これは入力をデバイス上で処理するデプロイメントの選択肢を提供するが、完成したアプリケーション内のすべてのデータフローを説明するものではない。何をローカルに保持するかは、アプリケーションアーキテクチャによって決まる。
これらの区別により、主張は検証可能になり、分析はより強固になる。もはや問われるのは「ロスレスなモバイルAI」がもっともらしく聞こえるかどうかではない。どの挙動が変わらないのか、システムがどのリソースを消費するのか、そしてどの測定が結果を示すのかである。
MiniCPM LESは、専門家の選択を維持しながら読み込み遅延を減らす具体的なスケジューリング提案を、開発者に提供している。受け入れるかどうかは、再現可能な結果とアプリケーションレベルの品質確認に基づくべきであり、各結論は実際に測定された性質に結び付ける必要がある。
このアプローチが製品へ転用できるかを示す3つの兆候
次に必要な証拠は、この順序で再現性、継続利用、実装の利用可能性を結び付けるべきである。
最初の兆候は、識別可能なアーティファクトと設定を伴う独立再現である。今後数か月に有用な結果には、正確なモデルファイル、ランタイムのリビジョン、プロンプト、測定範囲が含まれるだろう。これらの詳細があれば、他の開発者も同じ主張を検証できる。
再現試験では、最高記録だけでなく報告すべきだ。チームが対話型サービスを計画する際には、要求ごとの変動が重要となる。一貫した結果は、公開された速度が実用可能な構成を表しているという信頼を強める。
より低い結果は、即座に退けるのではなく解釈を要する。異なる重みファイルや設定が差を説明できる可能性がある。一致した条件下で再現可能な不一致が確認されれば、元の性能主張をより直接的に弱めることになる。
2つ目の兆候は、代表的なワークロードでの継続的なテストである。評価者は、入力送信から回答完了までの完全な要求を追跡すべきだ。また、より速くても誤った出力には製品価値がほとんどないため、応答性と並行して品質も確認すべきである。
ここでモバイルMoE推論は、技術デモからアプリケーション上の意思決定へと移行する。有用な評価は、繰り返される文書または画像の要求中にも利点が持続するかを示すだろう。また、より小さな常駐モデルの方が望ましい条件も特定するはずだ。
複数デバイスでの結果は、適用範囲を明確にする。追加ハードウェアでも同様の挙動が見られれば、より広い適用可能性を裏付ける。結果が狭い構成に集中するなら、より特化したデプロイ機会を示すことになる。
3つ目の兆候は、必要な最適化スタックを利用しやすく統合できることだ。開発者には、公開済みの重みからベンチマークの背後にある実装へ至る明確な道筋が必要である。ドキュメントは、必要なランタイムとアーティファクトの選択を曖昧さなく示すべきだ。
この利用可能性が重要なのは、互換性と同等の性能が別々の成果だからである。サポート対象のモデルを読み込めても、アプリケーションがすべてのスケジューリングおよびストレージ最適化を有効化するとは限らない。完全な構成を再現することが、重要な到達点となる。
明確な統合は、これがモバイルアプリケーション向けの再利用可能なインフラであるという根拠を強める。根底にある技術が健全であっても、断片的な手順や構成依存の結果は導入を難しくする。
パイロットを検討するチームにとって、適切な次のステップは、実際のユーザー要求に近い資料を使った範囲を限定した評価である。追加されたモデル容量が回答を改善するかを明らかにする、難しい文書や扱いにくい画像を含める。リソース使用量と正確性に加え、ユーザーが体験する待ち時間を測定する。各最適化を評価する間は参照構成を固定し、改善の要因を明確に保つ。MiniCPM LESが注目に値するのは、専門家の選択を維持しつつ読み込み遅延を削減する具体的な方法を示しているためだ。見出しの速度を前提に開発を進める前に、同じ構成が意図するモバイルワークフロー全体で信頼できる回答を提供するかを問うべきである。
