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

HEIR、準同型暗号コンパイラプロジェクトのアップデート #cryptography #ckks #homomorphic encryption #programming #mathematics 2026-09-04 2026年8月14日、Google SecurityブログにHEIR、当社の準同型暗号（HE）コンパイラのアップデートに関する記事を公開しました。この記事は、その補足記事であり、文字数や専門用語の制限がなく、率直に書くことができます。ですから、覚悟してください。 リンク先の企業ブログ記事を読まないという前提で、HEIRは入力プログラムを、暗号化されたデータ上で直接動作するプログラムに変換するコンパイラです。準同型暗号の保証は、暗号を解読していないと仮定した場合、プログラムを実行しているコンピュータは、暗号化された入力を生成するために使用された平文データに関する情報を一切取得できないということです。入力、出力、あるいは中間値に関する情報は何一つ漏れません。 ブログ記事は、HEIRが事前学習済みMLモデルをコンパイルする能力に焦点を当てており、コンパイル可能な小規模ながらも非自明なモデルの4つの例を挙げています。したがって、準同型暗号は、サービスが完全にプライベートな推論を提供することを可能にします。この記事の後半で、これがいつ、どこで役立つかについて、さらに詳しく説明したいと思います。まず、これらの例の文脈でHEIRがどのように機能するかをより具体的に示し、プロジェクトの将来のロードマップ（私の見解）を概説したいと思います。この記事を長くなりすぎるため、HEIRの内部構造については深く掘り下げません。もしそれを望むなら教えてください。しかし、heir.devには plenty of docsがあり、今年のASPLOSで私が発表した最近の（ペースの速い）講演も見ることができます。 目次: ブログ記事の背後にあるリポジトリ ブログ記事は、HEIRでコンパイルされた例のリストで終わります。これらの例は、自分でクローンして実行できるGitHubリポジトリを指しています。最大のハードルはbazelのインストールで、その後はbazelがすべてをhermeticallyに管理します。 いくつかの簡単なランタイム比較 試すのに最もシンプルで高速な例は、クレジットカード不正検知器です。これは、シグモイド活性化関数を持つ3層のフィードフォワードネットワークで、Kaggleデータセットで学習されています。線形層の次元は128、64、そして2（最後は2クラス、不正と非不正のロジット）です。 以下のコマンドで基本的な例を実行できます。 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秒かかったということです。 平文入力での同じ実行と比較してください。これは単一推論のレイテンシであり、償却の恩恵を受けないことに注意してください。（これには元のデータセットを取得してエンコードする必要がありますが、ここではその部分は省略します）。 $ 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分。 これは悪く聞こえるかもしれませんが、シングルスレッドCPU実行であることを忘れないでください。HEIRをGPUと統合するために取り組んでいる同僚は、criteoワークロードが単一GPU（H100のようなもの）で約500ミリ秒で実行されると報告しています。これをcriteo/cleartext:evaluate_cleartextデモ（10ミリ秒で実行される）と比較すると、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のメンテナーと協力して、私がそれを自動化できるようにする機能を追加しています（範囲を推定するために使用する検証セットが与えられれば）。 とはいえ、コンパイラパイプラインの初期段階の多くは、