Show HN: I ran a language model on a PS2(github.com)
github.com
Show HN: I ran a language model on a PS2
https://github.com/xaskasdf/ps2-llm
15 comments
Neat! While the physicality of having the CD spin while running inference is undeniably cool, I wonder if you could run larger models at higher speeds through the PS2 HDD accessory/Memory Card Micro SD adapter/the PS2's USB port.
I doubt the VUs can help with inference given their small scratchpad sizes and instruction set though, haha.
I doubt the VUs can help with inference given their small scratchpad sizes and instruction set though, haha.
The PS2's USB port is limited to 1.1 speeds so unfortunately it's much slower than the CD interface. The phat models have an internal IDE port that is trivally converted to SATA though, and is plenty fast with an SSD!
The network port is faster than the CDVD drive or any of those accessories with the exception of the HDD. The ethernet PHY links at 100Mbit, but the processors inside the PS2 are not really capable of pushing that speed, the best I ever saw when installing games over the network with a hyper-optimized IP stack (on the IOP, IIRC) was something like 5MiB/s.
The HDD is the fastest form of I/O one can use on the PS2. It might not even need to be modified - depending on how well it's coded, it may be possible to run this software via Open PS2 Loader, which will replace CDVDMAN with a custom version that will access USB/ETH/HDD (and as mentioned in sibling comments, USB on the PS2 is version 1.1 and is much slower than even the CDVD drive).
Both network and HDD will also greatly minimize the cost of seeking the CDVD, which may be an issue depending on how the CD is laid out. CD access is up to 24x, DVD-ROM access is at 4x. DVD is thus slightly faster, and can be further increased by pushing the used data to the edge of the disc via a dummy file (traditionally, developers and game modders used Sony's own CD/DVD Generator software to determine the order of files being added to the disc, thus allowing the boot files to come first, followed by the dummy file, then any data files that need the extra speed).
The HDD is the fastest form of I/O one can use on the PS2. It might not even need to be modified - depending on how well it's coded, it may be possible to run this software via Open PS2 Loader, which will replace CDVDMAN with a custom version that will access USB/ETH/HDD (and as mentioned in sibling comments, USB on the PS2 is version 1.1 and is much slower than even the CDVD drive).
Both network and HDD will also greatly minimize the cost of seeking the CDVD, which may be an issue depending on how the CD is laid out. CD access is up to 24x, DVD-ROM access is at 4x. DVD is thus slightly faster, and can be further increased by pushing the used data to the edge of the disc via a dummy file (traditionally, developers and game modders used Sony's own CD/DVD Generator software to determine the order of files being added to the disc, thus allowing the boot files to come first, followed by the dummy file, then any data files that need the extra speed).
I'm excited for the PS2 SDK. Currently there isn't a lot in that space that won't get you sued
Some of us have it legally via PS2Linux, naturally distribution isn't allowed.
Right but that's just developing for an old version of linux running on weak hardware, you can't do any of the crazy stuff the EE is really capable of. Plus, development is still hard for newcomers. I wish RenderWare was open sourced when it died instead of bitrotting
IIRC the EE had some interesting hardware with vector units. Were these of any use/benefit here?
My goodness... Is nothing sacred anymore?
How many tok/hr?
Now you must teach it how to play Multiplayer AoE:II!
SilentEditor(1)
The CD-ROM streaming approach is the real insight here, keeping only activations and KV cache in RAM and streaming weights one matrix at a time sidesteps the 32MB constraint entirely. It's essentially the same trick modern edge inference does with flash storage, just on hardware from 2000.
Curious about the latency profile, with CD-ROM read speeds around 1.6 MB/s on PS2, the 77MB SmolLM2 model being too slow makes sense, but how does the 10MB brandon-tiny feel in practice? Are you getting tokens per minute or more like tokens per several seconds?
Also interested in the custom PSNT format decision, was the main motivation the PS2's MIPS alignment constraints, or was there something about the existing GGUF/llama.c formats that made them impractical to parse on the Emotion Engine?
Had to build a custom quantized format (PSNT), hack endianness, write a tokenizer pipeline, and most of the PS2 SDK from scratch (releasing that separately). The model itself is also custom — a 10M param Llama-style architecture I trained specifically for this.
And it works. On real hardware.