AI・機械学習

HEIR、準同型暗号コンパイラプロジェクトのアップデート

Updates on HEIR, the Homomorphic Encryption Compiler Project (jeremykun.com)

30 pointsby turtleyacht2026年9月5日0 コメント

要約

HEIRは、入力プログラムを暗号化されたデータ上で直接動作するプログラムに変換するコンパイラです。この記事では、HEIRが機械学習モデルをコンパイルする能力に焦点を当て、その動作原理、パフォーマンス、およびモデルをHEIRに取り込むプロセスについて詳細に解説しています。特に、準同型暗号による推論は、入力データに関する情報を一切漏らさずに実行できるプライベートな推論を可能にしますが、現状ではパフォーマンスの課題も存在します。

全文翻訳

HEIR、準同型暗号コンパイラプロジェクトのアップデート

2026年8月14日、私はGoogle Securityブログに、私たちの準同型暗号（HE）コンパイラであるHEIRのアップデートに関する記事を公開しました。この記事は、その補足記事であり、ここでは単語数や専門用語の制限がなく、率直に話すことができます。さあ、始めましょう。

リンク先の企業ブログ記事を読まないことを前提とすると、HEIRは入力プログラムを、暗号化されたデータ上で直接動作するプログラムに変換するコンパイラです。準同型暗号の保証は、暗号を解読していないと仮定した場合、プログラムを実行しているコンピュータが、暗号化された入力の生成に使用された平文データに関する情報を一ビットたりとも取得できないということです。入力、出力、または中間値に関する情報は一切漏れません[1]。

ブログ記事は、HEIRが事前学習済みMLモデルをコンパイルする能力に焦点を当てており、コンパイル可能な小さくも非自明なモデルの4つの例を挙げています。これにより、準同型暗号はサービスが完全にプライベートな推論を提供することを可能にします。この記事の後半で、これがいつ、どこで役立つかについてさらに詳しく説明します。まず、これらの例のコンテキストでHEIRがどのように機能するかをより具体的に理解し、プロジェクトの将来のロードマップ（私の見解）を概説したいと思います。HEIRの内部構造について深く掘り下げることはしません。記事が長くなりすぎるからです。もしそれを望むなら連絡してください。しかし、heir.devには読むべきドキュメントがたくさんあり、今年のASPLOSで私が話した最近の（ペースの速い）講演も見ることができます。

ブログ記事の背後にあるリポジトリ

ブログ記事は、HEIRでコンパイルされた例のリストで締めくくられています。これらの例は、自分でクローンして実行できるGitHubリポジトリ[2]を指しています。最大のハードルはbazelのインストールですが、その後はbazelがすべてを管理してくれます[3]。

簡単な実行時比較

試すのに最も簡単で高速な例は、クレジットカード不正検知器です。これは、Kaggleデータセットで学習された、シグモイド活性化関数を持つシンプルな3層フィードフォワードネットワークです。線形層の次元は128、64、そして2（後者は不正と非不正の2クラスのロジット）です。

基本的な例は1行で実行できます。

bazel run -c opt //demos/cc_fraud/lattigo:evaluate_fhe

このコマンドは、(事前学習済みでチェックイン済みの) cc_fraudモデルをLattigoバックエンドにコンパイルし、サンプル入力で実行します。上記のコマンドの出力は以下の通りです。

Loading test row 0 from /home/jeremy/fully-homomorphic-encryption/demos/cc_fraud/data/test_rows.csv...
  Took 83.226µs
  Expected label (is_fraud): 0
  Feature vector size: 82
  First 5 features: [-0.31676582 0.85089076 -0.40874073 -0.1833772 -1.7155787]
Configuring Lattigo context...
  Took 2.164051998s
Encrypting input features...
  Took 19.430069ms
Running preprocessing...
  Took 573.537941ms
Running FHE evaluation (preprocessed)...
  Took 2.020821739s
Decrypting output...
  Took 488.237µs
Decrypted logits: [16.464235 -16.781752]
Predicted class: 0
SUCCESS: Predicted class matches expected label!

ここでの中心的な点は、暗号化された入力に対するモデルの評価が、シングルスレッドCPUで約2秒かかったということです。

平文入力での同じ実行と比較してください。これは単一推論のレイテンシであるため、償却の恩恵を受けません。（これには元のデータセットの取得とエンコーディングが必要ですが、これはREADMEで説明されています。ここではその部分は省略します）。

$ bazel run -c opt //demos/cc_fraud/cleartext:evaluate_cleartext
Loading model from: demos/cc_fraud/data/mlp_fraud_model_sigmoid.pt

Evaluating Credit Card Fraud Sample Index: 0
True Label:      0 (LEGITIMATE)
Predicted Label: 0 (LEGITIMATE)
Fraud Probability: 0.000000
Result:          CORRECT
Latency:         0.5233 ms

HEについて聞いたことがある人なら誰でも、それが遅いと聞いたことがあるかもしれませんが、ここで立ち止まって、この（シングルスレッドCPU、非償却！）実行時を比較したいと思います：HE推論で2秒 vs 平文で0.5ミリ秒。これは4,000倍の遅延であり、計算には2回の行列ベクトル積（行列はプライベートではない）と、2回のシグモイド関数の評価が含まれます。

このデモには注意すべき点がいくつかあります。

このモデルは小さいため、プライベート情報は単一の（CKKS）暗号文に収まります。例えば32k要素を超える入力テンソルは、複数の暗号文を必要とし、当然ながらオーバーヘッドも増えます。
このモデルは小さいため、ブートストラップ（HEの最も遅い部分）は必要ありません。
シミュレートされたネットワークオーバーヘッドや、HEを機能させるためのユーザーごとの一度限りのセットアップ（関連する鍵材料の生成とアップロード）は含んでいません。
サーバーは「Running preprocessing」ステップでかなりの（一度限りの、モデル固有の）事前計算を行っています。

リポジトリ内の他の例はより複雑であり、そのためレイテンシが長く、平文とのオーバーヘッドも悪くなります（メモリ要件は60〜90 GiB）。特に：

network_anomaly、オートエンコーダーのアンサンブル：推論に30秒。
criteo、HE用に特別に調整されたレコメンダーモデル：推論に5分。
hotword、10層の畳み込みネットワーク：推論に20分[4]。

これは悪く聞こえるかもしれませんが、シングルスレッドCPU実行であることを忘れないでください。HEIRをGPUと統合するために取り組んでいる同僚は、criteoワークロードが単一GPU（H100のようなもの）で約500ミリ秒で実行されると報告しています。これを、10ミリ秒で実行されるcriteo/cleartext:evaluate_cleartextデモと比較すると、50倍の遅延になります（ここでも、ベースラインは非償却CPU実行です）。その作業はGoogleのブログ記事には含められませんでしたが、HEIRによってコンパイルされており、いくつかの保留中のupstream PRがあります。私の言いたいのは、実行時間は改善し続けており、一部の小さな問題では、目を細めれば許容できると呼べるかもしれないということです。そしてこれは、FPGAやASICによって加速されたHEのトピックにさえ触れていません。これらはパフォーマンスの観点からはさらに有望です。

したがって、Googleの企業ブログ記事が生のパフォーマンスを示すのではなく、HEIRの表現力を示すことを目的としていました。それは多くのモデルをコンパイルでき、一部のモデルでのパフォーマンスはまともであるということです。

機能の提示という点では、リポジトリはHEIRを使用して以下を行う方法も示しています。

複数のHEバックエンドをターゲットにして比較する（リポジトリにはLattigoとOpenFHEの例があります。bazel run -c opt //demos/cc_fraud/openfhe:evaluate_fheを試してください）。
レイヤーごとのタイミングを調査する：HEIRはコンパイル済みプログラムにデバッグコールバックを挿入する機能があります。bazel run -c opt //demos/cc_fraud/lattigo:evaluate_fhe_timingを試してください。そのコマンドでは、最初の線形層が実行時間の大部分、合計2秒のうち約1.2秒を占めていることがわかります。
不正確な推論を調査する：タイミングと同様に、デバッグコールバックは暗号文を復号化し、正確性や精度損失を検査できます。bazel run -c opt //demos/cc_fraud/lattigo:evaluate_fhe_debugを試してください。推論の終わりまでに、HEの使用が平文モデルと比較して約2ビットの精度損失を引き起こしたことを示す出力が表示されます。この精度損失は、コンパイラフラグで調整でき、パフォーマンスとトレードオフになります。残念ながら、そのトレードオフをナビゲートするにはHEの専門知識が必要です。

モデルをHEIRに取り込む方法

事前コンパイルされたモデルをHEIRが処理できるものに変換するプロセスは、まだ自動化されていません。主な2つの制約は次のとおりです。

事前コンパイルされたモデルを、HEIRがプログラムを表すために使用する中間表現であるMLIRに変換できる必要があります。PyTorchやJAXなどの多くのMLフレームワークには、MLIRに変換するツールがあります。
プログラムにHEIR固有のアノテーションを手動で追加する必要があります。これは、（a）推論のどの入力が秘密であり、（b）各活性化関数の入力範囲の境界が何であるかを示します。

リポジトリのデモでは、PyTorchの場合にこれをどのように行うかを示しており、私はtorch-mlirのメンテナーと協力して、範囲を推定するために検証セットが与えられた場合にこれを自動化できる機能を追加しています。

とはいえ、コンパイラパイプラインの初期段階（活性化の認識、線形層の融合など）の多くは、torch-mlirがモデルをMLIRにエクスポートする方法に基づいています。そのため、ONNXやJAXのサポート（どちらも優れたMLIRエクスポート機能を持っています）を追加したい場合、まだそのままでは機能しないでしょう。さらに、torchオペレーターの完全なカバレッジもまだありません。線形代数オペレーターをHEでサポートする方法の多くの詳細は、非常にトリッキーであり、活発な研究トピックです（MLIR愛好家向けに、linalg.genericを完全に一般的にサポートしていません）。

コンパイラの呼び出し

これは少し脱線しますが、リポジトリの例のビルドルールを見ると、コンパイラを呼び出すマクロへの少し乱雑な呼び出しが見られます。

load("@rules_heir//heir:lattigo.bzl", "heir_lattigo_lib")

HEIR_OPT_FLAGS = [
    "--annotate-module=backend=lattigo scheme=ckks",
    "--torch-linalg-to-ckks=min-slot-count=8192 greedy-level-budget=15 greedy-modulus-switch-after-mul=true experimental-disable-loop-unroll=true first-mod-bits=30 scaling-mod-bits=24",
    "--scheme-to-lattigo",
]

heir_lattigo_lib(
    name = "fraud_model_lattigo",
    go_library_name = "fraud_model_lattigo",
    heir_opt_flags = HEIR_OPT_FLAGS,
    importpath = "fully_homomorphic_encryption/demos/cc_fraud/lattigo/fraud_model_lattigo",
    mlir_src = "//demos/cc_fraud/data:model_annotated.mlir",
    split_preprocessing = True,
)

go_binary(
    name = "evaluate_fhe",
    srcs = [
        "evaluate_fhe.go",
        "utils.go",
    ],
    data = [
        "//demos/cc_fraud/data:test_rows.csv",
    ],
    pure = "on",
    deps = [
        ":fraud_model_lattigo",
        ":fraud_model_lattigo_utils",
        "//demos/common/go/pathutils",
    ],
)

ここで何が起こっているかというと、HEIRのインターフェースはclangよりもLLVMに似ています。コンパイラパスの実行とコード生成をそれぞれ処理するheir-optとheir-translateという2つのバイナリがあり、LLVMのoptとtranslateに対応しています。これらの2つのバイナリはbazelルールにラップされ、私はそれをrules_heirとして公開しました。さらに、これらのルールをマクロでラップして、オプティマイザーとコードジェネレーターのバイナリを正しく接続し、結果を適切なバックエンドに応じてcc_library、go_library、またはrust_libraryにラップしています。

このことの1つの良い点は、rules_heirが固定されたバイナリを使用しており、ナイトリーまたはカスタムHEIRリリースを指すことができることです。それでも、これは、一貫したインターフェースと、基盤となるLLVMのシンクホールへの限定的な露出を持つclangのようなものよりも、明確なユーザーエクスペリエンスではありません。

私たちの目標は、最終的に（1つまたは複数の）clangスタイルの製品を作成することです。これらは、スコープが狭く（例えば、1つのフロントエンドのみをサポート）、概念的にシンプルなフラグ（-O2など）を持っています。JAX/PyTorchのようなフロントエンドの場合、これはおそらくPythonライブラリにラップされるでしょう。

Pythonライブラリといえば！私たちはheir_pyフロントエンドライブラリを持っています。これは現時点ではMLとは全く関係ありません。実際には、（非常に限定的な）Pythonバイトコードのサブセットを（numbaのフロントエンドを使用して）準同型暗号にコンパイルし、HEIRを実行し、OpenFHE C++コードを生成し、それをclang（最も遅い部分！）でコンパイルおよびリンクし、その後マシンコードをPythonモジュールにロードして、ユーザーが関数のように呼び出せるようにします。

明確にしておくと、Pythonフロントエンドを特に有用なものに使用したことはありません。HEIRが理解するMLIR linalgオペレーションとしてnumpyオペレーションを保持するなど、まだ多くの機能が必要です。

HEを求めるのは誰か？

ここで一歩立ち止まって、誰がHEを求めているのかについて少し考察したいと思います。HEコミュニティではこの問題について多くの議論があり、特に「HEの「キラーアプリ」は何か？」という疑問が提起されています。

ほとんどの学者は、その答えは「プライベートLLM」だと言うでしょう。そのトピックに関する私の意見はディナーパーティーのために取っておきますが、2つのことが現在真実であると言えば十分です。第一に、学術界における応用HEのほとんどすべては、現在、暗号化されたLLM推論をより速くすることに焦点を当てています。第二に、SOTA（State-of-the-Art）はまだ実用的には程遠いです。特に、レイテンシはトークンあたりの秒数の単位で測定され、私が知っているすべてのソリューションは、1回の推論の出力を復号化し、次の推論ステップの準備をするためにクライアントへのラウンドトリップを必要とします。そしてこれにはハードウェアアクセラレーション（例：8 GPU）が含まれます。私はLLMアーキテクチャの専門家でもないので、現在の障壁と、それらが追加の研究努力によって克服される可能性について強い感覚を持っていません。

Googleでの私の焦点は、代わりに手が届きやすい果実に向けられています。つまり、今日私たちが持っているHEの能力を活用できるアプリケーションは何でしょうか？その議論において、私は次のソフトヒューリスティックに落ち着きました。これは、HEを本当に実用的なものにするための残りの課題を明らかにするのに役立ちます。ここでは再びプライベート推論に限定します。

2020年のモデル

HEのレイテンシは大幅に改善されましたが、数十億パラメータを持つモデルは依然として実用的なアプリケーションには手の届かないものです。そして特に、これは有用なほど大きいトランスフォーマーをすべて除外します。

とはいえ、Googleのエンジニアや科学者と話したことがありますが、彼らの努力にもかかわらず、彼らのドメインはトランスフォーマーを適用することからまだ何の利益も得ていません。そのため、彼らのモデルアーキテクチャのコアの複雑さは、約2020年以来大きく変わっていません。

多くのドメインでは、畳み込みが依然として王様です。つまり、巨大なモデルを必要としない有用なタスクはまだ存在します。したがって、たとえ大きなモデルを使用できたとしても、プライバシーが十分に重要であれば、高速なHEを得るために小さなモデルでも許容できるかもしれません。

両当事者にとってのクリティカルなプライバシー

HEをプライバシーの必要なしに適用できる世界を夢見ていますが、まだそこには到達していません。そのため、HEが有用であるためには、両当事者のプライバシーがクリティカルでなければなりません。

「両当事者」と言う理由は次のとおりです。プライベート推論について議論する際に期待される標準的なプライバシー保護は、ユーザーの機密データです。私のメールサービスがメールの本文を見ることができない場合、データ漏洩、内部脅威、令状による検索への暴露などのリスクを回避できます。これらの状況でユーザーのプライバシーを保護する標準的な方法は、ユーザーのデバイス上でローカルにすべての作業を行うことです。2024年末、Googleマップは、少なくとも部分的に米国警察のジオフェンス令状に対応するために、位置情報履歴機能を完全にオンデバイスに変更しました。

しかし、特にプライベート推論の場合、学習済みモデルもサービスプロバイダーの機密データです。モデルをデバイスに出荷すること、たとえそれがセキュアエンクレーブを備えていたとしても、競合他社にモデルの重みが漏洩するリスクがあります。生体認証のようなユースケースでは、モデルを漏洩するとセキュリティリスクも増大します。攻撃者は、制限のない環境で本番モデルに対して攻撃を仕掛けることができます。私はハードウェアベースのセキュリティの専門家ではありませんが、私の同僚の中にはそれを破ることで生計を立てている人もおり、彼らがそのトピックについて話す方法は、セキュアエンクレーブへの信頼を刺激しません。

また、所有モデルを秘密にしておくことがユーザーのプライバシーよりも重要であると見なされるユースケースがあるとも聞かされています。これらの状況では、ユーザーデータは機密とは見なされません。これらの状況では、「ユーザープライバシー」はIP保護に加えてボーナスです。それはユーザープライバシーほどロマンチックではありませんが、HEへのさらなる投資を促進するのであれば、理想に近づくために我慢します。

同時ユーザー数が多すぎないこと

レイテンシがHEのボトルネックでなくなるにつれて、他のボトルネックが自然に現れます。私が認識している最大のものは鍵管理です。

HEを機能させる数学には、特別な「評価鍵」が必要です。これらの鍵は、文字通り、ユーザーの秘密鍵（またはユーザーの秘密鍵から派生したもの）の暗号化です。円形セキュリティに関する追加の仮定はさておき、実用的なHEシステムにとって重要なのは次のとおりです。

評価鍵は、サービスの各ユーザーに固有です。
それらはプログラムサイズに応じて（例えば、より大きな行列乗算をHEで行うには、より小さな行列乗算よりも多くの評価鍵が必要です）スケーリングします。
HEIRデモリポジトリの最大の例では、約40 GiBの評価鍵が必要です。HEにおけるSOTA LLMは、数百 GiBの鍵材料を必要とします。

したがって、40 GiB/ユーザーのユースケースを持つ100万ユーザーのサービスがあった場合、鍵材料を格納するためだけに512x20Tのハードドライブが必要になります。ドライブあたり約500ドル（Amazonで確認したばかりなので、これはコンシューマー価格です）で、追加のストレージコストとして25万ドルを要求していることになります。まともなQPS（Queries Per Second）を提供するために必要なRAMの価格はさらに悪いでしょう。

さらに、HEを加速するためにGPUを使用している場合、ユーザーがリクエストを行ったときに、この40 GiBの鍵材料をディスクからGPUに転送するという追加の問題があります。私のざっくりとした計算では、これは数百ミリ秒かかるはずです。これは、HE計算全体と同じオーダーの大きさです。そして、1人のユーザーのためにGPUのメモリを鍵で満たしている間、他のユーザーのリクエストを処理できません。

公平を期すために言うと、RAM要件のかなりの部分は、モデルに依存し、ユーザー固有ではない事前計算済みモデルの重みで構成されています。さらに、必要な鍵材料のほとんどはブートストラップをサポートするために必要なので、ブートストラップを必要としないように回避策を使用できる良いHEアプリケーション（Appleのなど）があるかもしれません。最良の場合でも、1 GiBの鍵材料しか必要ないかもしれません。したがって、強力なデータセンターGPUに50ユーザー分の鍵を収めることができるかもしれません。それでも、システム上のボトルネックが見えます。

そして、これはあまり改善していないと思います。新しいHEスキームは、より良いレイテンシを約束しますが、より大きな鍵材料を必要とします。したがって、私たち（HEコミュニティ）がHEのメモリ要件を1桁削減する方法を見つけるまで、同時ユーザー数がそれほど多くないアプリケーションのみを探します。

サーバーが出力を見る必要がないこと

準同型暗号を使用したいと考えている多くの人々は、最終的に、実際にはサーバーがユーザーの基盤となる平文に関する1ビットの情報を知りたいことに気づきます。例えば、ユーザーの生体認証情報を保存することなく指紋を認証したいとします。HEはサーバーが出力を見るのを防ぐため、それに基づいて行動できません。

これに対処するための基本的なアイデアの1つは、暗号化された認証結果をユーザーに送り返し、ユーザーにそれを復号化させ、結果をサーバーに送り返すことです。これの明らかな欠点は、クライアントが認証結果を正直に報告することを信頼できないことです！

これを機能させるには、クライアントが、提供された暗号文とユーザーの秘密鍵で復号化ルーチンを実行した結果であることを証明するゼロ知識証明を生成する必要があります。サーバーはユーザーの秘密鍵について何も学ぶことができないため、ゼロ知識でなければなりません。私はこれを自分自身で行ったことはありませんが、それが可能であり、CKKSのようなHEスキームにスケーリングする上でまだいくつかの課題があることを聞いています。そしてもちろん、これはレイテンシ予算をさらに食い尽くします。

したがって、HEの短期的なアプリケーションは、サーバーが出力結果を見ることを必要としない場合、本番環境に到達する可能性が高くなります。

では、どのようなアプリケーションがこれらの制約を満たすか？

有望に見えるアイデアをいくつか挙げます。

リモート診断。 工場を運営していて、製造業者から購入した高価な機械があるとします。製造業者に機械を診断させて、メンテナンスを推奨し、問題を特定してもらいたいが、機械の設定や、競合他社に漏洩した場合の製造量などの詳細は、ある程度機密の財務情報になります。しかし、診断レポートはバッチジョブであり、サーバーが出力を見る必要はありません。何百万もの工場があるわけではなく、診断は製造業者が料金を請求したいプレミアムサービスであり、おそらくそれほど複雑なモデルではありません。

誰かが実際にこれをHEで使用しているという噂を聞いたことがありますが、公的に検証可能な証拠はありません。私たちのネットワーク侵入検知デモも同様の性質を持っています。パケットの内容が機密データです[5]。

B2B分析： Googleのプライベートセット交差の既存のアプリケーションと同様に、ビジネス間アプリケーションは多くの条件を満たします。両方のビジネスはプライバシーニーズを持っていますが、ユーザーは2人だけなので、鍵材料は障害になりません。しかし、計算が両当事者に関連するビジネス指標のセットを生成している限り、両当事者が結果を共有するのに十分な信頼があります。そして、ビジネス分析と指標レポートは通常、レイテンシに対して寛容です。私はHEの実務家と話したことを思い出します。「クライアントが月に一度レポートを生成するだけでよいなら、HE計算に1週間かかっても誰が気にしますか？」と彼は言いました。

特殊な生体認証状況： 顔認識や指紋認識のような生体認証アプリケーションは、鍵材料の問題を除けば、現在のHE技術の能力の範囲内にあると思います。しかし、対面でのアカウント作成やアカウント回復手順（新しい従業員のオンボーディング日や、セキュリティバッジを紛失した状況を考えてみてください）のように、追加のレイテンシを許容できる特殊な状況があります。これらのイベントは、システムが大量のQPSニーズに悩まされるほど頻繁ではありません。そして、雇用主が従業員の生体認証情報のデータベースを持っていないことは一般的に良い考えだと思います。

HEIRロードマップに関する注記

HEIRの今後の方向性について、いくつか注記して締めくくります。

コンパイラ内の暗号

現在、すべてのHEIRバックエンドは外部ライブラリAPI（高レベル言語）であることをご存知かもしれません。これは主に、HEIRを開始したとき、ハードウェアアクセラレーションの作業がまだ初期段階にあったためです。さらに、アクセラレータ（およびGPUライブラリ）を構築している人々は、ベンチマーキング目的でライブラリを使用するより大きなアプリケーションを簡単に記述する必要がありました。これらは既存のライブラリAPI（OpenFHEなど）をミラーリングし、スケジューリングされたキー切り替えオペレーションをGPUに挿入するなどのレベルで独自のコードを注入することがよくありました。

そこで、HEIRはそれらの中間に位置することにしました。これらの人気のあるライブラリAPIをターゲットにし、コンパイラパイプラインのフロントエンドをうまく機能させることから始めます。同時に、MLIRによるマルチレイヤー設計により、HE暗号化をコンパイラパスとして直接実装する、真の「バックエンド」をゆっくりと構築してきました。それが整えば、プログラムをライブラリAPI（高レベルHEスキームオペレーション）にコンパイルすることも、一部のアクセラレータが開始点として使用する低レベルのモジュラー多項式算術にコンパイルすることも、一部のアクセラレータが開始点として使用するさらに低レベルのベクトル化モジュラー算術レベル（bfloat16ではなく、カスタム素数 modulo 64ビット整数演算のためのGPUまたはTPUを考えてください）にコンパイルすることも、さらにLLVMにコンパイルし、x86またはwasmなどにコンパイルすることもできます。

これは、Niobium、Cornami、Optalysysを含む複数のハードウェアパートナーにとって重要であり、これらのハードウェアのすべてをHEIRでターゲットにする予定です。このパスは着実に進歩していますが、GPU作業の多くが成熟し、私自身も今後6か月でその作業に本格的に取り組む時間があるため、勢いを増すことが期待されます。これにより、スケジューリングやカーネル融合などを含む多くの最適化の可能性が開かれます。

GPUおよびTPUサポート

HEIRへのTPUおよびGPUバックエンドの統合（現時点ではまだライブラリAPIとして）には、多くの並行した取り組みがあります。これには、CHEDDARライブラリ、BelfortのCyclops GPUライブラリ、およびCROSS/jaxiteが含まれます。また、GPUアクセラレーションに取り組んでいるさまざまな他のグループからも関心を聞いています。

私の見解では、カスタムASICがデータセンターでスケールアップされる前にHEを本番環境に投入するには、GPU/TPUが不可欠になります。

新しいスキーム

研究者は数年ごとに新しいスキームを発表しており、HEIRはそれらすべてをサポートすることを目的としています。私たちのレーダーに乗っているものには以下が含まれます。

行列乗算に最適化されており、GPU/TPUの相乗効果の可能性が高いGentry-Lee。
CKKSの基盤となる多項式演算の多くを合理化・簡素化し、スキーム間の切り替えも容易にするPoulpy。これにはすでにいくつかの進展があります。
算術演算と論理演算の両方を1つのスキームで可能にする高度なエンコーディングを使用するGao-Zheng。

ベンチマーキング

HEIRの大きなセールスポイントの1つはベンチマーキングです。特に、さまざまなハードウェアソリューション、HEスキーム、および最適化手法すべてをベンチマークできるようにしたいと考えています。これにより、Googleがデータセンターに統合すべき特別なハードウェア（時期が来たら）を決定するのに十分な情報が得られます。

その一部として、私の同僚Shruthi Gorantalaは、fhe-benchmarking.orgという形式で業界をベンチマーキングソリューションに結び付けるために熱心に取り組んでいます。

ベンチマーキングリポジトリに提出するのに適切な構造のコードを生成できるように、HEIRに機能を追加したいと考えています。これにより、HEIRに取り組んでいる人々（特に研究者）が、最適化の利点をテストし、実証することが非常に容易になります。

研究

HEIRの魅力の大きな部分は、研究者が自分の研究アイデアをHEIRに直接実装できること、または少なくともHEIRをフロントエンドとして使用できることです。そのため、私の仕事の大きな部分は、大学院生にHEIRの操作方法を教え、彼らのコードをレビューすることです。

HEIRはまだ正式な論文を発表していませんが、引用数を積み重ねており、私のカウントでは、HEIRで直接行われた研究に基づいた4つの論文が発表されています。

参加しませんか！

これに興味がある場合、またはコンパイラ/MLIRまたは暗号化の経験を積みたい場合は、HEIRは完全にオープンソースであり、毎週のオフィスアワーと、過去1か月に行われた作業をレビューし、今後の設計作業について議論する月例会議（録画あり）があります。どなたでも歓迎しますが、PRを送信する前に、これらの対面会議のいずれかに参加するか（またはメンテナーとプライベート会議をスケジュールする）ことをお願いしています。これは、AIスパムを削減するためのポリシーの一部です。

これが驚きであれば、まずこの入門記事を読むことをお勧めします。↩︎
このリポジトリは、GoogleがHEIRに資金を提供するきっかけとなった、ずさんなプロトタイプであった元の「Googleトランスパイラ」プロジェクトから再利用されました。元のトランスパイラコードは、GitHubリリースにアーカイブされています。↩︎
よく受ける質問：なぜbazelなのか？簡単な答えは、Googleはどこでもbazelを使用しているからです。より良い答えは、HEIRの主なバックエンドターゲットにはソフトウェアライブラリのソースコードが含まれており、これらはC++、Go、Rust、Pythonを含む多くの異なる言語で書かれています。私の意見では、bazelはこのようなマルチ言語プロジェクトに最適なビルドシステムです。↩︎
これには、修正方法を知っているが、ブログ記事の公開日までに完了する時間がなかったパフォーマンスの問題がいくつかあります。↩︎
とはいえ、このデモは少し奇妙です。なぜなら、異常検知モデルは参照トラフィックで学習する必要があり、その場合、モデルは顧客に公開されるからです。したがって、異常検出器をトレーニングするためにHEを使用することも検討する必要があります。↩︎