Swiftletという新しいオープンソースプロジェクトは、極端な量子化でQwen3-80BをMacBook上で4.3GBのRAMで動かし、Qwen3-35BをiPhoneでも動かします。このガイドでは、それが開発者にとって実際に何を意味するのか、品質のトレードオフがどこにあるのか、そして今日、ローカルLLMのエンドポイントを実際のプロダクトに組み込む方法を解説します。
Swiftlet（github.com/leonickson1/Swiftlet）は、極端な量子化技術を使ってApple製ハードウェア上で大規模言語モデルを動かすオープンソースプロジェクトです。Macでは4.3GBのRAMでQwen3-80Bを、iPhoneではQwen3-35Bを動かせます。Swiftで書かれており、AppleのMetal GPUフレームワーク向けに最適化されています。
Swiftletは、おそらく2ビット未満という積極的な量子化を使い、モデルの重みを元のサイズよりはるかに小さく圧縮します。80Bパラメータのモデルはフル精度（FP16）でおよそ160GBのメモリを必要とします。4ビット量子化ではおよそ40GBです。Swiftletが達成している4.3GBという水準では、量子化は極端で、パラメータあたり平均およそ0.4ビットです。これはグループ化量子化と重要度重み付けによるビット配分といった手法を使い、最も重要な重みの品質を保っています。
タスクによります。極端な量子化は、モデルの一般的な知識や指示追従能力をよく保持しますが、正確な数値推論、複雑な多段階の論理、長い構造化出力を要するタスクでは性能が落ちます。会話インターフェース、コンテンツ生成、分類では、驚くほど実用的な品質です。コード生成や複雑な推論には、より量子化の浅い小型モデル（4ビットのQwen3-35Bなど）の方が良い結果を出すことがあります。出荷前にベンチマークを取りましょう。
はい。Swiftletはプロンプトを受け取り補完を返すローカルHTTPエンドポイント（通常localhost:8080）を公開します。どんなウェブアプリからもそのエンドポイントを呼び出せます。We.Incでは、わかりやすい言葉でアプリを説明すればすぐに動くReactアプリが得られ、そこにローカルのSwiftletエンドポイントへのfetch呼び出しを追加すれば、数分で機能するプロダクトが完成します。生成されたコードはあなたのものとしてGitHubにエクスポートできるため、特定のプラットフォームに縛られません。
Swiftletは2026年8月3日（Aug 3, 2026）にHacker Newsのトップページに登場し、260ポイントと116件のコメントを集めました。売りは、800億パラメータを持つフロンティア級の大規模言語モデルQwen3-80Bを、MacBook上でわずか4.3GBのRAMで動かせるという点です。35BモデルはiPhoneでも動きます。
要約： Swiftlet（github.com/leonickson1/Swiftlet）は、通常160GBのメモリを必要とするモデルを、極端な量子化によって一般消費者向けのApple製ハードウェアに収めます。品質のトレードオフは確かに存在しますが、予想より小さいものです。APIコストゼロでローカルLLM駆動のプロダクトを作りたいなら、これが最も手軽な始め方です。We.Incのアプリをローカルエンドポイントに接続して公開すれば、ユーザーはモデルがあなたのノートPC上で動いていることに気づきません。
核心となるトリックは魔法ではありません。多くのツールより一歩踏み込んだ量子化です。
計算式： Qwen3-80BはFP16（推論の標準精度）でおよそ160GBのメモリを必要とします。よく使われる4ビット量子化（GGUF Q4_K_M）ではおよそ40GBです。Swiftletは、重要度重み付けによるビット配分を使ったグループ化量子化により、パラメータあたり平均およそ0.4ビットまで押し下げます。最も重要な重み（アテンションヘッド、最初と最後の層）にはより多くのビットが割り当てられ、フィードフォワード層の大部分にはより少ないビットが割り当てられます。
対象ハードウェア： Apple Silicon。SwiftletはSwiftで書かれ、GPUアクセラレーションにMetalを使います。統合メモリを持つM1/M2/M3/M4 Macが最適です。GPUとCPUが同じRAMプールを共有するため、NVIDIAベースのローカル推論を制限するメモリコピーのボトルネックを回避できます。
得られるもの： プロンプトを受け取り補完を返すローカルHTTPサーバー（通常localhost:8080）です。M3 MacBook Proでのトークン生成速度は、80Bモデルで毎秒8〜12トークンと報告されており、対話型アプリケーションには使えるものの、瞬時とは言えません。
極端な量子化はタダではありません。HNでの議論と初期テストに基づくと、うまくいく部分といかない部分は次のとおりです。
うまくいく：
目立って劣化する：
実務上の結論：プロダクトが対話型アシスタント、要約ツール、コンテンツツールであれば、極端に量子化された80Bは驚くほど有能です。プロダクトがコード生成や数学を行うなら、代わりにより高精度な量子化の35Bをテストしましょう。小型モデルでパラメータあたりのビット数を増やす方が、大型モデルでビット数を減らすより良い結果になることが多いです。
構築の道筋は単純です。クラウドのAPIキーも課金アカウントも必要ありません。
ステップ1：Swiftletをインストールして起動する。 リポジトリをクローンし、量子化されたQwen3-80Bの重み（4.3GBのファイル）をダウンロードし、サーバーを起動します。8GB以上のRAMを積んだMacなら、およそ30秒で起動します。
ステップ2：エンドポイントが動作することを確認する。 curlや任意のHTTPクライアントで、localhost:8080にテストプロンプトを送ります。数秒で補完が返ってくるはずです。
ステップ3：アプリケーション層を構築する。 ここに最も時間をかけることになります。ユーザーの入力をローカルエンドポイントに送り、レスポンスを表示するフロントエンドが必要です。We.Incでは、作りたいアプリ（「段落を受け取り、書き直した3つのバージョンを返すライティングアシスタント」など）を説明すれば、AIがライブプレビュー付きの動くReactアプリを構築します。その後、API呼び出しを自分のSwiftletエンドポイントに向けて編集します。
ステップ4：公開またはエクスポートする。 We.Incから直接カスタムドメインに公開する（アプリは実行時にあなたのローカルエンドポイントを呼び出します）ことも、コードをGitHubにエクスポートして自分でデプロイすることもできます。コードは独自の依存関係を持たない標準的なReact、Vite、TypeScriptです。
結果として、継続的なAPIコストゼロで、ローカルの80Bモデルが動かす本番品質のウェブアプリが手に入ります。
ローカルが勝る場合：
クラウドが勝る場合：
正直な落としどころは、開発とデモにはSwiftletを使い、本番規模になったらクラウドのエンドポイント（OpenRouter、Together AI、Qwen APIなど）に切り替えることです。アプリのコードはどちらの場合も同じで、変えるのはエンドポイントのURLだけです。
ノートPCで80Bモデルを動かせることは、品質がデータセンター並みだからではなく、APIキーという障壁をまるごと取り除くという点で一つの節目です。MacBookを持っている人なら誰でも、今やフロンティア級のモデルをローカルで動かし、その上に構築できます。
AI搭載ツールを作ってきた開発者にとって、コストの構図が変わります。プロトタイプ段階のプロダクトにとって、APIの請求額は現実的な摩擦要因でした。Swiftletは開発とテストの間、その摩擦をなくしてくれます。モデルは自分のマシン上で動き、クエリごとの費用はゼロで、推論速度は対話的な利用に十分なほど速いです。
フロントエンドとホスティングを担うWe.Incのようなビルダーと組み合わせると、「AIツールのアイデアがある」から「カスタムドメインで公開されている」までの道のりは、Swiftletをインストールし、アプリを説明し、localhostを指定し、公開する、というものになります。アイデアからプロダクトまでのステップ数が大きく減ったということです。
We.Incで無料で構築を始め、ローカルのSwiftletエンドポイントに接続しましょう。コードはいつでもGitHubにエクスポートできます。
無料で始める · クレジットカード不要