Fixing TFHE Parameters in Concrete's `parameter_selection_strategy`

Zama Concrete
1

I am working with the Concrete library, and I want to fix the TFHE parameters in an application, similar to how it is done in a the benchmark application NN-20/NN-50/NN-100 in Reference [1]. The TFHE parameters reported in Reference [1:1] (128 bits) are:
GLWE: k=1, N=4096, \sigma=2^{-62}.
LWE: n=938, \sigma=2^{-23}.

The default value for the Concrete Configuration parameter_selection_strategy is “MULTI,” which uses multiple parameter sets within the same application, and the parameters are automatically searched by the Concrete optimizer, cannot be set manually.

My target

I try to set the parameters manually, same as the reported values in References [1:2], [2]. If that’s not possible, I would like to use a single set of parameters instead of multiple sets.

Here are my two attempts.

Attempt 1: parameter_selection_strategy="V0"

I added the following code in frontends/concrete/fhe/compilation/server.py under Concrete’:

options.set_v0_parameter(glwe_dim=1, log_poly_size=12, n_small=938, br_level=2, br_log_base=10, ks_level=9, ks_log_base=2)

It seems set_v0_parameter does not allow setting \sigma, and since Reference [1:3] did not report br_level, br_log_base, ks_level, ks_log_base, I set them arbitrarily.

I changed the parameter_selection_strategy to "V0".

Result: Concrete runs without errors, but the inference results are completely incorrect.

Attempt 2: parameter_selection_strategy="MONO"

I switched the parameter_selection_strategy to "MONO". It finds parameters for NN-20, NN-50, NN-100, but not for some networks like DeepCNN-X mentioned in Reference [2:1]. For instance, while it finds parameters for DeepCNN-20 under "MONO", it fails for DeepCNN-50 and DeepCNN-100 with a RuntimeError: NoParametersFound. Moreover, even though the results are correct for DeepCNN-20 using "MONO", it is significantly slower than when using "MULTI".

Summary

  1. Is it true that using parameter_selection_strategy="V0" with parameters reported in some papers leads to incorrect results?
  2. Does using parameter_selection_strategy="MONO" fail to find parameters for more complex models?
  3. With "MULTI", I noticed that even for the same neural network model, different inputs (i.e., different torch_inputset parameters in compile_torch_model) lead to different selected parameters. Is there a way to ensure the same set of parameters is reused for the same model, regardless of the input?

  1. I. Chillotti, M. Joye, and P. Paillier, “Programmable Bootstrapping Enables Efficient Homomorphic Inference of Deep Neural Networks,” in Cyber Security Cryptography and Machine Learning, S. Dolev, O. Margalit, B. Pinkas, and A. Schwarzmann, Eds., Cham: Springer International Publishing, 2021, pp. 1–19. doi: 10.1007/978-3-030-78086-9_1. ↩︎ ↩︎ ↩︎ ↩︎

  2. Prasetiyo, A. Putra, and J.-Y. Kim, “Morphling: A Throughput-Maximized TFHE-based Accelerator using Transform-domain Reuse,” in 2024 IEEE International Symposium on High-Performance Computer Architecture (HPCA), Mar. 2024, pp. 249–262. doi: 10.1109/HPCA57654.2024.00028. ↩︎ ↩︎

2

Hello. Great to see that you’re trying to reproduce our 2021 results! And, it’s a great coincidence that our ML team has worked on this white paper, and has been able to reproduce the results … and go much further, with 2024 stack: Concrete and Concrete ML :slight_smile:

You can find their experiment in concrete-ml/use_case_examples/white_paper_experiment at main · zama-ai/concrete-ml · GitHub : they go up to 20x time faster than what we had in 2021. We’re going to blog soon on this, to explain a bit how our stack has changed and how it’s feasible we are so faster now. Stay tuned.

For your question, the best person we have to answer you is off for a moment: when he is back, he’ll guide you more than I can.

1 Like
3

The blog post is available @IsaacQuebec : https://www.zama.ai/post/making-fhe-faster-for-ml-beating-our-previous-paper-benchmarks-with-concrete-ml

Happy reading

1 Like
4

Hi,

  1. You cannot choose br_level, br_log_base, ks_level, ks_log_base arbitrarily, most of the time you’ll get incorrect values.
    But you can get correct values for theses parameters using strategy MONO for instance.Parameters can be visualized with show_optimizer option (or using the statistics of the circuit).
    MONO and V0 have compatible parameters domain. So you can generate parameters with MONO and use them all with set_v0_parameters if you want.

  2. MONO strategy use the same parameters everywhere. Some circuit can be infeasible with MONO (no parameters) because some different parts of the circuit have incompatible needs in term of parameters.
    MULTI strategy solves that issue by picking different parameters for different circuit parts.
    That’s also why MULTI can be a lot faster than MONO.

  3. If the parameters have big differences, it means the generated FHE circuit have big differences. So you should increase your inpuset until it converges to similar parameters each time. It’s kind of similar to machine learning parameters, if training set is too small you get a very different trained model each time.