Friday 1 November 2024
Overview of Content Published in October
Tuesday 8 October 2024
Quickpost: The Electric Energy Consumption Of LLMs – No GPU
A friend asked me if I had used a GPU for my tests described in blog post “Quickpost: The Electric Energy Consumption Of LLMs”. Because he had tried running an LLM on a machine without GPU, and it was too slow.
I did a quick test, just redoing previous test but without GPU (by setting environment variable CUDA_VISIBLE_DEVICES=-1).
Answering my query took 17 seconds, and required 1.13 Wh (again, for the whole PC).


Quickpost info
Sunday 6 October 2024
Quickpost: The Electric Energy Consumption Of LLMs
I’ve read claims that AI queries require a lot of energy. Today I heard another claim on the Nerdland Podcast (a popular science podcast here in Belgium): “letting ChatGPT write an email of 100 words requires 70 Wh” (if you’re interested, that’s said at 00:28:05 in this episode).
I though to myself: that’s a lot of energy. 70 Wh is 252,000 Ws (70 W * 3600 s). Assume that it takes 10 seconds to write that email, then it requires 25,200 W of power, or 25 kW. That’s way more than the theoretical maximum I can get here at home from the power grid (9 kW).
So I decided to do some quick & dirty tests with my desktop computer and my powermeter.
First test: measure everything.
Step 1: starting up my desktop computer (connected to my powermeter) and waiting for the different services to startup, required 2.67 Wh of electrical energy:

Step 2: I opened a command prompt, started Ollama, typed a query to generate an email, and waited for the result. By then, the required electrical energy op my desktop computer (since starting up) was 3.84 Wh:

So step 2 took 57 seconds (00:02:36 minus 00:01:39) and required 1.17 Wh (3.84 – 2.67). That’s way less than 70 Wh.

Second test: just measure the query.
I restarted my computer and started Ollama. Then I started my powermeter and pasted my query and waited for the answer:

That took 3 seconds and required 0.236 Wh:

Notice that I have not just measured the electrical energy consumption of Ollama processing my query, but I measured the total electrical energy consumption of my desktop computer while Ollama was processing my query.
0.236 Wh for a computer running Ollama and processing a query is very different than 70 Wh for ChatGPT processing a query. That’s almost 300 times more, so even though my test here is just anecdotal and I’m using another LLM than ChatGPT, I will assume that 70 Wh is a gross overestimation.
FYI: asking Google “what is the electrical energy consumption of chatgpt processing a query”, I find results mentioning between 1 and 10 Wh. That’s closer to my tests than the 70 Wh claim.
Quickpost info
Wednesday 2 October 2024
Overview of Content Published in September
Sunday 1 September 2024
Overview of Content Published in August
Thursday 29 August 2024
Overview of Content Published in July
Saturday 13 July 2024
Update: cut-bytes.py Version 0.0.17
–prefix and –suffix can now also be filenames.
cut-bytes_V0_0_17.zip (http)
MD5: 86D0692C6303248639A740E7A2AC4525
SHA256: D4FCFBD2305D7E5E97AB993741DF95B4565A882B0CD7DBA061D09578A1DDADA7
Thursday 11 July 2024
Update: oledump.py Version 0.0.77
This is an update for plugin plugin_biff.py.
Protected xls files (workbook protection, sheet protection) are protected with a password, but are not encrypted.
The password is hashed to a 16-bit hash called verifier, such a short hash gives ample opportunity for hash collisions.
I calculated passwords for all possible hash values (32768, or 0x8000) mostly with letters and digits, some with special characters (verifier table). This verifier table is not a rainbow table, because the table contains all possible hash values and a corresponding password.
If a verifier can not be cracked with a provided password list, the password will be taken from the verifier list.
Example: this spreadsheet has a sheet protected with password azeqsdwxc, which is not in the embedded password list (obtained from John The Ripper); thus the password from the verifier table is taken (bbbbhz):


Passwords azeqsdwxc and bbbbhz both hash to the same verifier value (0xd9b1), thus there is a hash collision, and both passwords can be used to unprotect the sheet.
oledump_V0_0_77.zip (http)MD5: CC8E3BB7BFA8D6312F8371DADE414EE4
SHA256: 08A097FB2491072043BFD4032BEBC4B2994AEF94B99F3C68EFAEB56004AE7ECE
Sunday 7 July 2024
Update: hash.py Version 0.0.13
This is a bugfix release for @files.
hash_V0_0_13.zip (http)MD5: 43419BBB95FC1321EC6098AE369DEC26
SHA256: 88BD3A7B71BB2C8579F49E76E8069E7A5A4B23DCF1DB1716E5E2C9F78BFF6D5B
Saturday 6 July 2024
Overview of Content Published in June
- Update: file-magic.py Version 0.0.8
- Update: hash.py Version 0.0.12
- Update: myjson-filter.py version 0.0.6
- Update: strings.py Version 0.0.9
- Update: zipdump.py Version 0.0.30
- Update: count.py Version 0.3.2
- Update: simple_listener.py Version 0.1.5
- Update: what-is-new.py Version 0.0.4
- Update: FileScanner Version 0.0.0.9
- Update: pdf-parser.py Version 0.7.9
- Update: base64dump.py version 0.0.25
- Update: InteractiveSieve Version 0.9.3.0
- MyJSON Tools
- Update: python-per-line.py Version 0.0.12
- Update: emldump.py Version 0.0.14