転載に関する注記: 著者の許可を得て、Versunによるオリジナルの中国語ベンチマークから転載しています。 テストデータ、結論、一人称の体験は著者のものです。 Nowledge Labsは、この編集と要約を加えた英語翻訳、フォーマット、用語の整合、および現在のドキュメントへのリンクを提供しました。
短い答え
Qwen3.6 35B-A3Bを常駐させてください。 Gemma 4 26B-A4Bはオンデマンドでロードします。 ウォームタスクの速度よりもメモリが重要な場合は、Gemma 4 12Bを選んでください。
意思決定ガイド
パラメータ数ではなく、ロードパターンで選びましょう。
意外な結果はトレードオフです。12Bはメモリを節約しますが、ウォームタスクでは2.8倍遅くなります。26Bと35Bモデルはほぼ同じRSSを使用し、ウォームタスク時間もほぼ同じです。コールドロード戦略が両者を分けます。
- 常駐させる
Qwen3.6 35B-A3B MLX
検証した64 GBのMacで、読み込み済みのタスクと生成が最速でした。
- 2.64秒 · 78.1 tok/s
- 必要なときに読み込む
Gemma 4 26B-A4B MLX
モデル未読み込みの状態では、Qwenの14.19秒より待ち時間が短くなりました。
- 読み込み+タスク 10.85秒
- メモリを節約する
Gemma 4 12B GGUF
大きい2モデルより約7 GiB少ない一方、読み込み済みのタスクは7.38秒かかりました。
- 合計RSS 10.65 GiB
3つすべてが、1つの固定された9項目のメモリタスクを3回実行して3/3を獲得しました。これは一般的な品質の同等性ではありません。16/24/32 GBのガイダンスは、この64 GB RSSサンプルから推測されたものであり、それらのマシンで測定されたものではありません。
なぜ今、ローカルモデルを再テストするのか
Nowledge Memは当初からLocal Firstです。 初期のバージョンでは、アプリに同梱された小さなモデルでメモリを処理できました。 バージョン0.5では、より長く要求の厳しいバックグラウンド作業が導入されました。 会話の整理、変更のマージ、競合の処理、そしてAI NowとTimelineのサポートです。 4Bモデルではすべてのタスクをカバーできなくなり、サブスクリプションやbring-your-own-keyプロバイダーが日常的な構成として一般的になりました。
バージョン0.10以降、ローカルランタイムは初期のM1 Mac環境を超えて、デスクトップおよびヘッドレスLinuxに拡大しました。 公式DockerイメージはCPU、CUDA、Vulkanをカバーしています。 同梱のマルチモーダルモデルは、すでにLibraryのドキュメント処理にビジョンを使用しています。 MemはLemonade、Ollama、LM Studioもサポートしています。 コミュニティコントリビューターのabnは、Lemonade統合に多大な作業を行いました。
Versunは一般的なベンチマークスイートを省略しました。 彼はNowledge Memのメモリ整理、更新、ノイズフィルタリング、長文コンテキストのタスクを使って、より狭い問いに答えました。 すなわち、品質、待ち時間、メモリ負荷を踏まえて、今日ローカルで何を動かすべきかという問いです。
なぜ私はNowledge Memをローカルモデルに移したのか
私は最近、Nowledge Memのメモリ処理をクラウドモデルからローカルモデルに変更しました。 理由は単純でした。 私はさまざまなトークンプランを購読しているため、Memに設定されたプロバイダーが変わり続けていました。 あるプランが切れるとインテリジェント処理が停止し、何日も気づかないことがありました。
ローカルモデルはクォータの問題を取り除きます。 残る問いは、どのモデルがNowledge Memに適しているかでした。
私のテストマシンとランタイムは次のとおりです。
- M4 Proと64 GBのユニファイドメモリを搭載したMac mini
- LM Studio
0.4.19+2 - GGUFランタイム:llama.cpp
2.25.2 - MLXランタイム:
1.10.1
私はすでに簡単な最初の比較を公開していました。 Nowledge LabsのWeyが、より多くのコンテキスト、メモリ測定、再現可能な説明をこのフォローアップスレッドで求め、それが以下のより完全なテストにつながりました。
制御されたメモリテスト
すべての実行で同じ設定を使用しました。
- コンテキストウィンドウ:32,768トークン
- Temperature:0
- Top P:1
- Thinking / reasoning:オフ
- GPUオフロード:最大
- 同時リクエスト:1
- 並列モデルスロット:LM Studioのデフォルトである4
- 最大出力:700トークン
システムプロンプトは、モデルに対して、引き続き有用であり続ける情報のみを保持し、一時的なチャットと古い事実および現在の事実を区別し、一度きりの天気や気分を拒否し、厳密なJSONを返すよう指示しました。
会話には6つの永続的な項目が含まれていました。
中国語の好み、古いagent_browserバックエンド、そのopencliによる置き換え、20項目の自動化制限、公開前の確認を要求するルール、および置き換えられた決定を保持するという好みです。
また、2つのノイズも含まれていました。
暑い天気と、コップ一杯の水を飲んだことです。
出力は、次の9つのチェックをすべて満たした場合にのみ合格しました。
- ちょうど6つのメモリ。
- 中国語の好み。
- 古い
agent_browserの決定。 - 古い決定が
supersededとマークされている。 - 新しい
opencliの決定がcurrentとマークされている。 - 20項目の制限。
- 公開前の確認ルール。
- 置き換えられた決定を保持するという好み。
- 天気や飲水に関するメモリがない。
各モデルは同じタスクを3回実行しました。 私はJSONの妥当性、合計時間、最初のトークンまでの時間、生成速度、および9つの品質条件を確認しました。 3つのモデルすべてが、この固定プロンプトの3回の実行すべてに合格しました。 この結果は、モデル間に一般的な品質の同等性があることを証明するものではありません。
表はメモリタスク時間の中央値を報告しています。 2回目と3回目の実行はLM Studioのプロンプトキャッシュの恩恵を受けたため、「メモリタスク」は常駐モデルの通常の速度を表し、コールドスタートではありません。
長文コンテキストの検索
私はまた、長いプロジェクトログを生成し、この永続的な事実をその中央に隠しました。
プロジェクトコードはQinglan-7391で、公開にはユーザーの確認が必要です。
同じ無関係なログ文が、その前後に180回ずつ現れました。
プロジェクトコードのみを返すよう求められたとき、すべてのモデルがQinglan-7391と回答しました。
以下の「長文入力TTFT」は、そのテキストを受け取ってから最初のトークンを生成するまでの遅延を測定しています。
ピークRSSの測定
メモリサンプラーは、すべてのモデルをアンロードし、推論プロセスの終了を待ち、アイドル状態のLM Studioベースラインを記録し、その後、モデルのロード、1.5秒のアイドル、3つのメモリタスクの実行、長文コンテキストタスクの実行、さらに0.8秒の観察の間、macOSのps RSSを0.08秒ごとにサンプリングしました。
私は推論プロセスと、LM Studioとその子プロセスの合計の両方を記録しました。 共有ページは複数回カウントされる可能性があるため、合計RSSはモデルの比較には有用ですが、空きシステムメモリが実際に減少する正確な量ではありません。
結果
| モデル | ディスク | コールドロード | メモリタスク | 生成 | 長文入力TTFT | モデルピークRSS | LM Studio合計ピークRSS | 品質 |
|---|---|---|---|---|---|---|---|---|
| Gemma 4 12B GGUF | 7.15 GB | 3.82 s | 7.38 s | 29.4 tok/s | 36.79 s | 9.33 GiB | 10.65 GiB | 3/3 |
| Gemma 4 26B-A4B MLX | 15.64 GB | 8.17 s | 2.68 s | 70.6 tok/s | 13.83 s | 16.38 GiB | 17.69 GiB | 3/3 |
| Qwen3.6 35B-A3B MLX | 20.43 GB | 11.55 s | 2.64 s | 78.1 tok/s | 9.87 s | 16.42 GiB | 17.72 GiB | 3/3 |
3つすべてが6つの永続的なメモリを抽出し、一時的な詳細を拒否しました。 このテストでは意味のある品質差は示されず、速度とメモリ使用量がそれらを分けました。
なぜ35Bは12Bより速かったのか?
Qwen 35B-A3BとGemma 26B-A4Bはmixture-of-expertsモデルです。 モデル全体は大きいものの、各トークンには専門家の一部のみが参加します。 Gemma 12Bは同じ設計を使用していません。
ひとつのイメージとしては、35Bモデルは大企業であり、各会議には約3Bの専門家グループだけを呼び出すようなものです。 毎回35Bパラメータ分の計算を行わなくても、より大きな総容量を持つことができます。
どのモデルを選ぶか?
- ひとつのデフォルト:Qwen3.6 35B-A3B MLX。 常駐時のメモリタスクは2.64秒、生成は78.1 tok/s、長文入力の最初のトークンが最速でした。 コールドロードが11.55秒であるため、常駐させておく場合に最適です。
- 頻繁なロードとアンロード:Gemma 4 26B-A4B MLX。 コールドロードとメモリ処理を合わせて約10.85秒で、Qwen 35Bの14.19秒に対して有利であり、生成も70.6 tok/sと近いままでした。
- 32~64 GBの場合、RSSからの推測:Gemma 4 26B-A4B MLX 4-bit。 異なるタスクでより多くのQwen専門家が起動する可能性がある場合、より保守的なメモリ選択です。 このテストは32 GBマシンでは実行していません。
- 32 GB未満の場合、RSSからの推測:Gemma 4 12B GGUF。 LM Studioの合計ピークは約10.65 GiBで、2つの大きなモデルより約7 GiB低くなっています。 これにより他のデスクトップソフトウェアのための余地が増えますが、このテストは16 GBや24 GBのマシンでは実行していません。
MLXかGGUFか?
これはフォーマットを制御した比較ではありませんでした。 モデルアーキテクチャが異なるため、MLXが常にGGUFより速いと結論づけるのは誤りです。
実用的な結論はより限定的です。 Apple Siliconでは、Gemma 26B-A4BとQwen 35B-A3BのMLXビルドは非常に良好に動作しました。 Mac専用で使う場合はMLXを好み、モデルをWindows、Linux、その他のllama.cppツールにも移す必要がある場合はGGUFを好みます。
結論
私は以前、パラメータ数が少ないほどモデルが速いと思い込んでいました。 このテストは逆の結果を示しました。
- 12Bはメモリ使用量が最も少ないものの、最も遅かった。
- 26B-A4Bと35B-A3Bはより速かった。
これは1台のコンピュータでの1つの制御されたプロンプトです。 Qwen3.6 35Bがすべてのタスクでより賢いことを証明するものではありません。 しかし、私のMacでのローカルメモリ管理においては、現在これが最適です。
Nowledge Labsの見通し
このベンチマークは今日の答えであり、永続的なものではありません。 私たちは、4B前後のモデルがいつか再びメモリ整理、変更のマージ、競合処理、バックグラウンドインテリジェンスをカバーするようになると予想しています。 スケジュールはなく、この3モデルのテストではそれがいつ起こるかを示すことはできません。
ローカルマルチモーダル経路は、すでにLibraryドキュメントにビジョンを使用しています。 PIIフィルタリングと音声会議処理は今後の方向性であり、このベンチマークの出荷済みおよびテスト済みの範囲外です。
自分のモデル呼び出しをオンデバイスに保ちたい場合は、Use Nowledge Mem with fully local modelsに進んでください。
元のディスカッション: