Hacker Newsnew | past | comments | ask | show | jobs | submit | trekhleb's commentslogin

Thank you.

The comparison and the reference to the karpathy/llm-council is available on GitHub https://github.com/trekhleb/yesbrainer

In short, Karpathy's llm-council is one fixed answer→rank→synthesize pass behind a local server you have to run, while Yes-Brainer is a zero-setup browser app with three deliberation structures — including a real multi-round debate (consensus mode)


The app is open-sourced here https://github.com/trekhleb/yesbrainer - feel free to check the sources


This article gave me another nudge towards running Claude in a Docker container.

I made a thin Docker container wrapper "claude-pod" recently for my personal usage here: https://github.com/trekhleb/claude-pod

However, I wasn't using it that often, just because of that additional friction of running Claude via `PORTS="3000 5173" claude-pod` instead of just `claude`, etc.

But now I have more motivation for the containerisation :D. Not a 100% defence from the potential glitches, though, but still something...


Nice and minimalistic

I played with similar approach in JavaScript and built a NanoNeuron https://github.com/trekhleb/nano-neuron (it is more verbose than Python though)


What I mean is training something like GPT-3 in a distributed manner using a large number of regular browsers or laptops with average WebGPU support/power and WebRTC for communication.

Does it even make sense to ask this? Is it reasonable or feasible?

I understand there are many nuances, such as the size and source of the training data, the size of the model (which would be too large for any browser to handle), network overhead, and the challenge of merging all the pieces together, among others. However, speculative calculations suggest that GPT-3 required around 3x10^22 FLOPs, which might (very speculatively) be equivalent to about 3,000 regular GPUs, each with an average performance of 6 TFLOPs, training it for ~30 days (which also sounds silly, I understand).

Of course, these are naive and highly speculative calculations that don’t account for whether it’s even possible to split the dataset, model, and training process into manageable pieces across such a setup.

But if this direction is not totally nonsensical, does it mean that even with a tremendous network overhead there is a huge potential for scaling (there are potentially a lot of laptops connected to the internet that potentially and voluntary could be used for training)?


Thanks for the feedback! WebGPT is good. Looks like it is a vanilla JS? I used TensorFlow.js to offload all the troubles of working with tensors, gradients, and WebGPU integration to it. Along with a possibility to train the model in the browser it also helped to keep the actual GPT code pretty concise (<300 lines). Hopefully it will make easier to learn the model architecture itself for those who’re interested.


It is a very visual and entertaining visualization, I love it.

It inspired me to experiment with a genetic algorithm in "Self-parking car evolution":

https://trekhleb.dev/self-parking-car-evolution/


Thanks for the feedback! It is already in the roadmap here https://feedback.okso.app/feedback/p/love-it-is-in-desperate...


yup that was me :-)

cant wait! OS wide dark theme makes encountering a big white screen very painful...


No it is not open source for now


Person “R” breaks into the person’s “U” private property and kills part of the person’s “U” family. Could you give me an example of the properly worded “why” part that could justify person “R”?


That is the "what" happened, it does not give me any meaningful insight as to "why" it happened.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: