特集
NVIDIA対抗ではない――日本スタートアップ企業のLENZOが世に問うCGLAという選択
2026年2月27日 06:06
NAIST(奈良先端科学技術大学院大学)発のスタートアップ企業がNVIDIAの座を脅かす、的な報道が昨年(2025年)ちょっと見受けられた。TVの報道もあったようで、それもあって編集部より「『NVIDIAに挑む謎の国産半導体メーカー』的な記事を一つ」というお題が降ってきた。
何でもかんでも謎にするの止めろよ、と言いたいわけだが、それはそれとしてLENZOのメンバーを見ると、後列に明らかに旧SCEでCell Broadband Engineの開発に携わった関係者が3人ほど並んでおり、何かしらCellに関係するのか？という疑問を抱くのには十分であった。
実はこの後列3人のうちのお一人はよく存じ上げている関係で、ちょっと連絡をとってみたところ、LENZOのアーキテクチャはまったくCellとは無関係であることが判明し、「ではLENZOとは何ぞや」という話になった。今回そのLENZOのアーキテクトである、NAISTの中島康彦教授(写真1)にインタビューする機会を得られたので、その内容をご紹介したい。
LENZOが注力するCGLAのアーキテクチャとは
中島教授の研究室では、コンピュータのハードウェアとソフトウェアの研究が行なわれている。そんな中島教授がここしばらく追及されているのがCGLA(Coarse-Grained Linear Array、最近CPU-Grained Linear Arrayに改称したそうな)というアーキテクチャである。
教授の研究室におられるPHAM Hoai Luan助教授が2024年のISOCC(International SoC Design Conference)に出された論文である「CGLA: Coarse-Grained Linear Array for Multi-Hash Acceleration in Blockchain Mining」は、CGLAを使ってブロックチェーンのマイニング用プロセッサを構築したというものである。
しかしこの論文を読んだら、むしろ余計に分からなくなり、インタビューに先立っていくつかメールで質問を送ったところ、回答として戻ってきたのが以下の動画だった。
以下、この動画のスライドを利用しながら説明していきたい。
まず最初に普通にCPUとCGLAの構造の違いを簡単にまとめてみた。
図1はいわゆるCPUのブロック図だ。アウトオブオーダーとかスーパースカラとか言い始めると面倒なので、1命令実行のシンプルなものである。
まずキャッシュから命令を取り込み(Fetch: フェッチ)、それを解釈(Decode: デコード)することで「どんな処理をするか」が決まる。それを実行ユニット(Execute)に送り込んで実際に処理を行なうわけだが、その際に処理対象となるデータをキャッシュから(レジスタファイルに格納させるという形で)取り込み、演算を行なう。
その結果は、レジスタファイルにまた書き込まれるわけだが、それをもう一度キャッシュに書き戻すために、ライトバックが行なわれる。これで1命令の処理が完了する。
もちろん、さまざまな処理を行なう必要があるプログラム(オフィススイートなどこの典型例)ならば、こうした仕組みが必要だが、ある種の処理では、こうしたやり方はオーバーヘッドの塊となる。
具体的に言えば、ブロックチェーンにおけるハッシュの計算とか、CNN(Convolutional Neural Network)における畳み込みとか。あと熱力学とか流体などで使われる解析などもこれに属する。要するに、直前の計算の値を基に、次の計算を行なっていくことの繰り返しを行なうようなケースだ。こうしたケースでは
- 実行すべき命令が毎回一緒なので、いちいちフェッチ→デコードを行なう必要が本来はない
- 前の値を使って処理する場合でも、一度キャッシュに書き戻し、それをまた読み込むという無駄なデータの移動が発生する
という問題が生じる。これを解決するにはどうするか？といえば、図2のように実行ユニットを縦方向にずらっと並べ、間にRAMを挟むのが一番効率的になる。
もちろん、RAMではなくレジスタファイルでも良いし、なんなら図3みたいな方法もあるのだろうが、これは本当に柔軟性に欠けてしまうのだ。
たとえば、処理A→B→C→D→A→B→C→D……みたいな流れだった場合、図3だと毎回実行の処理を変更する必要があるから、むしろ性能が落ちかねない。ある程度柔軟に処理が行なえて、しかも処理性能を引き上げやすいという意味でも図2の構成の方が妥当と言える。
この図2の方式の最大のメリット(と中島教授が力説したの)が、メモリストールが発生しないことである。図2の方式は、基本的にはデータフローである。つまり前段の処理が終わって、そのデータが届いたら次段の処理がスタートする(それまでの間、次段は休止状態にある)から、処理がスタートしたら、データがなかったという事態は原理的に発生しえない。
さらにいえば、データの移動も最小限に抑えられている。毎回全体のキャッシュに書き戻したり読み出したりという必要はなく、前段のローカルRAMから読み出しをするだけである。昨今のCPUでは演算そのものが費やす消費電力よりも、データの移動に費やす消費電力の方が大きくなっている。図2の方式はこれを最小限に抑えることが可能になり、結果的に演算効率(演算消費電力比)を最大化できる、というわけである。
よく似たCGRAアーキテクチャを採用しなかった理由
さてこの辺でいったんLENZOの話に戻る。
実はCGLAとよく似たものにCGRA(Coarse-Grained Reconfigurable Arrays)というアーキテクチャが存在する。実際、中島教授の研究室におられるLE Vu Trung Duong助教は「CTFE: A High-Efficient Heterogeneous Cryptographic CGRA for Diverse Security Applications」という論文を2025年に出されているし、古いところでは2019年のFCCM(International Symposium on Field-Programmable Custom Computing Machines)には「Impact of FPGA Architecture on Area and Performance of CGRA Overlays」なんていう論文が出ている。これは何か？という話を説明したい。
まずCGLAだが、図1～3は基本的に機能固定の実行ユニットで構成されている。図4は冒頭に紹介したCGLAの論文に示された図であるが、(b)の右側がCGLAの本体である。ここでPE(Processing Element)が図1～3の「Execute(実行ユニット)」に相当するものと考えてもらえれば良い。そのPEはALUとコンテキストレジスタ、それと出力レジスタからなるが、この出力レジスタが、図2と3でいう「RAM」にあたる部分だ。
ではCGRAは？というと、大きな構造としては図2の(b)に近い。問題はそのPEの中身(つまり(c)の部分)で、ここがReconfigurable Processor(再構成可能なプロセッサ)になっているというものだ。
再構成可能なプロセッサは、要するに用途に応じて非常に短い時間(一番高速なものだと1サイクル)で処理の中身を変化させられるものだ。
たとえば汎用プロセッサだと、ALUとひと口で言っても、Adder(加算器)だったりMultiplier(乗算器)だったりDivider(除算器)だったりShifter(シフター)だったり、とさまざまな機能を持つ。そのため、ALUの中は、実際はAdderとMultiplierとDivider……という具合に、さまざまなブロックの集合体で構成される。
それに対して再構成可能なプロセッサの場合、用途に応じてAdderだったりMultiplierだったり、と動的に構成を変えることが可能である。
この再構成可能なプロセッサのメリットは、回路規模を最小化できることだ。たとえば先ほど処理A→B→C→D→A→B→C→D……という流れを説明したが、CGLAでこれを実装する場合、PEの#1～#4に、それぞれA/B/C/Dという処理を割り当ててデータを流すことになる。ところが再構成可能なプロセッサの場合、図3の構成のまま、1サイクルごとに処理をA/B/C/Dと変化させることで、同じ処理ができることになる。
この再構成可能なプロセッサ、歴史的にも何度か登場しており、古いところでは東芝のMePとかIPFlexのDAPDNA、現在も販売しているものとしてはルネサステクノロジのDRPなどがあるが、実はAIプロセッサでもこれを採用しているものがある。それが、SambaNovaのRDUだ。このRDUはまさしくCGLAのお手本とでもいうべき実装であり、PCU(Pattern Compute Unit)とPMU(Pattern Memory Unit)からなる再構成可能なプロセッサ同士をメッシュ構造でつなぎ、データフロー的に制御する仕組みになっている。
ただし、LENZOはこのCGRAの方策を取らなかった。最大の理由は中島教授の「コンパイル時間が短くなければコンピュータではない」という信念に基づいたものである。
一般に再構成可能なプロセッサの場合、最大の難点はプログラミングの難しさである。先にちょっと触れたIPFlexのDAPDNAの場合、コンパイルにはMathWorksのMATLABを利用し、ここでモデルベースで設計した出力を変換するという手間のかかることをしていた。SambaNovaの場合も、ユーザーが直接PCU/PMUのプログラミングをするのではなく、SambaNovaがあらかじめ開発したライブラリを経由してアクセスする形になっている。
ところがCGLAの場合、PUの中身というかALUが固定機能であるがゆえに、JITでのコンパイルが可能になっており、これによってプログラミングが容易だし、必要ならダイナミックにプログラムを変更することも可能である(この仕組みは後述)。ちなみにCGRAの場合、コンパイルに10時間以上かかる(そもそもコンパイルが不可能な場合もあるらしい)という話であった。
CGLAの実装方法
ではいよいよCGLAの実装の話に移りたい。
LENZOのトップページには謎の動画(図5)があって、ところがこれが何を意味しているのかがさっぱり分からないからだ。
現在のCGLAの内部構造をまとめたのがこちら(図6)である。まず最初に説明すると、真ん中がALUの構成である。①がAI用の構成、③がブロックチェーンマイニング用で、SHA256によるHash演算を高速で行なうためのもの。そして②が同じくブロックチェーンマイニングではあるが、こちらはscrypt(鍵導出関数)向けのものである。SHA256ではメモリアクセスがほとんどないが、scryptでは激しくメモリアクセスを必要とするので、これ向けの構造となっている。
本来はこの①～③を選んで実装するわけだが、現在はまだFPGA上のプロトタイプということもあり、実際には①～③のすべての機能がALUに実装されているという話であった。ちなみにALU全体の幅は64bitであり、これを真ん中の上のように、FP32×2とかINT4×16とかSIMD風に処理を分割することもできる。
そのALUと、さきほど図4の(c)にあるように、レジスタというかメモリを組み合わせたものでPEを構成することになる。このPE同士の物理的な接続法は？というと、右図のように1列×64行のリング構成である。要するに64個のPEが数珠つなぎになっているわけだ。
この右上を切り取ったのが図7である。64個のPEが8行8列で並び、AXIにぶら下がっている形なのが分かるかと思う。最初のPE(これでいえば#1、#9、#17、……#57)はAXIから直接データやプログラムを受け取ってセット、その先はディジーチェーンでつながり、列の最後(#8、#16、……#64)の出力がまたAXIに戻される格好である。
ここでは「Chip #0/#1」となっているが、これは物理的に異なるチップというわけではなく、PEを64個まとめた塊をチップと呼んでいるものと思われる。このチップも複数個、ディジーチェーンでつなぐことが可能だ。
なので各PEに命令をセットしたり、最初のデータを送り込んだり、結果を受け取ったりといった仕事はAXI(Advanced eXtensible Interface、Armが策定した標準インターフェイス規格)のバスマスターの仕事となっている。ちなみにAXIなのは単にそれが使いやすかったからであって、別に独自のローカルバスでも構わないという話であったが、その辺は実装依存ということになる。
ただこの構図はプログラマーからすると、ちょっとコードを書くのが面倒である。そこで論理的には64行4列の循環的な構造に見せるようにした。これが図6の左側の、同心円である。LENZOのホームページで示されている動画は、要するに論理的にどのユニットが使われているのかを動的に示しているものであったのだ。
図4の(b)のCGLAのユニットが、4つのPEが並んでおり、各PEの出力段にRow Connectionが入って、それが縦方向にずーっと並んでおり、そして一番下のPEの出力が最上位のRow Connectionに戻されているのが分かるかと思う。これを円周状に示したのがこの図形というわけである。
余談になるが、各PEにはそれぞれキャッシュが搭載されている。これは読み込み用ではなく、書き出し用のキャッシュで、要するに図2の(c)の図の中の、PEの下段にあるレジスタをもう少し大規模化したものである。実態としてはスクラッチパッド的なSRAMらしいのだが、プログラマーからはそれが見えない形になっており、なのでキャッシュと呼んでいるとのこと。
またFFTのように大量のデータの転置が発生する場合、このキャッシュ(というかSRAM)を使ってダブルバッファリングを構成することで対応できるという話だった(このあたりの詳細は以下の動画で説明されている)。
現在はFPGAで実装実験。商品化はもっと先
このCGLA、現在はFPGA(XilinxのVersal Prime)上で動作している。実際にこれを利用してさまざまなLLMを稼働させた場合の性能を示したのがこちら(図8)である。
パラメータの数が増えるとやはりメモリに収まりきらない(煩雑にPEにウェイトを送る必要があり、ここが律速段階になってしまう)ので、これを解決するにはPEの数をもっとスケールさせるか、PE内にウェイト用の大容量ローカルメモリを持つしかないのだが、PEの数をスケールさせるのはともかく、ローカルメモリを持つのは効率性の観点からするとよいソリューションではなさそうだ。
そのPEの数のスケールであるが、2025年8月時点ではPE(というかChip)の数を増やしても性能がスケールしないという問題が出ていた。ところが2026年1月にはこれがある程度解決している(図9)。
解決の糸口はFPGAにVersal Prime Gen2を利用したことにある。何が問題だったかというと、Versal Primeに搭載されるCortex-A72×2では8個のChipに対してのAXIの制御が間に合っていなかった、ということらしい。Versal Prime Gen2ではこれがCortex-A78AE×8になり、各々のCPUで1個ずつAXIを制御することでオーバーヘッドが大きく減った、ということだそうだ。案外、AXI側の負荷が大きいのはまぁ仕方がないことなのかもしれない。
将来的なロードマップとして示されているのがこちら(図10)。さきほどもちょっと触れたが、現在CGLAのPEというかChipは、外部のAXIから制御とデータ入出力を行なうことになる。なので、たとえばこれをPCIeに置き換えるのは容易であり、チップレット化したうえで複数枚のカードでホストに装着する、なんて接続方法も考えられるとしている。
ただこれは残念ながらやや遠い将来の話で、まず直近はブロックチェーンマイニング用のチップを28nmでテープアウトするのが最初の目標となる。時期については2028年頃という話であったが、これは中島教授の研究室が(教授が定年を迎えるのに伴い)2028年3月で閉鎖になるので、それまでにということだそうだ(ちなみに定年後はLENZOに居場所を移すだけなので何も変わらない、と笑っておられた)。
そんなわけで「NVIDIA一強を打ち破る」的な話も、もちろん嘘ではないのだろうが、それよりもCGLAというアーキテクチャを世に問うための試みという方が実情に近いのがLENZO、というわけだ。面白いのは別にAI特化型アクセラレータというわけではなく、むしろDSPに近い性格を持つ構成なことだ。汎用というにはちょっと用途が限られるが、意外に実用性は高そうに思える。うまくLENZOのビジネスが軌道に乗ることを祈ってやまない。