Nativ - フロンティア級オープンモデルをMacでローカル実行

 (blaizzy.github.io)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • Nativは、Apple Silicon MacでオープンAIモデルをダウンロードし、アカウント・サブスクリプション・クラウドなしで実行できるMITライセンスのオープンソースアプリ
  • Google、Cohere、Liquid AIなどのモデルを提供し、Macハードウェアに適したモデルを推奨し、すべての応答をローカルで生成
  • チャットではストリーミング、Markdown、コードハイライト、画像入力をサポートし、1秒あたりのトークン数とメモリプレッシャーなどのパフォーマンス状態をリアルタイムで確認可能
  • MLX-VLMとMシリーズのユニファイドメモリ・Metalに最適化され、言語、ビジョン、動画、コード、音声タスクを処理
  • ローカルモデルサーバーをPi、Codex、Claude Code、Hermes、OpenCodeと接続でき、アプリとモデルローダーの全コードも公開

Macに最適化されたローカルモデル実行

  • Apple Silicon M1以降をサポートするユニバーサルmacOSアプリで、クラウドや別の変換レイヤーなしに実際のモデルをMac上で動作させる
  • 厳選されたライブラリからGoogle、Cohere、Liquid AIのオープンモデルを選択でき、ハードウェアに適したモデルの推奨も受けられる
  • チャットインターフェースは次の機能を提供
    • ストリーミング応答とメッセージごとのパフォーマンス指標
    • Markdownとコードのシンタックスハイライト
    • 画像入力
  • リアルタイムのパフォーマンス測定により、1秒あたりのトークン数、メモリプレッシャー、発熱状態、最初のトークン生成時間を確認可能
  • MLX-VLMをベースに、MシリーズのユニファイドメモリとMetalに合わせて調整
  • LLMチャット、画像キャプション生成、動画要約、コード補完、音声変換および生成をサポート
  • アカウント・クレジット・サブスクリプションは不要で、ユーザーデータを販売しない

開発ツール連携とオープンソース原則

  • Nativの単一ローカルエンドポイントを通じて、既存のコーディングエージェントをMacで実行するローカルモデルに接続できる
    • Pi
    • Codex
    • Claude Code
    • Hermes
    • OpenCode
  • デスクトップアプリ、モデルローダー、パフォーマンス測定チャートを含む全コードを公開し、閲覧・フォーク・Pull Requestが可能
  • MITライセンスで配布し、VCロードマップ、エンタープライズグレード、プロンプトを学習データに転用するダークパターンを設けない
  • 全モデルライブラリはHugging Faceで確認できる

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Hacker Newsの意見

  • このMITライセンスのアプリは、人気ライブラリ MLX-VLM をメンテナンスしている Prince Canuma が作ったもの。MLX-VLMはAppleデバイス上でllama.cppより高速な推論を提供できるため、長らくLM Studioなどの依存関係として使われてきた。
    MLXエコシステムはCUDAより小さいが、新しいモデル、特にビジョン・音声認識・音声合成・動画生成のような マルチモーダルモデル への対応が非常に速い。mlx-audio-swift も参考になり、この種のモデルがこのUIに統合されても驚かない。
    ランディングページにはバイブコーディングの痕跡があるかもしれないが、アプリの大半はSwiftで書かれているため、この推論スタックをiPadやiPhoneへ移植するのも容易に見える。

    • 最近のHugging Faceには、ほぼすべての人気モデルの MLX版 が上がっている。たとえば Qwen 3.6 35B-A3B の基本ページから量子化リンクをたどり、評判がよく人気のあるMLX派生版を選べばよい。
    • ドメインで blaizzy を見てうれしくなった。Prince CanumaのMLX関連の仕事はとりわけ品質が高かったからだ。
    • GitHubリポジトリには、音声専用および画像生成専用モデルのサポートが近日追加されると書かれている。Prince CanumaはXやGitHub Issuesでの返信が非常に速く、私は音声クローンに mlx-audio と mlx-community/Qwen3-TTS-12Hz-1.7B-Base-bf16 をほぼ毎日使っている。
    • 最初に浮かんだ疑問は、Unslothと比べて何が違うのか だった。
    • mlx-vlmはvllmやsglangのように 最新サンプラーのサポートがひどく弱い ため、移行するとむしろ害になる可能性がある。私は min_p論文 の著者の一人だが、llama.cppがはるかに優れたtop-n-sigmaをサポートしている状況で、min_pが最善だというなら、速度が速くても移る理由はない。
      最新サンプラーに対応するには、まず 論文1、論文2、論文3 から見てみるとよい。

  • フロンティア という表現は濫用されているように思う。現在のFableのような最高水準のモデルを指すのだと思っていたが、そうしたモデルは膨大なRAMと高価なGPUが必要で、自前でホストするのは難しいのではないか。

    • ここでは、多目的最適化問題における最良解の集合である パレートフロンティア を指しているようだ。知能と価格を基準にすると、同等以上の知能をより安く提供するモデルもなく、同じ価格以下でより知的なモデルもない場合にフロンティアに属する。
      Artificial Analysisのチャート を見ると直感的に分かる。たとえばDeepSeek V4 Proほど知的で、かつより安いモデルがないので、フロンティアモデルと見なせる。パレートフロンティア上の解は、何かを犠牲にせずにより良い代替へ置き換えられない、そのクラスでの最善だ。
    • この用法は混乱を招くので同意しにくいが、一般に フロンティアは複数あり得る し、その中でもオープンウェイトの小型ローカルモデルのフロンティアが最も重要で興味深いと思う。
      Gemma 4 12Bを使うたびに、小さく賢く効率的なのに、AI業界のエネルギーがまったく見当違いの方向へ向かっていると感じる。研究費を16GBのユニファイドメモリシステムで動くモデルの改善に集中すれば、重要な進展が可能だろう。
      Qwen 3.6やBottleCapの27Bファインチューニングモデルも良いが、小型Gemma 4モデルの驚くべき性能は十分に知られていない。このWebサイトがQwen 3.6 27Bにフロンティアという表現を使うのは不適切に見えても、性能面ではまったく的外れというわけではない。
    • フロンティアは、パラメータ数、タスク別性能、同一ハードウェア上でのトークン生成速度、アクティブメモリ要件など、複数次元の 最適な組み合わせ として定義される。現在の選択肢の中で、ある指標を改善しようとすると他の少なくとも一つの指標が悪化するモデルがフロンティアに該当する。
    • フロンティアは曲線であり、パレートフロント を意味する。
    • オープンソースと最前線との差はKimi K3のようなモデルで縮まりつつあるが、Kimi K3はパラメータが2兆を超える。一般的なMacで実際に動かせるGemma 4などは同じクラスではない。

  • ホームページが、まるでLM Studioのような既存アプリが存在しないかのように紹介していて驚いた。ぱっと見では 何が違うのか不明確 で、Open WebUIも抜けている。
    私はMacBook ProでOpen WebUIとDS4を使い、ここ数週間DeepSeek V4 Flashをローカル実行している。

    • LM Studioは、Nativの開発者が公開したコードを基に作られた クローズドソースのソフトウェア だ。
    • LM Studioも同じことをするが、オープンソースではない。したがってNativには追加で提供する差別化要素がある。
    • 「聞いたことのある他のローカルAIアプリは、自分たちが所有していないオープンソースエンジンの上に作られたプロプライエタリなシェルだ」という文言は、LM Studioを遠回しに狙った 表現だ。
    • MacBookのスペックが気になる。私のStrix HaloではDeepSeek V4 Flashはエージェント用途に使うには遅すぎる。

  • 今や フロンティア は、Claude Codeユーザーなら分かる load-bearing のように濫用される言葉になった。特にこのアプリは実際の最上位モデルをMac上でローカル実行できないのだから、使うのをやめてほしい。

  • 「誰もやっていないのに私たちがオープンソースである理由」のような マーケティング文句 が気に入らない。私はオープンソースのoMLXを使っており、Nativの機能をすべて提供しているように見える。
    存在しない扱いにされた既存のオープンソース競合製品と、きちんと比較してほしい。

    • おそらくLM Studioのような選択肢がオープンソースではない理由を言おうとしていたのだろう。

  • 小さなローカルモデルを実際に何に使っているのか気になる。かなり有能にはなったが、遊びで作るいくつかのトイプロジェクト以外の実務を任せるには、まだ信頼しづらい
    コーディングエージェントに実際に使っているのか、それとも主に別の用途なのか知りたい

    • OpenCodeでQwen3.6 27Bが生成したコードを本番環境にデプロイしたことがある。Opusほど知識範囲は広くないが、プロンプトと周辺コードだけで変更内容を完全に推論できるなら非常によく機能する
      Blackwell GPU向けの高性能推論エンジンのように専門知識が必要なコードを一から書くのは難しいが、既存プロジェクトにユースケースを追加する一般的なPRならSonnetと同程度。推奨temperatureとtop-p設定、過度でない量子化、最低15万トークンのコンテキストといった適切な構成が必要
    • 個人エージェントのメモリグラフ抽出にGemma 4をローカルで使っている。メッセージをトピック、出典、事実、エンティティなどに分け、NLEmbeddingsを使った検索用グラフに入れている
      対象エージェントはDeepSeek V4 Flashを使っており、ローカルモデルはチャットエージェントとして使うには遅いが、メモリ抽出にはかなりうまく機能し、各会話ターンのAPI使用量を減らしてくれる
    • コーディングエージェントとしては使っていないが、テキスト変換・要約・情報抽出には非常に有用。すでに有料モデルを購読しているなら、プライバシー保護以外に特別な利点はないかもしれないが、それ自体も無視する価値はない
    • 小さなモデルでも、依存関係の更新、マージコンフリクトの解消、--help、Markdown、README作成のような反復作業は十分こなせる。失敗してもgit restoreで戻すかPRを拒否して、より良いモデルに再度任せればよい
    • Qwen35ba3bは、比較的普通のハードウェアでも大規模なデータクレンジングを実行できる。3090 GPUを2枚使って、すでに約1,000億トークンを処理した

  • LM Studioより優れている点は何か、またMTPモデルも実行できるのか気になる。知る限りでは、MTPモデルはGGUF形式だ

  • Rapid MLXでMLXを試したが、Qwenがしょっちゅう途切れて同じ内容を繰り返した。llama.cppに移ったところ、MTPでのトークン生成がより速くなり、モデルも安定した
    他の人たちがMLXとllama.cppを比較してどのような結果を得たのか気になる

    • M1 MaxではMLXの利点をほとんど感じなかった。Apple Neural Engineの変更のおかげで、M3以降では利点がより大きい可能性はある
      自分が試したモデルでは、llama.cppのGGUF性能のほうが良い場合もあった。Gemma 4のMTPには大きな価値はなかったが、Qwen 3.6 MoEでは測定可能な差があり、最新ハードウェアならより意味があるかもしれない
    • 異なる時期にMLXを2回試したが、毎回llama.cppよりかなり低い性能だった

  • この用途に適したミドルレンジのMac仕様が気になる。64GB M5 Proと、低価格のM5 Airを買ってクラウドのトークン費用を払う選択肢の間で迷っている
    性能がより低いモデルをローカルで動かすために2,000〜3,000ドル多く使う代わりに、かなりの量のクラウドトークンを買える

    • M1 Max 64GBでも、こうしたモデルのかなり多くを実行できる

  • ds4上でDeepSeek V4を実行しない理由が気になる。結果はかなり良さそうだ

    • NativはDwarfStarのようなSSDストリーミングをサポートしていないようだ