言語モデルを提供する開発者向けのSGLangが、Macの実行方式を増やし、モデル読み込みと分離型サーバーのスループットを改善した。ローカル開発と大規模サービスの選択肢が広がったが、性能向上はストレージとリクエスト構成によって異なる。

1. Macでも標準PyTorchの経路を使う

2026年10月19日に公開されたv0.5.22は、Apple Siliconで従来のMac専用の実行経路とは別に、標準PyTorchの経路を追加した。他のアクセラレーターと共有するタスク配分・モデル実行コードをMacでも試せる。

新しい経路は、重みを圧縮したモデルやテキスト以外の入力を受け取るモデル、複数デバイスでの実行に対応しない。次のトークンを事前に推定して検証する生成方式と分離サービングも対象外だ。

MacはCPUとGPUがメモリを共有するため、物理メモリ全体ではなくOSの推奨予算を基準にキャッシュサイズを計算する。Macでの検証では、M4 Pro 48 GBでQwen3-0.6Bを、この予算の0.6を静的メモリに割り当てて実行した。数学の問題200問に例を5個与え、同時実行数8で測定した正解率は0.425だった。

同じ機器・モデルのオンラインサービングでは、ランダムなリクエスト40件、入力256トークン・出力128トークン、最大同時リクエスト数8で、入力と出力を合わせて毎秒213.49トークンを処理した。これはMacでの実行検証であり、他のアクセラレーターより速いことを示す比較ではない。

2. モデル読み込みではストレージ条件を確認する

任意で選べるローダーのInstantTensorは、重みを分割して読み、次のデータを先読みする。既存のファイル探索手順を維持し、以下のように別途インストールして指定する。

対応デバイスはCUDAとROCmであり、Mac向けの新しい実行経路には適用されない。ファイルはSafetensors形式のみに対応する。

pip install "sglang[instanttensor]"

python -m sglang.launch_server \
  --model-path Qwen/Qwen3.5-4B \
  --load-format instanttensor \
  --model-loader-extra-config '{"backend":"URING","chunk_size":8388608,"io_depth":64}'

読み込み比較では、毎秒50 GBのストレージとH200 8基でDeepSeek-R1の重みを読む際、従来ローダーの160秒が15.3秒に短縮され、10.5倍高速になった。ストレージをメモリ上に置いた場合、同じモデル・機器で22.6秒が12.1秒に短縮され、1.87倍だった。サーバー準備までの全体時間ではなく、重みの読み込み時間だ。

毎秒50 GBのストレージからQwen3-30B-A3BをH200 1基で読み込む時間は、従来ローダーが57.4秒、新ローダーが1.77秒だった。先の結果とはモデルとデバイス数が異なり、直接比較できない。

3. 分離サービングはメモリ予約の時点を変える

分離サービングは、入力を一括処理する段階とトークンを順に生成する段階を別のサーバーに任せる。新しい選択式ポリシーは、入力処理が終わるまで、生成サーバーの中間計算用領域であるKVキャッシュの予約を遅らせる。まだ生成できない長いリクエストが場所を先取りすることを減らすもので、計算自体を速くする方式ではない。

分離ポリシーの過去の実験では、GLM-5.2-NVFP4とRubin GPU 12基、3段階のマルチトークン予測を使用した。入力処理のレプリカ2個・生成のレプリカ1個に、テンソル・データ・エキスパート並列のサイズをそれぞれ4とし、モデル計算を分割・複製した。

生成サーバーのキャッシュ領域を意図的に不足させた実験だ。

> 確認用の条件：8ビット浮動小数点キャッシュ、Mooncake転送、生成キャッシュはデバイスごとに163,840トークン。先行する入力処理の試行数は、両ポリシーとも1だった。

入力131,072トークンのリクエスト64件と4,096トークンのリクエスト192件を混ぜ、出力256トークン・同時リクエスト数64でポリシーごとに2回測定した。実行ごとの指標の算術平均の比較で、スループットは26.81%増え、最初のトークンまでの待ち時間の95パーセンタイルは48.87%減った。95パーセンタイルは、測定値の95%がその値以下になる点だ。

一方、出力トークン当たりの平均時間は2.13%、トークン間隔の99パーセンタイルは92.77%増え、遅い側での途切れが大きくなった。

入力サーバーのキャッシュをより長く保持し、入力処理とキャッシュ転送を重ねられないという代償もある。

小さいモデルでは、スループットの差は実行ごとのばらつきの範囲内だった。

初期対応はMooncake転送を使う構成だ。モデル計算全体を4台のデバイスに分ける設定とは別に、デバイスごとに、トークン間の関係を計算するアテンション・入力コンテキスト・モデルの段階をさらに分割しない構成のみをサポートする。

> デプロイ時の確認：通信ワーカーをまずデフォルトのポリシーのままアップグレードし、その後、両方の役割のポリシーを一緒に変更する必要がある。

この実験はベースとなるコードの更新前の結果であり、変更案では最新コードの回帰検証が未完了のまま残っている。

4. ハードウェア対応の拡大と性能比較を区別する

リリース文書は、DeepSeek-V4.1 FlashのH200 8基構成で、GPU当たりの出力スループットが2.1~2.3倍に増えたと報告した。入力長と同時リクエストの条件は示されていない。

対応する2種類のデバイスのうち一方で、投機的生成のスループットが通常の生成に対して最大1.9倍と測定された。

> 確認用のデバイス・構成：AMD MI350X・MI355Xに対応。測定はMI350X 4基とDSparkを使った結果だ。

この構成でDSparkを使うと、128K入力の最初のトークンまでの待ち時間は860ミリ秒から576ミリ秒に短縮された。対応デバイスすべてで同じ性能が確認されたわけではない。

5. アップグレードはPythonから確認する

Python 3.11以上が必要だ。3.10でバージョンを指定せずにインストールすると、3.10に対応する最後のリリースが選ばれるため、インストールの成功だけで更新できたと判断してはならない。

今回のリリースはMacでの開発経路とサーバー最適化の選択肢を広げたが、分離ポリシーは長短の入力が混在し、生成キャッシュが不足するサービスで検討すべきものであり、応答中の長い途切れに敏感なサービスは、スループットだけで選んではならない。