ハクソク

世界を動かす技術を、日本語で。

GPU専用で動作するCPU

45日前原文(github.com)

概要

  • NeuralCPUは、全てのCPU構成要素（レジスタ、メモリ、フラグ、プログラムカウンタ）をGPU上のPyTorchテンソルで管理
  • 全算術演算が訓練済みニューラルネットワークによって実行
  • Kogge-Stoneキャリー先読み加算器やバイトペアルックアップ乗算など、従来のハードウェア設計をNNに適用
  • ARM64命令セットを完全サポートし、全ての状態遷移がGPU上で完結
  • 性能・精度検証済み、DOOMレイキャスターなどのデモや347の自動テストを搭載

NeuralCPU：GPU上で動作するニューラルネットワークCPUの概要

  • CPUの全構成要素（レジスタ、メモリ、フラグ、プログラムカウンタ）をPyTorchテンソルとしてGPU上に常駐
  • ALU演算は全て訓練済み.ptモデル（PyTorchモデル）を経由して実行
  • 命令デコード、ALUディスパッチ、状態更新も全てGPU上で完結、CPU⇔GPU間の往復通信なし
  • 加算・減算はKogge-Stoneキャリー先読み（8パス）、乗算はバイトペアルックアップ、ビット演算はNN真理値表、シフトはアテンションベースのビットルーティング
  • 算術関数（sin, cos, sqrt, exp, log, atan2）も全てNN経由
  • 整数演算は100%精度、347件の自動テストで検証済み

ALU演算と対応モデル

  • ADD/SUB/INC/DEC：Kogge-Stone CLA（carry_combine + full adderモデル）
  • MUL：バイトペアルックアップテーブル（256×256×16）
  • AND/OR/XOR：ベクトル化NN真理値表（7×4）
  • SHL/SHR：アテンション型シフトネットワーク
  • CMP：ニューラル減算
  • sin/cos, sqrt, exp, log, atan2：それぞれ専用の深層NN
  • 全23モデル（約135MB）、うち13モデルが実際のCPU実装に直結

性能とベンチマーク

  • **Apple Silicon（MPS, PyTorch 2.10.0）**で各演算1000回の平均レイテンシ計測
    • exp, log, mul, and, or, xor：21μs（O(1)単一パス）
    • add, sub, cmp：248μs（O(log n)キャリー先読み）
    • shl, shr：434μs（3バッチパス, アテンション）
    • sqrt：522μs（2パス＋バッチパッド）
    • atan2：935μs（6パス＋バッチパッド）
  • 全モデルのロード時間は60ms
  • 1命令あたり136～262μs（命令ミックス依存）、約4,975 IPS
  • 乗算は加算の12倍高速（従来CPUと逆転現象）

アーキテクチャの特徴

  • NeuralCPUはシミュレータでなく、GPUネイティブなCPU
  • 全状態（レジスタ、メモリ、フラグ、PC）はGPU上テンソル
  • 命令フェッチ、デコード、実行、書き戻しまで全てGPU内で完結
  • ALUは訓練済みNNバンクとして動作
  • ホストCPU側での演算は一切行わない

実行モード

  • Neuralモード（標準）：全ALU演算を.ptモデル推論で実行
    • 例：cpu = CPU(neural_execution=True)
  • Fastモード（--fast）：ALU演算をPyTorchのネイティブ演算（torch.add等）で実行し、最大1.35M IPS（バッチサイズ32768時）

Metal Computeカーネル

  • kernels/mlx/：Apple MLX用Metalシェーダー（Pythonインターフェース）
  • kernels/rust_metal/：Rust+objc2-metal+PyO3によるMetal API直実装
    • GPU側でシステムコール処理、基本ブロックキャッシュ、ニューラルディスパッチ、アウトオブオーダー実行も対応
    • DOOMベンチマーク付属

命令セット（ISA）

  • テキストアセンブリ（ncpu.model）
    • MOV, ADD, SUB, MUL, DIV, AND, OR, XOR, SHL, SHR, INC, DEC, CMP, JMP, JZ/JNZ, JS/JNS, HALT
  • ARM64バイナリ（ncpu.neural）
    • ARM64実バイナリエンコーディングにも対応

プロジェクト構成

  • ncpu/neural/：完全GPUニューラルCPU（ARM64, 12K行）
  • ncpu/model/：モデルベースCPU（テキストアセンブリ用）
  • ncpu/tensor/：テンソルベースARM64カーネル
  • kernels/：Metal Computeカーネル（Python+Metal, Rust+Metal）
  • models/：23種の訓練済み.ptモデル
  • demos/：DOOMレイキャスター等デモ
  • programs/：アセンブリプログラム
  • tests/：347件のテスト
  • benchmarks/：性能ベンチマーク
  • paper/：研究論文
  • main.py：CLIエントリーポイント

DOOMレイキャスターデモ

  • 全演算を訓練済みNN経由で実行するDDAレイキャスター
  • Neuralモード：約2.5FPS、Fastモード：約5,000FPS
  • 両モードでアルゴリズム・出力は完全一致（違いは演算経路のみ）
  • **固定小数点演算（スケール1024）**で32ビット整数のみ使用

テスト・ライセンス

  • pytest tests/ -vで全347件のテストを実行可能
  • MITライセンス

まとめ・ポイント

  • 従来のハードウェア設計手法をNNへ直接転用可能であることを実証
  • キャリー先読みやベクトル化による大幅な高速化
  • 全CPU状態がGPU上に常駐、真のGPUネイティブCPUを実現
  • **演算ごとの計算量階層（O(1), O(log n), O(n)）**が明確
  • 研究論文・詳細ドキュメント・デモ・テストが充実した先進的プロジェクト

Hackerたちの意見

6年前に予言された通りだね。
└
https://en.wikipedia.org/wiki/Xeon_Phi#Knights_Landing ?
面白いアイデアだね。驚いたのは、MULがADDよりも速くなる逆転現象だよ。ニューラルLUTが逐次依存性を取り除く一方で、加算器はまだプレフィックスステージが必要だから。
最近、なんでGPUって呼ぶんだろう？データセンターのラックにあるほとんどのGPUは、そもそも「グラフィックスを処理」してないしね。
└
一般処理ユニット、粗並列化ユニット、生成手続きユニット、無駄に利益を追求するユニット。
└
専用用語のGPGPUはあまり浸透しなかったね。
└
CPU = 計算　GPU = 補完
└
VPU。ベクター/ビデオ処理ユニット。
数年前に、MULとADDは1サイクルか数サイクルで実装できるって教わったんだけど。複雑さは同じくらいだと思ってた。何か見落としてるのかな？それに、GPUのADD/MUL実装を使うことってできるの？GPUが得意とすることだし。
└
任意の2つの数を1サイクルで掛け算するには、ALUに専用のハードウェアを組み込む必要があるよ。そうしないと、いくつかの足し算や論理シフトを組み合わせることになるからね。GPUのADD/MUL機能を使わない理由は、チャレンジの精神に反するからじゃないかな。 ;)
面白い実験だけど、CPUを完全に排除できると思ってる人がどれくらいいるのかな？そういう意見が増えてる気がする。情報を空間を通じて伝えるコストは、ここでは根本的に違う方法で扱われてる。CPUでは直接対処されて、実際のレイテンシはできるだけ最小限に抑えられる。未来を予測する方法や、各デバイス（コアコンプレックス）の空間的範囲をできるだけ小さく保つことでね。GPUは大規模な並列処理でレイテンシを隠すから、比較的遅いネットワークでも優れたパフォーマンスが出せるんだ。レイテンシを隠すのは、分岐が多くて直列的なワークロードにはうまく対応できない。論理スレッドは1つしか持てないからね。CPUはこの分野で優位だよ。なぜなら、直接目的を狙ってるから。効率的で正確な制御フローの決定をすることは、大量のデータを処理するよりも価値があることが多いんだ。ただ、このルールには非常に人気のある例外がいくつかあるだけなんだけど。
└
CPUがなくなることはないと思うけど、最終的にはCPUとGPUが異種計算ユニットの1つのシステムに統合されるんじゃないかな。
└
> CPUを完全に排除できると思ってる人がどれくらいいるんだろう。PS5みたいにAPUがGDDRに接続されてるシステムはどう分類するの？主な問題はメモリ容量が限られてることだよね。VRAMの代わりにGPUクラスのHBMをパッケージに載せて、CPU部分には普通のRAMを使ったシステムが出てくるかもしれないね。
└
> どれくらいの人が本気でCPUを完全に排除できると思ってるんだろう。そういう感情が高まってるみたいだね。この感情は最近のものじゃないよ。GPGPUが話題になって以来、最初にそれを聞いた人たちがプロセッサアーキテクチャを理解せずに、GPUが魔法のようにすべてを速くするって興奮してるのを見てきた。2011年に管理職の人と話したとき、彼が新しいNvidiaテスラでPHPを動かすことに夢中になって、ウェブサイトがどれだけ速くなるかを語っていたのを鮮明に覚えてるよ！FPGAについても同じような話が何度も出てくるね。最近の感情の変化は違うもので、GPUの「グラフィックス」の起源が歴史に埋もれてしまったみたい。最近、GPUで画像をレンダリングするって話をしているときに、意外にも長い間「安定した拡散」のことを指していると思っている人に出会ったことがあるよ。今では、GPUの「G」はおそらくGPGPUを指してるんだろうね。
└
CPUを排除することはないと思うけど、関係性は逆転するかもね。CPUがGPUを呼ぶのではなく、GPUが中央コントローラーになってプログラムを作り、CPUにタスクを実行させるようになるかもしれない。
└
メインフレームはまだ存在するから、CPUはなくならないよ。めっちゃ便利なツールだしね。
「GPU上で完全に動くCPU」って、CPUの抽象を構築するために慎重に作られたプログラミングプリミティブのセットを想像するなぁ…「すべてのALU操作は訓練されたニューラルネットワーク。」おお…おお。面白いね。ただ、私が期待してた「面白さ」とはちょっと違うけど。
└
精度エラーで即クラッシュしないのって面白いよね？それって慎重に作られてる感じがする。
└
何を考えてるのか教えてくれたら、別のことを試してみるよ！
└
ペンティアムプロセッサをエミュレートしてるの？ :)
誰かがこのISAをターゲットにしたLLVMPipeを実装する必要があるね。そうすれば、ソフトウェアのOpenGLエミュレーションを動かして「ハードウェアアクセラレーション」って呼べるようになるよ。
└
なんか不安になるな。
└
確かに、それはハードウェアで遅延させられるだろうね。
みんな、私のプロジェクトを見てくれてありがとう！これは純粋に「できるかな？」って感じのもので、最終的な目標は、GPUだけで動くOSを作ること、または学習システムで構成されたOSを作ることなんだ。
└
こんにちは！このアイデアは確かに面白いと思うよ。良い並列オペレーティングシステムを作ろうとする長い歴史があるけど、どのプロジェクトも成功したとは思えないな。このことに興味があるなら、この記事は読む価値があるよ。並列コンピュータのオペレーティングシステムが今までうまくいかなかった理由はよくわからないけど、今あるオペレーティングシステムが十分良くて、馴染みがあるからじゃないかな。 [0] https://news.ycombinator.com/item?id=43440174
└
「GPU上で」って言ってるのが面白いね。本当は「テンソルを使って」って意味なのに。GPUは計算シェーダーを自然に実行できるし、簡単にCPUのように動作できるよ、CUDAを使えばね。これは「NPU上のCPU」に近い感じで、君のNPUがGPUってことだね。
└
これ、めっちゃ面白いし、ハッカーニュースの精神そのものだね。投稿ありがとう:)
└
GNU/GPU
ドゥームのベンチマークを取る時が来たね。これからの天才モデルはCPUなんて必要なくて、テンソルやレクティファイア回路だけで済むんだ。もしCPUが必要になったとしても、ただ想像するだけでいい。適応的なスパース実行を持つロービットモデルなら、パフォーマンスを保ちながら想像することもできるかも。実質的には、ニューラルPGAの能力だね。
いいね。でも、GPUにCPUの仕事をさせるためには、まだCPUからGPUにコマンドを送る必要があるよ。
└
> いいね。でも、GPUにCPUの仕事をさせるためには、まだCPUからGPUにコマンドを送る必要があるよ。ラズベリーパイのGPUって、最初に立ち上がってからCPUを初期化するんじゃなかったっけ？この技術があれば、その余分なステップは必要なくなるね。