Kimi K3はM1 Maxで動作する。ただしopenai maxとの比較は的外れだ

Kimi K3は現在、64GB M1 Max上で報告値として毎秒0.0687トークンで動作しており、openai maxの検索結果に何が表示されるべきかを捉え直す事例となっている。小規模な研究プロジェクトであるDeltafinは、Moonshot AIの2.8兆パラメータモデルを、重み全体をメモリに読み込むことなく実行する。その成果は技術的には注目に値する一方、実用速度は極めて遅い。

このプロジェクトは、2021年のMacを競争力のあるAIサーバーへ変えるものではない。完全なローカルインストール時のデコード時間の中央値は、1トークン当たり14.6秒だ。やや長めの応答でもマシンを数時間占有し得るため、エージェント型コーディングセッションはワークフローというより実演に近い。

可能であることと、使えることの隔たりこそがこの話の核心だ。Deltafinは、巨大なモデルには巨大なメモリ容量が必要だという前提に挑んでいる。ただし、OpenAI、Anthropic、Moonshot、その他のインフラ提供事業者によるホスト型システムの応答性に挑んでいるわけではない。

この実験が示すのは、別のフロンティアである。オープンウェイトにより、独立系開発者はストレージ、メモリ圧力、スパース計算を軸に推論を再設計できる。その結果生まれるシステムは、ユーザーが期待する速度を提供できなくても、モデルを実行できる場所を広げる。

Deltafinは64GBで2.8兆パラメータを扱う

Deltafinは、モデルへのアクセスとモデルの常駐を切り分けることで、「ローカルで実行する」の意味を変えている。

Moonshot AIは2026年7月16日にKimi K3を発表した。同社はこれを、100万トークンのコンテキストウィンドウを持つ、ネイティブなマルチモーダル対応の2.8兆パラメータモデルとして説明している。公開されたアーキテクチャでは、すべてのトークンにすべてのパラメータを使うのではなく、フォワードパス中に1040億パラメータをアクティブ化する。

この設計はmixture of experts、すなわちMoEと呼ばれる。MoEはニューラルネットワークの一部を専門化されたパラメータ群に分割し、各トークンを限定された選択肢へルーティングする。Kimi K3には896のルーティング対象エキスパートがあり、各関連レイヤーで16個が選択される。

この違いがDeltafinを可能にしている。密な2.8兆パラメータモデルでは、各トークンごとにパラメータプール全体を読み取り、処理する必要がある。Kimi K3のスパースルーティングでは、ランタイムはモデルのルーターが選択したエキスパートだけを取得できる。

Deltafinのメンテナーによると、公開されたKimi K3の重みは約1.56TBを占める。アテンションコンポーネント、埋め込み、共有エキスパート、潜在射影を含む約114GBが、モデルの常駐スパインを構成する。さらに1.45TBには、82,432個のルーティング対象エキスパートが収められている。

どちらのグループも、元の形式では64GBのユニファイドメモリには収まらない。そこでDeltafinは、高速なローカルストレージをメモリ階層の別レベルとして扱う。スパインをレイヤーごとに読み込み、各トークンがネットワークを通過する際に、選択されたエキスパートをディスクからロードする。

プロジェクトのDeltafin repositoryでは、定常状態のデコード速度の中央値を毎秒0.0687トークンと報告している。これは1トークン当たり14.6秒、または毎分約4.1トークンに相当する。フルモデルを使った6回の実行で測定された範囲は、毎秒0.0503～0.0779トークンだった。

これらの数値は、10コアCPU、32コアGPU、内蔵ソリッドステートストレージを搭載した1台の64GB M1 Maxから得られた。フルモデルはローカルに保存されていた。テストでは、greedy decoding、厳密な数値設定、int8スパイン、トレース無効を使用した。

ベンチマークプロンプトは5トークンで構成されていた。Deltafinは検証済みの3トークンの続きを生成し、最初のデコードステップは定常速度の計算から除外された。生成された3トークンに対するモデル時間の中央値は56.5秒で、プロセス起動直後の実測時間は64.1秒に達した。

これは独立したベンチマークでも、デバイス横断の代表的な平均値でもない。1台のマシンでメンテナーが実施した参照値である。リポジトリは構成と実行範囲を公開しているが、より広範な再現検証はまだ限られている。

その留保を踏まえても、この実験は意味のある境界を越えている。最初の動作版では、1トークン当たり約20分が必要だったとされる。Deltafinの現在の結果は、その内部的な出発点から約82倍の改善を示す。

この改善により、ほぼ静的な実演だったものが、目に見える生成へと変わった。それでも対話的な会話を実現するものではない。この違いが、プロジェクトに関するあらゆる実用上の評価を左右する。

M1 Maxが参加できても追いつけない理由

M1 Maxは有用な計算能力を提供するが、Deltafinは本質的にストレージ経由で重みを移動することに制約されている。

Appleは2021年10月、最大64GBのユニファイドメモリに対応するM1 Maxを発表した。ユニファイドメモリではCPUとGPUが単一の共有プールにアクセスでき、別々のメモリ空間間でのコピーを一部削減できる。

Appleは同チップについて、最大毎秒400GBのメモリ帯域幅も公表している。こうした特性は、ローカルAIソフトウェアがシステムメモリとディスクリートGPUメモリの硬直した分離を回避するうえで役立つ。しかし、1.56TBのモデル重みを64GBに収められるようにするものではない。

Deltafinは、その不一致をなくすのではなく、容量の制約を回避する。常駐スパインをint8へ変換し、ストレージ要件を約114GBから約60GBへ削減する。その後、他のデータをディスクに残したまま、選択されたレイヤーをメモリ経由で処理できる。

ルーティング対象エキスパートには、モデルサイズとデータ移動を減らすための4ビット浮動小数点形式であるMXFP4重みを使用する。Moonshotによれば、Kimi K3は教師ありファインチューニング以降、量子化認識学習を受けている。つまり、低精度での挙動はリリース後に追加されたのではなく、学習中から考慮されていた。

公式のKimi K3 codeは、vLLMやSGLangなど、サーバー向けの推論エンジンを推奨している。Deltafinは別の道を取り、従来のデプロイ先としては大幅に低い性能のハードウェア向けに、ネイティブカーネルとストレージ認識型の実行を追加している。

生成されるトークンごとに、ルーターは92のルーティングレイヤーにまたがって16個のエキスパートを選択する。Deltafinによれば、この処理では1トークン当たり約25.8GBのエキスパートデータを読み取る。ローカルストレージならその読み取りを数秒で提供できる一方、ネットワーク経由の取得には数分かかることがある。

これにより、M1 Maxがうたうメモリ帯域幅が最終性能を決めない理由が分かる。GPUは、まだ到着していないデータを処理できない。ディスクレイテンシ、ストレージスループット、展開、重みの準備、同期はすべてクリティカルパスに入る。

プロジェクトは、バックグラウンドロードとエキスパートのプリフェッチを使い、一部の作業を重ね合わせている。メモリマッピングにより、ランタイムはファイル全体を繰り返しコピーせずにエキスパートデータへアクセスできる。ネイティブのMetalカーネルは、AppleのGPUパスで選択されたエキスパート計算を実行する。

Deltafinには、複数の処理を統合して中間データの移動と起動オーバーヘッドを減らす融合カーネルも含まれる。こうした最適化が重要なのは、わずかな非効率でも各トークンで数十のレイヤーにわたって繰り返されるためだ。

ただし、同じルーティングと重みを維持したまま、カーネルだけで25.8GBのエキスパート読み取り要件を消すことはできない。完全なローカルインストールでは、そのトラフィックを内蔵ドライブへ移す。ストリーミングでは、キャッシュミスをリモートホストへ移し、レイテンシを増幅させる。

Appleの当初のM1 Max specificationsは、重要な現実確認を与えてくれる。このチップは、グラフィックスやメディア処理を含む高性能ノートPCワークロード向けに設計された。1.56TBの言語モデルのメモリとして機能するよう設計されたわけではない。

この結果は、ハードウェアの限界が消えた証拠ではなく、マシンのアーキテクチャを見事に活用した例である。Deltafinは、容量と時間を繰り返し交換することで計算を進め続ける。

このトレードオフこそが、システム研究者にとってこの実験が重要である理由だ。「ロードするには大きすぎる」は、「実行不可能」と同義ではないことを示している。同時に、実行できることだけではデプロイの実現可能性を測るには不十分であることも示している。

openai maxとの比較は可能性と応答性の対比だ

Deltafinが競うのはホスト型推論が提供する体験ではなく、その背後にある前提である。

openai maxを検索するユーザーは、より高いモデル能力、より強い推論、あるいは製品上の上限を求めている可能性がある。Deltafinが答えるのは別の問いだ。意欲的な開発者は、1台のワークステーションでどれほど大きなオープンモデルを動かせるのか。

ホスト型AIシステムは、サービス契約に合わせて最適化されている。ユーザーはプロンプト処理、生成トークン、同時実行性、可用性、予測可能なレイテンシを期待する。提供事業者は、一般のユーザーが管理することのないアクセラレータ群と補助インフラにその作業を分散している。

Deltafinはローカルでの実行可能性に最適化している。極端なメモリ制約下で動作させながら、Kimi K3の公開された重みとモデルパスを維持することが目的だ。これは研究目標であり、応答性の高い商用エンドポイントの代替ではない。

このプロジェクトはOpenAI互換サーバーを公開しており、HTTPエンドポイントが一般的なリクエストおよびレスポンス形式に従うことを意味する。chat completions、text completions、モデル一覧、ストリーミング出力を実装している。開発者は互換クライアントをローカルのベースURLへ向けられる。

互換性は同等の挙動を意味しない。Deltafinは一度に1件の生成リクエストのみを処理する。2件目の同時リクエストにはHTTP 429レスポンスが返る。現行システムはgreedy decodingを使用するため、temperatureおよびtop-pパラメータは受け付けるものの無視される。

メンテナーは、クライアントのタイムアウトを秒単位ではなく時間単位に設定するよう推奨している。この助言は、どのアーキテクチャ図よりも明確に隔たりを表している。なじみのあるAPIはインターフェース上の違いを隠せても、物理的な待ち時間までは隠せない。

コーディングエージェントは、この問題をよく示している。こうしたツールは、最初の有用なアクションを求める前に、長いシステムプロンプト、リポジトリのコンテキスト、ツール定義、会話履歴を送ることが多い。Deltafinは、これらのプロンプトが入力トークンの初期処理であるprefillを特に高コストにすると警告している。

コーディングアシスタントは、多数の連続したモデル呼び出しを必要とする場合もある。ある応答はコマンドを提案し、別の応答はその結果を解釈し、後続の呼び出しでファイルの修正やテストの確認を行う。生成トークン当たり14.6秒では、レイテンシはあらゆるステップで積み重なる。

Moonshot自身のデプロイは、OpenAI互換およびAnthropic互換のインターフェースをサポートしている。同社のモデルドキュメントによると、Kimi K3は常にreasoningを使用し、別個のreasoningフィールドを返す。デフォルトの推論努力は「max」で、API経由ではより低い設定とより高い設定も利用できる。

日常的なKimi K3の利用を評価する人にとっては、その公式サービスが適切な参照対象になる。ローカル実行、スパースルーティング、重みストリーミング、再現可能な推論を研究する人にとっては、Deltafinが適切な参照対象になる。

プライバシーという点でも違いがある。完全なDeltafinインストールでは、重みをダウンロードした後はネットワークアクセスなしでトークンを生成できる。ユーザーが接続されたアプリケーションやログも管理していることを前提に、プロンプトと生成テキストをワークステーション内に留められる。

この特性は、機密性の高い草稿や独自コードを扱う研究者の関心を引く可能性がある。ただし、ローカル処理であれば自動的に規制対象データや本番データに適したシステムになるわけではない。運用者は依然として、依存関係、アクセス制御、ログ、モデルライセンス、アプリケーションの挙動を確認する必要がある。

Kimi K3 paperでは、ネイティブな視覚機能と100万トークンのコンテキストウィンドウを備えるモデルが説明されている。Deltafinのベンチマークは、そのコンテキスト全体、マルチモーダル入力、または継続的なエージェント型ワークロードにおける実用性能を実証するものではない。

これが、openai max との比較を限定的にとどめるべき理由です。Deltafin は、最先端規模のオープンモデルを実行できるハードウェアの範囲を広げます。しかし、ホスト型サービスのレイテンシ、同時実行性、運用成熟度、利便性には及びません。

影響を受けるのは商用 API よりも、従来のデプロイメント前提です。インフラ開発者は、RAM 容量だけを唯一の厳しい制約として扱うことができなくなりました。ストレージを意識したランタイムは別の道筋を提供しますが、深刻なレイテンシを伴います。

フルインストールとストリーミングは、まったく異なる実験になる

Deltafin の2つのインストールモードは、ストレージの配置がモデルサイズとほぼ同じくらい重要であることを示しています。

推奨されるフルインストールには、約1.7TBのローカルディスク容量が必要です。Deltafin はダウンロード時間を5〜10時間と見積もっており、転送は再開可能です。インストール後は、推論にネットワークアクセスを必要としません。

この構成で報告されたトークン時間の中央値は14.6秒でした。専門家プール全体をローカルに保存するため、ルーティングされた各 expert を HTTP 経由で取得するのではなく、ディスクから読み出せます。

ストリーミングインストールに必要なのは約215GBです。プロジェクトによれば、初回ダウンロードには約30分かかります。不足している expert は Hugging Face 上の Kimi K3 ファイルから取得され、拡大していくローカルキャッシュに追加されます。

この低い導入要件には、苛烈な性能ペナルティが伴います。必要な expert がまだキャッシュされていない場合、Deltafin は1トークンあたり3分以上かかると見積もっています。生成が始まる前にプロンプトが多くの expert に触れるため、チャットのプリフィルには数時間を要する可能性があります。

最小限のチャットテンプレートでも、60トークンの入力は珍しくありません。本番のアシスタントは、しばしば数千トークンを送信します。したがってストリーミングモードでは、ユーザーが最初の生成トークンを見る前に、expert のダウンロードに相当な時間を費やす可能性があります。

将来のプロンプトがすでにローカル保存された expert を経由する場合、キャッシュによって繰り返し通る経路は高速化されます。ただし、スパースルーティングは入力に依存します。あるタスクで温まったキャッシュが、別のタスクでも同じ expert パターンを再利用する保証にはなりません。

Deltafin には、記録されたルータートレースを使って不足している expert を順位付けするアイドル時のウォーミングツールが含まれています。この仕組みは、使用されそうな expert を事前取得し、古いキャッシュエントリをより高速な生形式へ変換できます。ネットワークからの取得は、引き続き明示的なオペレーター操作です。

ユーザーはストリーミングで始めてから、後で完全な expert プールをダウンロードすることもできます。このプロセスは再開可能で、既存のキャッシュデータを保持します。このアップグレード経路により、ストリーミングは恒久的なアーキテクチャ上の選択ではなく、試用モードになります。

それでも、フルインストールに必要なのは空きディスク容量だけではありません。生成トークンごとに25.8GBを読み出すため、ドライブには継続的な負荷がかかります。長時間の実行では、通常のアプリケーション利用とは異なるストレージ集約型のワークロードが生じます。

ソリッドステートストレージにも有限の書き込み耐久性がありますが、Deltafin の安定したフルインストール経路では、主に既存の重みを読み出します。ストリーミングとキャッシュ変換では書き込みが発生します。実際の影響は、ワークロードの長さ、キャッシュ動作、ドライブ設計、利用可能な予備容量によって異なります。

プロジェクトのベンチマークは、内蔵 M1 Max ドライブを使用しています。外付けドライブ、ネットワークストレージ、空き容量の少ないボリューム、あるいは熱制約のあるシステムでの結果を、同等とみなすべきではありません。リポジトリは幅広いストレージ比較を提示していません。

モデルをフルインストールすること自体にも、運用上の摩擦があります。ユーザーはテラバイト単位の容量を確保し、依存関係を維持し、ネイティブライブラリをコンパイルし、アップデートを管理する必要があります。macOS では、互換性のある Python 環境と Apple 開発ツールが必要です。

これらの制約はプロジェクトを無効にするものではありません。対象ユーザーを定義するものです。Deltafin は、セットアップと測定を価値の一部と捉える研究者、推論エンジニア、ローカルモデル愛好家に適しています。

ストリーミングモードには別の目的もあります。実行を開始する前に、すべての expert 重みを完全に所有している必要はないことを示しています。この考え方は、階層型ストレージ、共有ネットワークキャッシュ、予測的な expert 配置を使う将来のランタイムに活かされる可能性があります。

現時点の数値は、その限界も明らかにしています。インターネット経由で expert を取得すると、生成は遅い状態から、かろうじて対話可能な状態へと移ります。モデルは技術的には動作しますが、待ち時間のために実用的な会話の大半は成立しなくなります。

このベンチマークは検討に値するが、一般化できるほど広範ではない

報告された結果は透明性がありますが、1台のマシンと短い1回の生成だけでは、日常的な Kimi K3 の性能を確立できません。

Deltafin は、多くの趣味的な推論性能の主張よりも詳細な方法論を公開しています。メンテナーは、プロセッサ、メモリ容量、GPU 構成、ストレージの場所、数値設定、プロンプト、期待される出力、最初のトークンの扱いを明示しています。

6回のフルモデル実行では、構成間のドリフトを減らすことを意図した、バランスの取れた実行順序が使われました。報告値は単一の最高結果ではなく中央値です。リポジトリは、同じマシン上でも意味のある変動があることを示す範囲も提供しています。

この透明性は結果の信頼性を高めます。しかし、独立した検証に変わるわけではありません。プロジェクトのメンテナーが最適化を開発し、基準ベンチマークを実行しているため、他のオペレーターによる再現が必要になるという通常の課題があります。

テストプロンプトも意図的に小規模です。「The capital of France is」は完全なフォワードパスを実行しますが、長い推論、コーディング、ビジョン入力、ツール呼び出し、大きなコンテキストウィンドウを代表するものではありません。

検証済みの3トークン継続は、テスト構成でモデルが想定された短いシーケンスを生成したことを確認します。タスク全体にわたる回答品質を測るものではありません。また、長時間の生成で同じスループットを維持できるかも示せません。

グリーディデコーディングでは、ランタイムが常に最高スコアの次トークンを選択するため、厳密な再現が容易になります。一般的なホスト型アプリケーションでは、多様な出力を作るためにサンプリングや別のデコーディング制御を使用する場合があります。Deltafin は現在、一部のサンプリングフィールドを受け付けますが、適用はしません。

プロジェクトは、主要なベンチマーク経路について厳密な数値的挙動を報告しています。オプションの近似モードでは低精度演算を使いますが、メンテナーはスコアが拮抗した出力が再現可能なままとは限らないと警告しています。

Kimi K3 自体にも、さらなる不確実性があります。Moonshot の公式資料は、コーディング、推論、視覚、エージェント型の評価にわたる高い性能を主張しています。これらの主張には、特定のハーネス、設定、競合モデルの構成が関係します。

Deltafin はこれらのベンチマーク上の主張を検証していません。未対応カーネル周辺の互換性変更を加えつつ、Moonshot が公開したモデリングコードを実行しています。読者は、重みの実行成功とモデル品質の独立した確認を分けて考えるべきです。

モデルの規模も誤解を招く可能性があります。Kimi K3 の総パラメータ数は2.8兆ですが、フォワードパス中にアクティブになるのは1040億です。総パラメータ数はストレージ負荷を決める一方、アクティブパラメータは計算負荷の一部をより適切に表します。

1040億のアクティブパラメータであっても、ワークステーションにとっては相当な規模です。しかし、このスパースアーキテクチャのため、Kimi K3 を高密度な2.8兆パラメータモデルと直接比較するのは誤りです。両システムは移動・計算するデータ量が大きく異なります。

新しいハードウェアでは結果が改善するはずですが、その程度は依然として不確実です。より大きなユニファイドメモリは、追加のスパインデータと expert を保持できる可能性があります。高速なストレージとメモリ帯域幅はデータ移動を短縮できます。より優れたカーネルは計算オーバーヘッドを減らせます。

ただし、これらの改善がすべてのフェーズに同じように影響するわけではありません。ある構成でストレージが支配的なら、GPU だけを高速化しても恩恵は限られます。メモリ増加によってキャッシュ動作が変わる場合、性能は生の帯域幅増加が示唆する以上に跳ね上がることがあります。

Deltafin は、128GB のユニファイドメモリを搭載した NVIDIA DGX Spark からのコミュニティ結果を引用しています。寄稿者は短いエンドツーエンド実行を報告しましたが、メンテナーは再現済みベンチマークではなく、単一のコミュニティ測定値として位置づけています。

その慎重さは適切です。ハードウェア比較には、同じプロンプト、ソフトウェアリビジョン、キャッシュ状態、数値経路、測定方法が必要です。そうでなければ、より高速な生成完了がデバイスではなくセットアップ差を反映している可能性があります。

したがって最大のリスクは、Deltafin の基準値が無意味であることではありません。読者が限定的なシステム結果を、ローカル AI の実用準備性に関する広範な主張へと変えてしまうことです。

毎分4トークンのローカル生成は、実験やオフラインでの検査を支えます。しかし、チャット、コード補完、自律エージェントに多くの人が期待する応答性の高い対話には対応しません。

0.0687トークンの結果の後に注目すべきこと

Deltafin の重要性は今後、再現性、キャッシュの経済性、そして現実的なプロンプトでもこのアプローチが成立するかにかかっています。

最初の指標は、新しい Apple ハードウェアにおける独立した性能測定です。結果には、正確なチップ構成、メモリ容量、ストレージデバイス、ソフトウェアコミット、キャッシュ状態、デコーディング設定を報告すべきです。

より多くのメモリを持つ新しい Max または Ultra システムなら、モデルのワーキングセットのより大きな割合を保持できます。制御されたテストでスループットが大幅に改善すれば、Deltafin のアーキテクチャは孤立した M1 Max の技巧ではなく、拡張可能なローカル推論の道筋に見えるでしょう。

改善が小さいままであれば、ストレージトラフィックがより厳しい上限を課している可能性が高いです。その結果は対話利用の根拠を弱める一方、プロジェクトの研究価値は維持します。

2つ目の指標は、長いプロンプトでの挙動です。Deltafin の現在の見出しは、5トークンのプロンプト後の定常デコーディングに焦点を当てています。実際のチャットやコーディングのワークロードは、生成開始前にすべての入力トークンを処理するプリフィルに大きく依存します。

有用なテストには、数千トークン規模のコードコンテキスト、ツール定義、会話履歴、繰り返し行われるエージェント呼び出しを含めるべきです。最初のトークンまでの時間は、定常デコーディング速度と分けて報告すべきです。

この違いは openai max の読者にとって重要です。生成速度が向上しても、最初の回答までに数時間待たされる可能性があります。実用的な応答性は、両方のフェーズに依存します。

Kimi K3 の100万トークンコンテキストは、この点で特に重要です。モデルアーキテクチャがコンテキスト長をサポートしていることは、すべてのランタイムが許容可能なメモリと時間の制約内でその長さを処理できることを意味しません。

3つ目の指標は、expert キャッシュがワークロード間で予測可能になるかどうかです。Deltafin のストリーミングモードは、蓄積されたローカル expert、トレースに基づくウォーミング、最終的な再利用に依存しています。研究者には、多様なタスクシーケンスにおけるヒット率データが必要です。

コーディングプロジェクトでは有用な expert のサブセットが繰り返し活性化され、時間とともに改善する可能性があります。コードから視覚分析や幅広いリサーチへ切り替えると、ルーティングパターンが変わり、その恩恵の多くが失われる可能性があります。

小規模なキャッシュでも現実的なセッション全体で高い再利用率を実現できれば、215GB モードは単なるプレビューを超えるものになり得ます。expert の選択が広く分散したままであれば、完全な1.7TBインストールが唯一許容できるローカル経路であり続けるでしょう。

これらのテストと並行して、ソフトウェア最適化も続きます。Deltafin はすでに、int8 出力ヘッド、投機的デコーディングの変更、バッファ再利用、ネイティブカーネル、バックグラウンドローディングによる改善を報告しています。

これらの改善は、初期段階のランタイムがどれほど急速に進化できるかを示しています。同時に、現在の毎秒0.0687トークンという数値は恒久的な上限ではなく、時点のある参照値として扱うべきことも示唆しています。

ただし、今後の見出しでもベンチマークの規律は維持すべきです。プロンプトの変更、より短い出力、温かいキャッシュ、近似数値モード、異なる expert 数は、比較条件を変えながら速度を向上させる可能性があります。

選択する expert の数を減らすことは、expert データの移動を削減するため、明白な高速化の手段です。Deltafin はその制御を公開していますが、expert を減らすと出力とモデル品質が変わる可能性があります。そのような実行結果を、デフォルトの top-16 経路と同等として提示すべきではありません。

Moonshotによる継続的な重みとコードの公開も重要だ。公式の Kimi K3 model により、開発者はDeltafinのような実験を可能にするファイルへアクセスできる。ランタイム互換性は、今後のモデル改訂とドキュメントに左右される。

開発者にとって、直近の教訓はホスト型モデルをM1 Maxに置き換えることではない。どの制約が絶対的なものなのかを見直すことだ。ストレージを活用する推論では、レイテンシーを許容できるなら、利用可能なメモリをはるかに上回るモデルを実行できる。

エンタープライズの導入担当者にとって、このプロジェクトはローカル制御と本番運用への適性の違いを明確にしている。データレジデンシー、モデルへのアクセス、応答時間、同時実行性、保守、ライセンスは、依然としてそれぞれ別個の判断事項だ。

ナレッジワーカーにとって、この結果はローカルシステムがますます大規模なモデルにアクセスできる未来を示唆している。現時点では、出力を管理することは、出力を待つことよりはるかに容易だ。低速なローカル実行を試すチームは、プロンプト、設定、結果、意思決定を検索可能なエンジニアリングナレッジとして保存すべきだ。

Deltafinは、データセンターを古いノートPCに圧縮したわけではない。そこには収まらないはずのモデルを通過させる、慎重に管理された経路を構築したのだ。だからこそ、1トークンあたり14.6秒であっても、この成果には意味がある。

次の問いは測定可能だ。独立系開発者はこの数値を再現し、その後Kimi K3のデフォルト計算を変えずに短縮できるのか。そうした結果が出るまでは、openai maxは依然として見当違いの競争相手だ。Deltafinが挑んでいるのは、不可能な実行と非現実的な実行の境界である。