zeekay
e037e8f7ea
The distribution called itself torus-ml while shipping a package directory named concrete, so the name a user installs and the name they import disagreed — and most of the tree already said torus.ml, which could not resolve against src/concrete. Moved src/concrete to src/torus and pointed the include at it. The dependency was Zama's concrete-python from their index. It is torus-fhe from ours, which is what luxfhe/torus already ships: that frontend declares torus-fhe and ships a torus/fhe module, so every 'from torus.fhe' in this tree was already naming our compiler and only the dependency lagged. Two distributions share one namespace, which is the shape the upstream this forked from used and the reason the split works: torus-fhe gives torus.fhe, torus-ml gives torus.ml. Swept every other spelling — identifiers, enum members, workflow variables, filenames, notebooks. LICENSE and NOTICE keep the upstream attribution a fork owes; the figures carry the old name in JPEG metadata a text sweep cannot reach.
2.4 KiB
Description
In this directory we show how to solve a classification task on CIFAR-10 and CIFAR-100, by converting a pre-trained CNN to its fully homomorphic encryption (FHE) equivalent using Quantization Aware Training (QAT) and Torus ML. We evaluate it using the FHE simulation mode provided by the Torus stack.
To do so, we divided this use case in 4 notebooks :
-
FromImageNetToCifar.ipynb : in this notebook, we used a VGG11 network from torch.hub, on which we applied some changes on the original architecture in order to speed up the FHE execution and therefore make it more user-friendly :
- replacing the
MaxPool2dby theAvgPool2d, because in the current version of Torus MLMaxPool2disn't available yet - changing the kernel and stride size in some pooling layers, because we have chosen to keep the initial input size of
3*32*32instead of the recommended input size of3*224*224 - changing the kernel size from
7to1in theAdaptiveAvgPool2dto further reduce the image's size - removing the classification part of the original VGG11 architecture to speed up computation
This notebook may be skipped if the user already has a pre-trained floating point CIFAR-10 / CIFAR-100 model.
- replacing the
-
CifarQuantizationAwareTraining.ipynb: explains the (FHE) constraints and how to quantize the pre-trained neural network to make it work in FHE.
-
CifarInFhe.ipynb: computes the accuracy of the quantized models using FHE simulation
-
CifarInFheWithSmallerAccumulators.ipynb: shows how to use the rounded PBS operation to lower the accumulator size, thus decreasing the inference time in FHE
Installation
To use this code, you need to have Python 3.8 and install the following dependencies:
pip install -r requirements.txt
Results
CIFAR-100:
| Runtime | Top1 Accuracy |
|---|---|
| VGG PyTorch | 70.04% |
| VGG Brevitas | 68.40% |
| VGG FHE simulation | 68.28% |
CIFAR-10:
| Runtime | Top1 Accuracy |
|---|---|
| VGG PyTorch | 90.11% |
| VGG Brevitas | 90.40% |
| VGG FHE simulation | 90.28% |