Swiftletは低RAM使用量でMacとiPhone上で35Bおよび80B Qwenモデルを可能にする

概要

SwiftletはSwift + Metalランタイムで、普通のAppleデバイス上でQwen3‑Next‑80B‑A3BおよびQwen3.6‑35B‑A3Bの混合専門家モデルを実行します。各モデルの小さな密コアのみをメモリに常駐させ、必要に応じてストレージからルーティングされたエキスパートの重みをストリーミングすることで、約2.5 GBのRAMを持つiPhoneで35Bモデルを実行し、約4.3 GBのRAMを持つMacで80Bモデルを実行できます。

エキスパートストリーミングの仕組み

核心的な洞察は、各トークンがモデルのパラメータの約3 Bしかアクティベートしないということです。各レイヤーで、モデルはトークンを少数のエキスパートにルーティングします（80Bでは512中10、35Bでは256中8）。Swiftletは以下を行います：

密な重み（アテンション、DeltaNet射影、ルータ、共有エキスパート、埋め込み）をメモリに常駐させます：4ビット量子化時に約1.3 GB（35B）および約2.5 GB（80B）。
数万のルーティングされたエキスパートを固定サイズのエキスパートスロットに再パックし、LFU＋リカレンシーによる境界プールでホットエキスパートをキャッシュします。キャッシュサイズは速度にほとんど影響を与えません。なぜならAppleのSSDがミスを吸収するからです。
Metalを使用してランタイムコンパイルシェーダーでフォワードパス全体を実行するため、ビルド時にMetalツールチェーンは必要なく、同じバイナリがiOSでも動作します。
レイヤーの75％でゲート付きDeltaNet線形アテンションを使用し、固定サイズのリカレント状態を維持し、コンテキスト長に関わらず増大するKVキャッシュを回避します。

パフォーマンスとリソース使用量

モデル	ディスクサイズ	ピークRAM	デコード速度 (M5 Mac)	iPhone 17速度
Qwen3.6‑35B‑A3B (4‑bit)	18 GB	2.6 GB	7‑11 tok/s	~1 tok/s
Qwen3‑Next‑80B‑A3B (4‑bit)	42 GB	4.3 GB	4.5‑5 tok/s	測定されていない
これらの数値はプロジェクトのREADMEから得られました。低RAMフットプリントは、密コアと小さなアクティブエキスパートセットのみが常駐し、残りの重みが必要に応じてSSDからストリーミングされることによって達成されます。

使い始め方

MacでSwiftletを試すには：

リポジトリをクローンし、リリースバイナリをビルドします：

git clone https://github.com/leonickson1/Swiftlet.git && cd Swiftlet
swift build -c release

Hugging Faceからモデルコンテナをダウンロード（再開可能）：

.build/release/swiftlet-repack \
  --from-hf Leonickson/Qwen3.6-35B-A3B-qpack \
  --output ~/models/qwen3.6-35b.qpack

または80Bモデルの場合：

.build/release/swiftlet-repack \
  --from-hf Leonickson/Qwen3-Next-80B-A3B-qpack \
  --output ~/models/qwen3-next-80b.qpack

チャットセッションを実行します：

.build/release/swiftlet chat ~/models/qwen3.6-35b.qpack \
  "Who wrote One Hundred Years of Solitude?" \
  "What language did he write it in?"

統計情報付きでテキストを生成します：

.build/release/swiftlet generate ~/models/qwen3.6-35b.qpack \
  --gpu --chat --prompt "Explain expert streaming in one paragraph."

OpenAI互換サーバーを起動（ループバックのみ）：

.build/release/swiftlet-server --model ~/models/qwen3.6-35b.qpack --port 8080

同じswiftlet-repackコマンドはraw MLXチェックポイントを再パックできます（--from-hf mlx-community/...または--source /path/to/checkpoint）。要件：Apple Silicon、macOS 14+またはiOS 17+、および空きSSD領域（約18 GBが35B、約42 GBが80B）。

使用オプション

Swiftletはライブラリ第一に設計されており、主に4つの使い方があります：

Swiftパッケージ – SwiftletCoreを任意のmacOSまたはiOSアプリに追加し、SwiftletSessionを使ってストリーミングデルタ付きチャット、会話キャッシュ、サンプリングコントロール、メモリ圧力処理を行います。
コマンドラインインターフェース – swiftlet chatおよびswiftlet generateをローカル使用およびベンチマークに、swiftlet-repackをMLXチェックポイントからコンテナを構築し、Hugging Faceからのストリーミングと再開機能を含めます。
OpenAI互換サーバー – swiftlet-serverがループバックでchat‑completions APIを実装し、OpenAI互換エンドポイントと通話する任意のUIがストリーミングローカルモデルを使用できるようにします。
iOSアプリ – App StoreのPriv AIアプリがSwiftletCoreをストリーミングモデルエンジンとして組み込みます。ユーザーは設定 → 実験的モデルから35Bモデルをダウンロードし、サーバーを介さずにオンデバイスでチャットできます。アプリのソースはleonickson1/localLLMにあります；自分でビルドするには、Swiftletリポジトリをそれを横にswiftletとしてクローンし、Xcodeプロジェクトを開く必要があります。

正しさの検証

フォワードパスの各レイヤー（ゲート付きDeltaNet再帰、ゲート付きGQAアテンション、スパースMoEルーティング）は、FP32およびint4量子化形式の両方でmlx‑lm参照実装と照合して検証されます。インクリメンタルデコードは全シーケンス処理と照合して確認されます。Metalカーネルは正確なCPU参照とテストされ、高速およびスカラーGPUカーネルの両方が同一の出力を生成します。コンテナはソースチェックポイントとバイトレベルで検証可能であり、ストリーミング配置はモデルの意味を変更しません：エキスパートはキャッシュからでもディスクからでも同じ答えを返します。

TurboFieldfareとの関係

Swiftletは、TurboFieldfareがMac上のGemmaで示したエキスパートストリーミングのアイデアを基盤としています。いくつかの公開された設計教訓を採用しています：preadによるエキスパートストリーミングを境界スロットプールへ、LFU＋リカレンシーによる削除、固定ストライドでのエキスパートパック（1フェッチ＝1リード）、ダウンロードバイトを直接最終コンテナ位置へルーティングによるインストール、ランタイムでのシェーダーコンパイルです。ただし、Swiftletはゼロから書き直されています（SwiftとMetalで約10k行）し、いくつかの点で異なります：

Qwenハイブリッドスタック（ゲート付きDeltaNet線形アテンション、ゲート付きGQA、共有エキスパートを伴う高スパースMoE）をサポートし、それに対しTurboFieldfareは古典的な密Gemmaアーキテクチャを対象とします。
MetalでMLXアフィンint4/int8グループ量子化を実装し、64ビットオフセットを持つバイトアドレスカーネルを使用してマルチギガバイトシャードを扱い、協力的simdgroup GEMV高速パスと明示的ハザード管理を行います。
すべてのカーネル変更を守る検証済みCPU参照実装とフィクスチャインフラストラクチャを含みます。
.qpackコンテナとリパッカー、スタールリカバリとダウンロードキャンセルを備えた再開可能なHugging Faceストリーミングインストーラーを提供します。
思考および非思考のQwenバリアントを扱うチャットセッションレイヤーを追加し、プレゼンスおよび周波数ペナルティでのサンプリング、最小長および文完了ストップ、デルタプリフィルによる会話キャッシュ、iOSメモリ圧力調整を行います。
アプリエンジン統合を含むエンドツーエンドのiPhoneサポートを提供します。プロジェクトは、colibrìからのキャッシングと配置ポリシーへのインスピレーションを認め、mlx‑lmを正確性の参照として全体で使用しています。SwiftletはClaude Codeとの共同作業で構築されました。

コミュニティフィードバックと制限

Hacker Newsの投稿へのコメントは、熱意と懸念の両方を示しています：

楽観的見解：一部のユーザーはこれが消費者デバイスで大規模モデルを効率的に実行する未来への進歩だと見ており、あるコメント者は「これが進歩のあり方だ」と述べ、別のユーザーは「2.5 GB RAMでiPhone上で35Bを1 tok/sで動かす…これがオンデバイス推論の未来だ」と述べています。
ストレージの摩耗と速度への懸念：いくつかのユーザーは頻繁なエキスパートストリーミングがSSDの摩耗を早め、デコード速度が低い（例："1時間に10トークン？これらのディスワップ方法はすべて同じ欠点があります－ドライブを早めに壊し、極端に遅い。"および"プリフィルがボトルネックになり…M5で10kトークンを処理するのに半時間かかるのは…あまり良くない。"）と警告しています。
RAM使用量の調整可能性への欲求：32 GB Macを持つユーザーは、RAM使用量を設定可能にして余分なメモリを高速実行に活用できるかどうかを尋ねています。
Claude Codeコラボレーションへの質問：コメント者は「Claude Codeとの共同作業で構築されました」という主張がAnthropicとの正式なパートナーシップを示すのか、それとも単なるAI支援開発のメモなのか疑問を呈しています。
他のプロジェクトとの比較：iPhone上での400Bモデル主張などの類似のストリーミングウェイト努力へのリンクや、BigMoeOnEdgeなどの代替実装への参照が共有されました。
プラットフォーム固有の問い合わせ：Android/Linux/Windowsサポートおよびこのアプローチの他プラットフォームへの移植可能性について尋ねるユーザーがいました。これらの発言は、エキスパートストリーミングのトレードオフを反映しています：RAMフットプリントは低いですが、SSDトラフィックとレイテンシが増加し、特にプリフィルフェーズにおいて顕著です。

結論

Swiftletは、メモリに小さな密コアのみを保持し、ルーティングされたエキスパートをストレージからストリーミングすることで、Mixture‑of‑Expertsモデルを消費者向けAppleデバイスで実行できることを示しています。このアプローチにより、約2.5 GB RAMのiPhoneで35B Qwenモデルを、約4.3 GB RAMのMacで80B Qwenモデルを実験的なオンデバイスチャットに適したトークン毎秒レートで動作させることができます。この方法はRAM要件を削減しますが、ボトルネックをストレージ帯域幅と摩耗に移し、今後のキャッシュ戦略、プリフェッチ最適化、およびハードウェアアクセラレートされたエキスパートアクセスへの余地を残しています。