最近Xをブラシすると、NVIDIA DGX Sparkを使用して数十億、数十億の大型モデルを展開する人がよく見られます。
しかし、DGX Sparkは確かに強力で、価格は人々に優しいものではありません。ほとんどの開発者にとって、本当に難しいのは、数年前から使用されているコンピュータです。
最近、ある人がシェアしました。 2022年型第1世代Mac Studio M1 Max / 32GB 上のデプロイ Ling-3.0-tiny INT 4 完全なプログラムだ
もともと、このネチズンは、このマシンが今日の大規模なモデル推論タスクを引き受けるのは難しいと考えていました。
しかし、実際の試験結果は予想外でした。
モデルはチャット、推論Think Mode、ツール呼び出しTool Callingをサポートするだけでなく、Apple Silicon 上でも標準化されている。 64トークン/秒 ローカルチャット、コード支援、翻訳、パーソナルエージェントなどのシナリオでは、安定した生成速度が非常にスムーズになります。
さらに重要なのは、伝統的な意味での“1 Bミニモデル”ではないことです。
Ling-3.0-tinyが注目に値する理由
Ling-3.0-tinyの総パラメータサイズは約 7.9B。
しかし、それが採用するのは MoE Mixture of Expertsスパース·エキスパート·アーキテクチャ。
簡単に言うと
- モデルは約128人の専門家Expertsを保有する
- 各トークンは8人のエキスパートのみをアクティブにする
- コンピューティングに参加する専門家の共有
- 実際に推論に参加するのは 3.3 Bパラメータ
この設計はモデル容量と推論コストを考慮しており、Apple Siliconでは優れた推論速度を達成します。
テスト環境。
ユーザーが使用する機器は以下の通りです。
- Apple Mac Studio（2022）
- アップルM 1 MAX
- 24コアGPU
- 32 GBユニファイドメモリ
- macOS 15.7.4
- アーム64。
Ling-3.0-tinyはより長いコンテキストをサポートしていますが、メモリフットプリントと安定性を考慮するために、このテストではコンテキストをに設定します。 8 Kです。
チャット、コード補完、日常的なエージェントアプリケーションには十分ですが、KVキャッシュが大量のユニファイドメモリを消費し続けるのを防ぐことができます。
全体的な導入アーキテクチャは次のとおりです。
Ling-3.0-tiny INT4
│
支持 Ling 的 Ollama 实验分支
│
MLX Runner
│
Metal / Apple Silicon GPU
│
Ollama API（11434）LingとBailing MoE V 3のサポートはまだOllama実験ブランチに依存しているため、安定版 Ollamaは直接使用されません。
vLLMやSGLangなどの推論フレームワークはNVIDIA CUDA環境に適しており、Apple Siliconでは最適ではありません。
導入前にディスク容量を計画しておく
デプロイメントプロセス全体で最も過小評価されているのは、モデル自体ではなく、ディスクフットプリントです。
最終的なディレクトリの占有率は以下の通りです。
| 内容は、 | サイズは |
|---|---|
| Hugging Face INT4オリジナルウェイト | 5.4 GB |
| Ollamaモデルのインポート | 約5.8 GB |
| Ollamaソースコード、MLX、コンパイル結果 | 約1.3 GB |
| キャッシュと配置 | 数十MB |
プロジェクト全体の最終結果 13 GBです。
一時ファイル、コンパイルキャッシュ、macOS Swapのダウンロードを検討してください。 20 GBです 空きスペース、より推奨 30 GB。 以上です。
見落とされがちな落とし穴：Git
このネチズンが共有した最大のピットストップ体験は、モデルではなくGitでした。
デプロイメントプロセス全体がCodexプロジェクトディレクトリで行われるため、プロジェクトはデフォルトでバージョンスナップショットを有効にします。
モデルのダウンロードが完了すると、Gitはモデルカタログ全体のコピーを保存します。
その結果、約5 GBのモデルはすぐに10 GBに膨張し、システムディスク容量は急速に減少しました。
最終的には、モデルカタログが事前に追加されなかったことが判明した。 .gitignore。
事前の追加：
.cache/
models/
ollama-models/
ollama-ling/Gitオブジェクトを再クリーンアップすると、 .git カタログは残る。 122 KB。
大規模なモデルを展開する準備ができている場合は、このステップを事前に行うのが最善です。
ダウンロードLing-3.0-tiny INT4
Hugging Face INT4ウェイトがあります。
倉庫全体が含まれる：
- 44の文書
- 32個のsafetensors重み付きシャード
ダウンロード中、ユーザーは主に2つの問題に直面しました。
まず、Xetのダウンロード速度が長い間停滞しています。
Xetは終了し、通常のHTTPダウンロードに切り替えた。
第二に、ダウンロード中にタイムアウトが頻繁に発生します。
Hugging Face CLIはブレークポイントの継続をサポートしているため、ダウンロードを続行するにはタイムアウト時間を適切に増やすだけです。
ダウンロード後、モデルが完成したとは直接考えられません。
代わりに3つのテストが行われた。
- 32個の重みがすべて存在するか確認する
- モデルインデックスが完全に参照されているかどうかのチェック
- SHA-256をすべてのシャードで計算
最終結果：
- 異常なファイル：0
- ハッシュ例外：0
- 欠けているピース：0
数 GBのモデルでは、ダウンロード完了プロンプトだけでモデルの完全性を判断するのではなく、少なくともシャード数またはハッシュチェックを完了することをお勧めします。
LingをサポートするOllamaのコンパイル
現在、公式安定版 OllamaはLingを直接実行できないので、実験ブランチを切り替えてコンパイルする必要があります。
この時点で、本当にこのネットユーザーを魅了したのは Metal Toolchainについて。
マシンが設置されました：
- Xcodeより
- コマンドラインツール
しかし、MLXコンパイルはまだ間違っている。
Metal Toolchainは別途インストールする必要があることがわかりました。
さらに厄介なことに、インストールが完了してもMetalコンパイラが見つからないことがあります。
Toolchain Identifierを確認した後、手動で設定する必要があります。
export TOOLCHAINS=...この値はmacOSとXcodeのバージョンによって異なるため、他のユーザーの設定を直接コピーすることは推奨されません。
コンパイルが完了すると、以下が生成されます。
- Ollamaメイン·プログラム
- MLXランナー
- メタル·カーネル
- Dynamic Libraryより
特別な注意が必要です。 ollama 実行可能な文書です
実際にモデルを実行するには、buildディレクトリ内のRunnerと動的ライブラリにも依存します。
INT4モデルの読み込み
システム内の安定版 Ollamaとの混同を避けるために、ユーザーはモデルディレクトリをプロジェクト内に別々に配置しました。
インポートが完了すると、Ollamaは次を出力します。
26947 tensors
479 layers
preserving source quantizationINT4ウェイトは元の量子化フォーマットを保持し、再変換する必要はありません。
最終モデル名は以下の通りです。
ling-tiny-int4:latestGPUが実際に動作していることを確認する方法
これは非常に重要です。
モデルはCPUにサイレントに戻ることができます。
導入が完了したら、次のような情報が確認されているかどうかログを確認できます。
library=Metal
Apple M1 Max
MLX engine initialized device=gpuこれらのログを見ることで、推論プロセス全体がApple GPUで実際に実行されていることがわかります。
M 1 Maxの測定速度
最初のトークンの遅延が結果に影響するのを避けるために、ネチズンはまずモデルウォームアップを行いました。
その後、3回の完全な生成テストが行われた。
試験条件は以下の通り統一されている。
- 背番号は819 2。
- 温度：0。
- Think：閉じる
- 出力長：38 4トークン
最終結果は以下の通り。
| テストテスト | トークン/s |
|---|---|
| 第1ラウンド。 | 64.26 |
| 第2ラウンド | 65.18 |
| 第3ラウンド | 63.67 |
最終的な平均：
64.37トークン/秒
モデルの初回ロードにはおおよそ時間がかかります
6.93秒ごとに
モデルが常駐すると、統一メモリの使用量は以下の通りです。
6.48GB
数年前から発売されているM 1 Maxとしては、これはかなり良いパフォーマンスです。
実際の体験は？
展開が完了すると、このネチズンはモデルをMacの一般的なスクリーンショット翻訳ツールに接続しました。 Bobさん。
BobはOllama APIを直接呼び出すことができるため、追加のクラウドインターフェイスを設定する必要はありません。
実際の経験から判断すると、ローカル翻訳は非常に迅速に応答します。
特にスクリーンショット翻訳のシーンでは、ほぼクリックすると結果が返されます。
オンライン翻訳サービスと比較して、翻訳品質に重点が置かれていますが、ローカルモデルには2つの明確な利点があります。
応答速度が速くなります
2つ目は、すべてのデータがローカルに保持されるため、プライバシーコンテンツの処理に適しています。
また、以下のシナリオでもうまく機能します。
- 毎日の会話。
- ドキュメントの概要
- AIの翻訳
- コード支援
- 地域の知識ベース
- パーソナルエージェント。
全体的な経験は毎日の使用ニーズを満たします。
最後に書く。
展開プロセス全体の観点から、このネチズンの最大の利益は“Macが大きなモデルを実行できるかどうか”ではありません。
Apple SiliconのネイティブAIエコシステムは成熟しています。
MLX、Metal、MoE、およびより効率的な定量化ソリューションの開発により、数年前のM 1 Maxは優れたローカル推論体験を提供しています。
もちろん、ハイエンドのNVIDIA GPUを置き換えることはできず、並列性の高い本番環境には適していません。
しかし、個人開発者には十分です。
- ローカルチャット。
- AIの翻訳
- プログラミングアシスタント
- プライベートナレッジベース。
- パーソナルエージェント。
- プライバシーテキスト処理
予算が限られていて、本物のローカルモデルを体験したい場合は、 Ling-3.0-tiny INT 4 + Apple Silicon + MLX + Ollama試してみる価値のある組み合わせです。
少なくとも、数年前にリリースされたMac StudioがまだネイティブAI推論能力を持っていることを証明しています。