Typically you need about 1GB graphics RAM for each billion parameters (i.e. one byte per parameter). This is a 405B parameter model. Ouch.

Edit: you can try quantizing it. This reduces the amount of memory required per parameter to 4 bits, 2 bits or even 1 bit. As you reduce the size, the performance of the model can suffer. So in the extreme case you might be able to run this in under 64GB of graphics RAM.

I think that’s a better plan than physically printing keys. I’d also want to save the keys in another format somewhere - perhaps using a small script to export them into a safe store in the cloud or a box I control somewhere

You need at least two copies in two different places - places that will not burn down/explode/flood/collapse/be locked down by the police at the same time.

An enterprise is going to be commissioning new computers or reformatting existing ones at least once per day. This means the bitlocker key list would need printouts at least every day in two places.

Given the above, it’s easy to see that this process will fail from time to time, in ways like accicentally leaking a document with all these keys.

I agree, so much legislation is broken, the legislators aren’t doing shit, so we citizens need to fix it!

But we could start with the right to repair.

If you’re pushing everyone’s buttons it’ll end badly.

There is non-zero risk in every surgery, and this is a major surgery. There is non-zero risk of very very severe consequences: brain infection, stroke being just some. While these risks are low, they are non-zero. The volunteers have the possibility of losing everything.

Java programmers are also functionally illiterate

Exactly. And all the core internet encryption and signing algorithms are fully open source. Eg RSA, AES, DIffie Helman. And these are the algorithms the US (and most other western) governments require when sending data to or from or within there servers.