Would probably be better to demonstrate by exsmple how this approach is used to train on sensor data and then use it (as is hinted by the author) instead of acknowledging that the klingon poc is useless.
I love the cool tech demo! I also would have loved to see a offline sensor calibration package - or whatnot - and analysis of model precision instead of Klingon. Just trying to think up of an actual use case where you would actually truly need an LLM instead of one of the other well known data analytics methods.
Very cool project! Sounds like it was a fun challenge :)
I wonder when we'll start seeing clusters of ESP32-S3s... not sure how interconnects would go though, but I guess the interconnect wouldn't be the bottleneck anyway.
Correct. No autograd: the expressions for the gradients are written out explicitly in C. There's a gradient check in tests/ that verifies them against centred finite differences on the published header, worst relative error 1.07e-08.
Author here. Fair question, and the answer is in the first line of the README: I wrote it, with AI help.
Specifically: I wrote it in Spanish first, which is my language, and then translated and condensed it into English with Claude. That's probably the blend you're picking up. The jokes, the structure and the decisions are mine; the English phrasing has fingerprints that aren't.
The code is more clear cut and it says so in the header: generated by AI under my direction. I wrote the architecture, the decisions and the validation, not most of the C.
I'd rather say that upfront than have someone find it later.
I understand that you are alluring that maximum training-state memory, not parameter count, is the key variable here. So you better start with the smallest model, and go to for highest training data quality, with the outlook of coupling systems together?
This small Klingon speaking language model was trained completely on ESP32. The training took 2 days
Number of parameters: 319K
(Disclaimer) The models is tiny and is not a pocket chatbot. It mistakes and is not capable to support conversation, but that's not the goal of the project
The goals of the project is to bring training to edge devices and it worked out
How can one use it? By using solar panels such device could be turned into autonomous meteorological station
Would probably be better to demonstrate by exsmple how this approach is used to train on sensor data and then use it (as is hinted by the author) instead of acknowledging that the klingon poc is useless.
I love the cool tech demo! I also would have loved to see a offline sensor calibration package - or whatnot - and analysis of model precision instead of Klingon. Just trying to think up of an actual use case where you would actually truly need an LLM instead of one of the other well known data analytics methods.
But would it be as cool as a microcontroller that spits out Klingon?
Very cool project! Sounds like it was a fun challenge :)
I wonder when we'll start seeing clusters of ESP32-S3s... not sure how interconnects would go though, but I guess the interconnect wouldn't be the bottleneck anyway.
Imagine a Beowulf cluster of those
Afaik there are already a few videos on YouTube.
hIngan motlh puS ruq tuq DujDaq SISwI' nge'vI' vIn SuvwI' yIvwI' qarghtaHvIS SIchoH
vIparHa'bej.
Very cool project.
> Backpropagation (gradients derived by hand)
What does by hand mean in this context?
Also how did you write the readme? It's a curious blend of human and AI writing.
The fact that by hand is emphasized so often and so often (see src/handgpt.h comments as well above backward()) makes me think it's AI.
Anyways, it looks like gradients derived by hand means they didn't use autograd. They have written out the expression for dL/dW themselves.
Correct. No autograd: the expressions for the gradients are written out explicitly in C. There's a gradient check in tests/ that verifies them against centred finite differences on the published header, worst relative error 1.07e-08.
I think the readme is clearly LLM generated. The tone, the short sentences, the em dashes, lists, sections.. It all feels like LLM.
The author is also replying with an LLM on HN: https://news.ycombinator.com/item?id=49180716
Author here. Fair question, and the answer is in the first line of the README: I wrote it, with AI help.
Specifically: I wrote it in Spanish first, which is my language, and then translated and condensed it into English with Claude. That's probably the blend you're picking up. The jokes, the structure and the decisions are mine; the English phrasing has fingerprints that aren't.
The code is more clear cut and it says so in the header: generated by AI under my direction. I wrote the architecture, the decisions and the validation, not most of the C.
I'd rather say that upfront than have someone find it later.
> Which is no small thing.
I think it is a small thing.
Awesome.
[flagged]
I understand that you are alluring that maximum training-state memory, not parameter count, is the key variable here. So you better start with the smallest model, and go to for highest training data quality, with the outlook of coupling systems together?
You're talking to an LLM, unfortunately
https://news.ycombinator.com/threads?id=runtime_lens
(enable showdead in your HN settings)
Aw, that is truly annoying...
Thanks for pointing it out!
Until now I never experienced something like this.
This small Klingon speaking language model was trained completely on ESP32. The training took 2 days
Number of parameters: 319K
(Disclaimer) The models is tiny and is not a pocket chatbot. It mistakes and is not capable to support conversation, but that's not the goal of the project
The goals of the project is to bring training to edge devices and it worked out
How can one use it? By using solar panels such device could be turned into autonomous meteorological station