時間を節約したいなら、バッチ推論が答えだよ。要するに、複数の人の「プロンプト」を同時にモデルインスタンスに通すってこと。モデルインスタンスを厳密にタイムシェアする代わりにね。これが、温度を0に設定しても、固定のシードを使っても、サービスを利用したときに返信にバラつきが出る理由なんだ。他のプロンプトと一緒にバッチ処理されるから、自分のプロンプトだけをコントロールできないんだよね。これってデータ流出攻撃のベクトルになり得るのかな？多分、そこまで「調査」してないけど。

自分はMLの研究者でもエンジニアでもないから、話半分に聞いてほしいけど、この投稿にはちょっと混乱してる。Deepseek V3/R1は、通常のローカルモデルに比べてサイズが大きすぎて、ローカルで動かすのは高くつくんだ。アクティブなパラメータの数はフルモデルサイズより明らかに少ないけど、それは計算要件を助けるだけで、メモリ要件には関係ない。複数のH100がない限り、V3/R1はローカルで実用的なスタントとしてしか動かせないし、モデルの一部または全部が低帯域幅のメモリに保存されてる。Deepseek V3のサイズをプロプライエタリなフロンティアモデルと比べることはできないよね、だってそのモデルのサイズもアーキテクチャも全然わからないから。比較されてるモデルは「スケールで高価」だから、ローカルでは全く動かせないけど、ローカルで安く動かせるとは思えないよね？ここで言われてるのとは逆の効果が期待されるはずじゃない？MoEはローカル/シングルユーザーのシナリオにはいいトレードオフだと思う。バッチ処理が難しくて効率が悪いってデメリットは関係ないからね。 > 大きなバッチはレイテンシを上げる、ユーザーのトークンがバッチが十分に満たされるまで200ms待つことがあるけど、フィードフォワードステップでより大きくて効率的なGEMMを可能にすることでスループットを向上させる 本当に掛け算される行列が大きいの？自分の考えでは、バッチ処理の目的は大きな入力行列を得ることじゃないと思ってる。ボトルネックをメモリ帯域幅から計算に移すことが目的だと思う。行列はすでに全体のモデルやレイヤーのサイズよりもずっと小さく分割されてるから、HBMからSRAMに重みの一部をロードして、そのスライスの掛け算をして、すべてのタイルが処理されたら結果を集計するって感じ。バッチ処理を使うと、同じ重みで複数の計算ができるから、メモリ帯域幅あたりの効果的なFLOPSが増えるんだ。 > OpenAIとAnthropicのモデルがすぐに応答するってことは、つまり： それって本当に事実なの？投稿には、3つのプロバイダーのファーストトークンまでの時間に関する数字が全くないよ。

エキスパートの混合はより大きなバッチサイズを必要とする それとも、低バッチサイズ（理想的には=1）のためのAppleシリコン。統一メモリは、通常のGPUよりも帯域幅/FLOPSが低いため、モデルが遅くなる代わりに大きなモデルを動かすことを可能にする。でも、MoEは毎回少数のパラメータしか計算しないから、計算ニーズは低いんだ。Macでのシングルバッチ推論に対して、Deepseekの良い速度を報告してる人も見たことあるよ。でも、多くの人にとっては、十分なメモリを得るのにお金がかかるから、まだ高いって感じる。ある意味、MoEモデルはMac（または同様のマシン）にぴったりだよね。対照的に、アップグレードしたRAMサイズのMacを注文して、VRAMに収まる密なモデルを動かすのは非常に苦痛だ。

簡潔に説明すると： - 高いスパース性は、各行列の掛け算が十分な算術強度を持つために、非常に大きなバッチサイズ（同時に処理されるリクエストの数）が必要になる。 - そんなに大きなバッチサイズでは、HBMに重みやMLA/KVキャッシュを収めるために、かなりの数のGPU（タイプによっては8-16台）が必要になる。でも、8-16台のGPUしかないと、合計スループットが低すぎて、多くの個々のユーザーリクエストがほとんどのアプリケーションにとって受け入れられないほど遅くなる。だから、良いユーザー体験のためには256台くらいのGPUが必要だね。

これは面白いブログ記事だね。一般的な結論（「バッチ処理が必要」）は正しいけど、Mixture of Experts（MoE）モデルの推論は実際にはもう少し複雑なんだ。大きなバッチが必要な主な理由は、LLMの推論が計算能力に制限されているわけじゃなくて、VRAMから全ての重みを読み込むことに関係しているからだよ。H100のTFLOPS数とメモリ帯域幅を比べてみると、基本的に1バイトあたり300FLOPの余裕があるんだ。だから大きなバッチが必要なんだよ：メモリから読み込むパラメータや重みに対してたくさんの操作を行えるからね。この制限は「ルーフラインモデル」と呼ばれることが多い。モデルが大きくなると、もはやスケールしなくなる。なぜなら、モデルの重みがGPUメモリに収まらなくなって、GPUやノードに分散させる必要が出てくるから。NVLinkやInfinibandを使っても、これらの通信はVRAMからの読み込みより遅いんだ。NVLinkはテンソル並列処理にはまだ使えるけど、ノード間ではかなり遅い。MoEが可能にするのはエキスパート並列処理で、異なるノードが異なるエキスパートをメモリに保持して、ノード間の通信をあまり必要としないんだ。これは、すべてのエキスパートをVRAMに保持できるだけのノードがあって、他のもの（KVキャッシュや他の重みなど）に十分なオーバーヘッドがある場合にのみ機能する。だから、自然に可能なバッチサイズはかなり大きくなるよ。そしてもちろん、すべてのGPUが実際に働いていることを確認するために、これを最大化したいよね。

これはLLMの視点からの素晴らしい説明だね。計算スケジューリングの詳細な説明も見てみたいな。ハイパースケールのLLM企業は、ボトルネックやアイドルバブルを特定するために計算トレースを徹底的に調べて、負荷分散装置やパイプラインアーキテクチャ、スケジューラーを開発しているんじゃないかな。効率のためのバッチ処理の要件は、高セキュリティアプリケーションをかなり難しくする。なぜなら、無関係なクエリを隔離する通常の手法が非常に高価になってしまうから。nVidiaのvGPUはGPUメモリを時間で共有するけど、スイッチするたびにコンテキストスイッチのアンロード/リロードが必要で、重複排除があるかは疑問だね。マルチインスタンスGPU（MIG）はGPUメモリをユーザー間で分割するけど、固定パーティショニング方式だから（変更するにはGPUを再起動しなきゃいけない）、96GBのGPUを4つの24GBに分けたくない人がほとんどだよね。GPUボードにセカンドレベルメモリ（普通のDRAM）を載せることのトレードオフが気になるな。そうすれば、異なるマトリックスデータをPCIeよりも早く読み込めるようになるから、HBMがキャッシュになるんだ。著者のソフトウェアエンジニアリングに関する本の正直さもすごく好きだよ。ドライなIEEE的なものじゃなくて、大企業でのサバイバルガイドみたいな感じ。

「遅くて高価」ってわけじゃないけど、そういう可能性もあるかもね。DDR4メモリを使った2世代前のワークステーションシステムで、約1Kで3トークン/秒が出せるよ、llama.cppを使えばね。

ここにはまだソフトウェアの最適化のチャンスがたくさんあるよ。問題は、実際にDeepseekの最適化を受けるシステムが、1つは小さなGPUと大量のRAM（ktransformers）を持つものと、もう1つは全てのVRAMを持っているシステムだけってこと。例えば192GBのVRAMと標準メモリ（DGXステーション、2xRTX Pro 6000、4xB60 Dualなど）を持つシステムは、理論的にはDeepseekを4bitでかなり早く動かせるはず。Deepseekを中国語でプロンプトしないと、多くのエキスパートが起動しないんだよね。これはプルーニングには簡単な仕事になるけど、やっぱりこれから数年でエンスージアスト向けのシステムが進化して、こういうソフトウェアの最適化がもっと大規模に役立つようになると思う。Redditに16x 3090のシステムを持ってるユーザーがいて（PCIE 3.0 x4のインターコネクトで、テンソル並列処理中にフルバンド幅を使ってないみたい）、llama.cppで7トークン/秒を出してるんだ。単体の3090は24GBのメモリを1秒間に39回スキャンできるだけのVRAM帯域幅があるから、パフォーマンスを制限している何か別の要因があるんだろうね。

これを見て、AI、特に推論におけるスケールメリットがすごいことを思い出した。人々がLLMが商品化されると言うとき、市場がすごく競争的になるとは思えないんだよね。AIのスケールメリットがさらに大きくなるにつれて（トレーニングコストが増加 + バッチ推論など）、結局3社くらいがLLMを支配する可能性が高いと思う。

私はDeepseek V3をローカルで日常的に使ってるけど、手頃で速くて効果的だと思ってる。この記事はGPUを前提にしてるけど、私の意見ではこういう大きなモデルをローカルで扱うには最適じゃないと思う。私は約4000ドルで全て込みのSupermicroマザーボードを使った中程度のEPYC 9004シリーズのホームサーバーを運用してる。これは384GBのRAMを持つ単一CPUマシンで（64GBのメモリを使えば768GBにできるけど、もっと高くなる）、GPUがないから電力消費はゲーミングデスクトップよりも少ないよ。RAMの制限があるから、Unsloth Dynamic GGUFを使ってるけど、実際の使用では元のものに非常に近いパフォーマンスを発揮してる。約270GBで、コンテキストに十分な余裕がある。普段は16kのコンテキストを使ってるけど、他の用途もあるから、もっと必要な時は24kに増やせる。トークンは1秒あたり約9〜10個取れるけど、大きなコンテキストだと7トークン/秒に落ちる。似たようなセットアップで2つのCPUを使ってる人もいて、同じくらいのトークン/秒でフルバージョンを動かしてる人がたくさんいるよ。