AMD Alveo V80 FPGA PCIカードを「貧乏人のTaalas HC1（チップに焼き付けるLLM）」として使えるかという考察

要約（TL:DR） - 仮想通貨時代に、FPGAのPCIボードが大きな話題だったのを覚えています。AMDのAlveo V80 FPGAカードで、Taalas HC1（LLM-on-a-chip）に近い性能を再現できないかと思いました。そのアイデアを、実現可能性／妥当性チェックのためにGemini Proに投げました。FPGA上での、推測的デコーディング系のセットアップのようだ、と提案され、Qwen3.5 4bのQ4で3,200 tk/sくらい、あるいは9bで1,400 tk/sくらいは出せるかもしれないと言われました。Taalas HC1の速度ではありませんが、それでもかなり速い（可能性はあります）。ここに投稿して、誰かがこの手のことをすでに試しているか確認したいです。ちなみにAMD V80 FPGAsは1万ドル近くします。

それで、TaalasがLlama 3.1 8bの重みをチップに焼き付けて、なんと15,000 tk/sを出しているのを見ました。彼らがこのハードウェアを実際にいつリリースするのかは分かりませんが、考えるきっかけにはなりました。もちろん、モデルの重みをチップに焼き付けてしまえば、それで終わりで、その重みをずっと使い続けるしかないのですが、もしそれが良いモデルなら、それでもかなり素晴らしいですよね。

私が仮想通貨マイニングをやっていた頃の話です。BitMainのL3+というASICマイナーがありましたが、Script Algoは実質的に複数のチップに「焼き込まれて」いて、それによってscript algoをめちゃくちゃ速く回せるようになっていました。もちろんGPUでもスクリプトマイニングはできますが、ASICマイナーに比べると遅すぎました。これはTaalasのチップが、GPUに対してハードコードされたモデルを提供できるのと同じ理由です。

人々がASICマイナーに飽きたのは、ASICが得意なのは基本的に1つのAlgoだけで、より効率の良いものが出てきた瞬間に、6か月前に買ったやつが今やただの紙の重りになってしまうからです。そこからField Programmable Gate Arrays（FPGA）です。FPGAは、両方の良いところを持つはずだと言われていました。GPUでマイニングするより速いはずで、しかも再プログラム可能なので、ASICのように焼き付け済みの1つのAlgoに縛られないはず、というわけです。つまり実質的には、再プログラム可能なASICのようなもの。ちょうどこの頃にETHがプルーフ・オブ・ステークへ移行し、仮想通貨のマイニング全般が大きく失速して死んでいきました。でも私はおそらく、Xilimix Alveo U55C（16GB HBM）PCIe FPGAを買うまでに数か月というところでした。結局買いませんでしたが、今なら次の理由で少し後悔しています。

Taalasの「チップ上のLLM」が信じられないほど15,000 t/sを出しているのを聞いて、なぜ誰かがFPGAのPCIカードでも同じことをやらないのかと思いました。XilinixのU55CのようなFPGAカードを使って、Taalasがやったのと同じことができないでしょうか。つまり、FPGAのHBMに重みを焼き付けて、重みがチップに焼き付けられている場合と同様の速度ブーストを得つつ、FPGAの再プログラマブル性という利点も享受できるのでは？

このアイデアをGemini Proに投げて、正気度チェックをしました。Alveo U55Cはメモリ面で制約が大きすぎましたが、AMD Alveo V80（おそらくAMDがXillinxを買収した）には興味深い仕様がいくつかあって、Geminiは、それをうまく使えば、Tallasとは同レベルではないにせよ、現在のコンシューマ向けGPUの速度を上回る形で推論を加速できる「小さな可能性」があると思っているようでした。以下がGeminiからの直接の回答です：

質問：思考実験：Taalasに近いレベルまで推論を加速するには、Alveo V80をどう最適に使うべきでしょうか。推論を加速するために新しいアイデアを最大限考えてください。何をするか（コードではなく）概要を教えてください。

これはまさに、私が没頭するのが大好きな種類のハードウェアパズルです。V80でTaalas HC1を追いかけるには、V80をGPUのように扱うのをやめて、その本質である「空間（spatial）計算」と「プログラマブルなメモリコントローラ」を活用する必要があります。TaalasのようにHBMの壁を完全に取り除くことはできないので、この思考実験ではHBMを実質的に“見えなくする”ことに焦点を当てます。

以下は、そのギャップを埋めるV80推論エンジンの構成イメージです。ここでは、このコンセプトを「動的アクティベーション・ルーティング付きデュアルティア推測（Dual-Tier Speculative Fabric with Dynamic Activation-Routed Fetching: DARF）」と呼びます。

1. 「Taalas-Lite」SRAMドラフトコア

V80には、内部のUltraRAMとBlock RAMがだいたい673MBあります。これをすべて、強く蒸留された、極端に量子化された「ドラフト」モデルに割り当てます。

コンセプト：ターゲットのLLMの小さなバージョン（例：5億パラメータ）を学習し、1ビットまたは1.5ビット（三値）の重みに量子化します。これならオンチップのSRAMに完全に収まります。

実行：重みがすべてオンチップにあるため、このドラフトモデルはTaalas HC1とまったく同じ動作になります。HBMのフェッチ待ちによる遅延はゼロで、Versal AI Enginesを使って、推測トークンを爆速で吐き出せます。

1. 動的アクティベーション・ルーティング付きフェッチ（DARF）

ここで、メインの高精度モデル（例：8Bパラメータモデル）を、32GBのHBMに格納したものについて、HBMのボトルネックを解決します。FPGAは散在して不規則なメモリアクセスが得意で、これはGPUを確実に詰まらせます。

コンセプト：LLMには巨大なアクティベーションのスパース性があります。推論中は、ある層にある多くのニューロンが単に0を出力して、次の層に寄与しないのです。

実行：V80のFPGAファブリック内で、カスタムのメモリコントローラをプログラムします。ある層の計算が始まる前に、小さな予測ルーティングアルゴリズムが入力トークンを見て、「本当に必要になる」特定の重みを決定します。HBMから8Bのモデル行列全体を盲目的にストリーミングするのではなく（それだとスループットが制限されます）、カスタムのメモリコントローラが細粒度の「scatter-gather（散らして集める）」読み出しを行い、重要になる重みのうち15%〜20%だけをフェッチします。フェッチするデータを5分の1に抑えることで、820 GB/sのHBM帯域を実質的に“4 TB/s接続”のように振る舞わせられます。

1. 非対称な、ハードウェアで焼き付けた量子化

Taalasはカスタムの3ビットおよび6ビットの計算を使います。私たちはそれをさらに一歩進め、特定モデルの重みの分布に合わせて数値の扱い（算術）を調整します。

コンセプト：通常のプロセッサは線形フォーマット（INT4, FP8）を使います。V80のルックアップテーブル（LUTs）を使って、カスタムの対数数値体系（Logarithmic Number Systems: LNS）や、偏ったビット幅（例：3.2ビット精度）を作ります。

実行：HBM上の重みはこのカスタムフォーマットでパックされます。DARFがそれらをチップへストリーミングすると、重みはこの“奇妙な”数体系のために物理的に合成された、カスタム配線済みのDSPスライスへ直接投入されます。これにより、HBMを1回読み出すたびに、モデル密度を大幅に高められます。

1. 連続的な空間パイプライニング

GPUはモデルを時間方向に処理します。つまり「層1をロード→計算→メモリへ保存」「層2をロード→計算→メモリへ保存」というふうに進みます。

コンセプト：V80をALUとして扱うのではなく、組立ラインとして扱います。

実行：トランスフォーマーのアーキテクチャをシリコン上に物理的にマッピングします。HBMは、カスタム量子化された重みを連続的にストリーミングします。トークンデータはLUTから順次流れ（層正規化を実行）、AI Enginesへ（DARFでフィルタされた行列演算を実行）渡され、さらにチップ上の次の物理セクタへ出ていきます。トークンデータは、最終的な予測が行われるまで外部メモリへ戻りません。

結果：

SRAMドラフトコアを使って、メモリ待ちなしで5〜10トークンを即座に生成します（Taalasのおまじないトリック）。その後、HBMからDARFを有効にしたメインモデルをストリーミングして、それらのトークンを一発で検証します。ただし、カスタムの非線形精度を使って重みの一部だけをフェッチするため、検証ステップにかかる時間は通常の一部で済みます。

HBMを駆動するだけで、静的なSRAMよりも単純に多くのエネルギーを必要とするため、原始的なパワー効率（トークンあたりのジュール）ではTaalasに対してやはり負けます。ですが、トークン毎秒の観点では、このアーキテクチャによってV80を同じような領域まで押し上げられる可能性があります。

これを作るとしたら、こうした高度にスパースで、物理的にパイプライン化されたFPGA環境にマッピングするのに最も適した、具体的なオープンソースのモデル・アーキテクチャ（Llama、Mistral、あるいはMixture-of-Expertsなど）として、あなたはどれがベストな候補だと思いますか？

私は次のように返答しました：「Q4（または収まるならそれ以上でも）で、たぶんQwen3.5の9bか4bを考えていました。これは可能ですか？また、私があなたが説明したアーキテクチャを使った場合、トークン毎秒はどのくらいになると思いますか？ 」

そして次のような返事が返ってきました：

「絶対に可能ですし、そうしたモデルサイズはV80のメモリ容量にちょうど良い“甘い領域”を突いています。Qwenモデル（現在の2.5世代の話であっても、仮に3.5があるとしても）は建築面での効率が非常に優れており、この種のハードウェア操作の優れたターゲットになります。」

以下では、Q4精度のQwen 4Bまたは9Bを、仮想の“DARF”アーキテクチャにどうマッピングするか、そしてトークン毎秒（tok/s）を計算するための理論上の数式を示します。

1. メモリマッピング（“適合”チェック）

4ビット（Q4）量子化では、メモリフットプリントはかなり扱いやすいです：

Qwen 4B（Q4）: およそ2 GBのメモリが必要。

Qwen 9B（Q4）: およそ4.5 GBのメモリが必要。

これらはいずれもV80の32 GBのHBM2eに余裕をもって収まります。ですが、私たちのアーキテクチャは“デュアルティア”方式であることを思い出してください。V80には内部SRAMが約673 MBしかないため、4Bおよび9Bモデルは“瞬間的なDraft Core（ドラフト・コア）”としては機能できません。

セットアップ：Qwen 4Bまたは9BをHBMに入れて“メインのバリデータモデル”とします。その上で、600 MB未満に収まるように1ビットまたは2ビットで量子化した、非常に小さな、10億パラメータ未満のQwenの派生モデルを、SRAM上に常駐させ、“スペキュラティブなDraft Core”として使う必要があります。

1. 理論上の数式

従来のLLM推論（バッチサイズ1）では、絶対的な速度上限はメモリ帯域によって決まります。V80は巨大なHBM帯域820 GB/sを持っています。

ステップA：標準ベースライン（カスタムなし）もしV80を通常どおり動かして、トークンごとに毎回モデル全体を取りに行くなら：

Qwen 4B: 820 GB/s ÷ 2 GB = 410 tok/s

Qwen 9B: 820 GB/s ÷ 4.5 GB = 182 tok/s

ステップB：DARFマルチプライヤー（スパース性）を適用する 我々のDynamic Activation-Routed Fetching（動的な活性ルーティングによるフェッチ）では、トークンを捕捉し、数学的にアクティブな重みだけをHBMから読み出します。保守的に75%のスパース性（つまり、トークンごとにHBMからモデルの25%だけを読み出せばよい）を仮定すると、有効帯域は4倍になります。

Qwen 4B（DARF）: 410 tok/s × 4 = 1,640 tok/s

Qwen 9B（DARF）: 182 tok/s × 4 = 728 tok/s

ステップC：SRAM Draft Core（スペキュラティブ・デコーディング）を適用する HBMがスパースなフェッチを行っている間、SRAM上の極小Draft Coreが、メモリレイテンシなしで先行して3〜5個のスペキュラティブ・トークンを即座に生成します。メインモデルは、それらを単一バッチで検証するだけです。高度にチューニングされたスペキュラティブ・デコーディングのセットアップでは、2倍〜2.5倍の高速化が得られます。ここでは保守的に2倍マルチプライヤーを使用します。

Qwen 4B 最終値: 1,640 tok/s × 2 = 3,280 tok/s

Qwen 9B 最終値: 728 tok/s × 2 = 1,456 tok/s

結論

Alveo V80を、このカスタムで高度にスパースな空間パイプラインとして用いるなら、理論上、Q4の4Bモデルで約3,200 tok/s、9Bモデルで約1,400 tok/sを達成できる可能性があります。

Taalasは“5桁”のトークンレートを狙っていますが、商用で入手できる単一のハードウェアで1,400〜3,200 tok/sを出せるなら、やはり目の眩むほど速いです。同じモデルをハイエンドのコンシューマGPUで動かすより、少なくとも10倍〜15倍速くなります。

もし実際にこれを合成しようとするなら、ボトルネックとして一番大変なのはAIの計算ではなく、散らばった読み出しを扱うためのVerilog/VHDLでのカスタム・メモリコントローラを書くことだと思います。

もちろん、これらは全部Gemini Proによる“口先だけで煽る”ようなシッポ振り的な幻覚に過ぎないかもしれませんが、似たようなことを調べている人がいて、実際に何か試したことがあるのかを見たくて、ここに投稿してみようと思いました。

あとはAMD Alveo V80を買うために$9500が必要だな、LOL