zeekay
531fc57003
Brand-only sweep. Touches READMEs, docs, package metadata, comments,
notebook markdown, requirements.txt files; does NOT yet touch Python
`concrete.*` imports (those are module-level dependencies requiring the
phase-2 Python module port from `concrete` → `torus`).
Substitutions applied:
Concrete ML → TorusML
concrete-ml → torus-ml
Concrete-ML → Torus-ML
concrete_ml → torus_ml
zama-ai/concrete-ml → luxfhe/ml-sdk
zama-ai/concrete → luxfhe/torus
github.com/zama-ai → github.com/luxfhe
docs.zama.ai/concrete-ml → docs.luxfhe.com/ml-sdk
docs.zama.ai/concrete → docs.luxfhe.com/torus
Zama Concrete ML → Lux TorusML
Zama Concrete → Lux Torus
Zama tfhe-rs / Zama TFHE-rs → Lux-FHE
tfhe-rs / TFHE-rs → Lux-FHE
Zama fhEVM / fhEVM → TorusEVM
Concrete framework → Torus framework
Concrete compiler → Torus compiler
Concrete by Zama → Torus by Lux
the Zama team → the Lux Industries team
Zama's → Lux Industries'
(Zama) → (Lux)
CoFHE / Fhenix → (removed)
LICENSE: original Zama copyright RETAINED per BSD-3-Clause-Clear §1-§2
requirements; Lux Industries modifications copyright added. Per §3 no
name of ZAMA used to endorse the derived work — product marketed
exclusively as TorusML.
README image URLs migrated to github.com/luxfhe/ml-sdk/assets to break
the dependency on Zama's CDN.
Hit count: 350 → 295. Residual hits are Python `from concrete.fhe import`
imports referencing the upstream Zama `concrete` PyPI package; these
require module-level port (phase 2):
Phase 2 plan:
1. Fork zama-ai/concrete (the Python compiler) to luxfhe/torus
2. Rename Python module `concrete` → `torus`; PyPI publish as `torus-fhe`
3. Update ml-sdk imports from `concrete.fhe` → `torus.fhe`, etc.
4. Wire `torus.compiler` GPU dispatch through `luxcpp/gpu` vtbl
(lux-private/gpu-kernels for CUDA/Metal/WebGPU/FPGA targets)
5. Port concrete-cuda + concrete-mlir kernels to
lux-private/gpu-kernels/{cuda,metal,wgsl}/ckks/ (matrix-vector
mul, rescale, rotate, bootstrap for TorusML inference)
Phase 3 plan (kernels):
- CKKS/BGV/BFV GPU kernels in lux-private/gpu-kernels/
(currently only TFHE PBS / keyswitch / blind-rotate exist)
- FPGA bitstreams in lux-private/fpga/ (currently scaffold only)
Phase 1 = docs/branding sweep. PR not opened; user reviews and merges.
4.7 KiB
Ternary VGG on CIFAR10 with Fully Homomorphic encryption
Description
In this directory we provide Python code for training, from scratch, a VGG-like neural network using Brevitas on CIFAR-10. We also give a script to run the neural network in the Fully Homomorphic Encryption (FHE) settings.
Original files can be found in the Brevitas repository. The model in the models/ folder has a few modifications from the original to make it compatible with TorusML:
MaxPoollayers have been replaced byAvgPoollayers. This is mainly because max pooling is a costly operation in FHE which we want to avoid for less FHE costly operations such as average pooling.- Quantization is applied after each AvgPool as this is needed for TorusML to capture the quantization parameter. A QuantIdentity Brevitas layer achieves this.
Installation
To use this code, you need to have Python 3.8 and install the following dependencies:
pip install -r requirements.txt
Training and inference
The files in this section are almost as identical to the original. Here we train a VGG-like neural network using an example available on Brevitas Github repository.
To train the neural network:
python3 bnn_pynq_train.py --data ./data --experiments ./experiments
To evaluate the trained model:
python3 bnn_pynq_train.py --evaluate --resume ./experiments/CNV_2W2A_2W2A_20221114_131345/checkpoints/best.tar
Simulation in TorusML
In TorusML, you can test your model before running it in FHE such that you don't have to pay the cost of FHE runtime during development.
You can launch this evaluation as follows:
python3 evaluate_torch_cml.py
Rounding for Improved Performance
In Concrete, a rounding operator is available which removes a specific number of least significant bits to reach a lower desired bit-width. This results in significant performance improvement. The default rounding threshold is set at 6 bits but can be changed to suit your needs.
python3 evaluate_torch_cml.py --rounding_threshold_bits 8
Testing with different rounding_threshold_bits values can help you understand the impact on the final accuracy:
python3 evaluate_torch_cml.py --rounding_threshold_bits 1 2 3 4 5 6 7 8
Using rounding with 6 bits for all accumulators provides a significant speedup for FHE, with only a 2.7% loss in accuracy compared to the original model. More details can be found in the Accuracy and Performance section below.
Fully Homomorphic Encryption (FHE)
Once you're satisfied with the model's performance, you can compile it to the FHE settings.
python3 evaluate_one_example_fhe.py
Here, an image from the CIFAR10 data-set is randomly chosen and preprocessed. The data is then quantized, encrypted and then given to the FHE circuit that evaluates the encrypted image. The result, encrypted as well, is then decrypted and compared vs. the expected output coming from the clear inference.
Hardware Used for the Experiment
Experiments were conducted on an m6i.metal machine offering 128 CPU cores and 512GB of memory. The choice of hardware can significantly influence the execution time of the model.
Accuracy and performance
| Runtime | Rounding | Accuracy |
|---|---|---|
| VGG Torch | None | 88.7 |
| VGG FHE (simulation*) | None | 88.7 |
| VGG FHE (simulation*) | 8 bits | 88.0 |
| VGG FHE (simulation*) | 7 bits | 87.2 |
| VGG FHE (simulation*) | 6 bits | 86.0 |
| VGG FHE | 6 bits | 86.0** |
We ran the FHE inference over 10 examples and achieved 100% similar predictions between the simulation and FHE. The overall accuracy for the entire data-set is expected to match the simulation. The original model (no rounding) with a maximum of 13 bits of precision runs in around 9 hours on the specified hardware. Using the rounding approach, the final model ran in 40 seconds. This significant performance improvement demonstrates the benefits of the rounding operator in the FHE setting.
* Simulation is used to evaluate the accuracy in the clear for faster debugging. ** We ran the FHE inference over 10 examples and got 100% similar predictions between the simulation and FHE. The overall accuracy for the entire data-set is expected to match the simulation.