PS5 local AI is a real measured result and a poor purchase argument at the same time. A hacked console ran a 27-billion-parameter Qwen model on its GPU at about 20 tokens a second in October 2026, according to the developer's own table, while the standard retail machine cannot run it at all.
Why is PS5 local AI fast?
PS5 local AI is fast because the console shares one pool of GDDR6 memory between its CPU and GPU, and text generation is limited by how fast weights move, not by arithmetic. Sony rates that memory at up to 448 GB/s in its PS5 specification. Every token of output reads the model's weights, so bandwidth sets the ceiling.
That design predates any language model plan. Sony built the console for games, and the shared memory pool keeps GPU work close to data it did not have to copy. A dense model such as Qwen, which activates all of its weights on every token, reads its whole file for each token it writes. The compute is cheap; the transfer is the bill.
The arithmetic follows from that. Divide the memory bandwidth by the size of the model file and you get the most tokens per second the machine can write before code, driver overhead or anything else slows it down. The same sum applies to a laptop, a server or a console.
For context, the memory figure comes from a product page, not a benchmark. Sony's 448 GB/s is a rating for the whole pool, and the console's CPU and GPU compete for it. Bandwidth on paper is the ceiling, and real throughput lands under it.
How did the two PS5 homebrew projects get there?
Two developers moved the result from a demo to a usable server. A first project ported llama.cpp, the C++ engine for running language models, to run as a payload on the console's CPU; a second project forked that work, moved execution to the GPU, and merged the changes back.
The payload stage
The first project, PS5LM, arrived as a payload: a homebrew program loaded while Sony's own system keeps running. The llama.cpp repository gave the author an engine that already supported many model formats, so porting it was less work than writing GPU code for one model. The console gave that payload about 1.6 GB of model memory, which fits only small Qwen 3.5 models.
The title stage
The fork's documentation draws the boundary plainly. A payload maps roughly six gigabytes at the absolute limit but keeps only the smaller safe slice locked, and it never reaches the GPU. A native title gets 12 GB of the console's direct memory plus GPU access. A model is one enormous allocation, so the program type decides whether the large model loads at all.
The GPU path runs through Vulkan, the cross-platform graphics API, using a community RADV driver build. The fork reserves a single block of a little over 11 GB for a heavily compressed Qwen model at about 2 bits per weight. None of the project documentation explains why Sony drew the memory lines where it did.
The merge
By mid-October 2026 the fork had been offered back to the original project and merged, according to the fork author's pull request description. If you already run llama.cpp on a PC, the engine and the model files are familiar; only the plumbing underneath changed. The PS5LM project is the place to follow the combined codebase.
How fast is PS5 local AI in practice?
Measured speed is about 20 tokens a second for the 27-billion-parameter Qwen model on the GPU, against roughly one token a minute for the same model streamed from disk on the CPU. The gap is more than a thousandfold, and it mixes two changes: GPU execution and holding the whole model in memory.
A ceiling calculation puts the theoretical maximum near 45 tokens a second for that file size at 448 GB/s. The measured figure is less than half of it. Where the remainder goes, whether driver overhead or kernel code, is not established by any published measurement.
Smaller models in the same table move faster. Llama 3.2, a model several times smaller, tops the table at more than 100 tokens a second. Less data to read per token means more tokens out, which is the same bandwidth rule applied to a smaller file.
The fork draws a live dashboard on the TV showing tokens per second over time, per-unit load, and power and memory use. For a homebrew project that dashboard is useful evidence that the work is actually landing on the GPU, though it is not an independent benchmark.
| Configuration | Model | Reported speed |
|---|---|---|
| CPU payload, streamed from disk | Qwen 27B | about 1 token/min |
| GPU, title, ~2-bit weights | Qwen 27B | about 20 tokens/s |
| GPU, title | Llama 3.2 | over 100 tokens/s |
| Theoretical ceiling at 448 GB/s | Qwen 27B file | about 45 tokens/s |
All of these numbers come from the developer's own table or from the transcript's arithmetic on Sony's bandwidth rating. No independent lab has reproduced them, so treat them as vendor-side claims from a hobbyist, not as a console benchmark.
What does 2-bit compression cost you in answer quality?
Squeezing a 27-billion-parameter model to about 2 bits per weight is what makes it fit an 11 GB block, and no published test establishes that the compressed model stays useful. Even the developer's larger build comes to roughly 9 GB, which leaves room in the block, but quality at this compression is unmeasured.
Model weight compression works by storing each learned number in fewer bits. At 2 bits per weight, a model that would otherwise occupy tens of gigabytes fits inside console memory. The trade is precision, and precision losses show up differently across tasks and languages.
Community members quoted in secondary coverage doubt a model squeezed that hard remains useful, and the transcript relays that doubt without an independent quality test behind it. "It runs" and "the answers are good" are separate claims, and only the first one has evidence. If you need a defensible comparison, run a model at several compression levels on your own evaluation set rather than reading a token-per-second table.
There is also an accuracy problem in the sourcing itself. The speed table, the memory figures and the merge date all originate with one developer. Reporting that repeats those figures is not corroboration.
Why is prompt reading the hidden bottleneck?
Prompt processing runs at roughly 35 to 50 tokens a second on the console, so a pasted document of a few thousand tokens can delay the first output token by several minutes. Generation speed gets the attention; reading the input is where the waiting actually happens.
The developer attributes the slow prefill to RADV driver limits and per-batch GPU timeouts. That diagnosis is his own, and no second source backs it in the material reviewed for this article. Prefill is usually faster than generation on mature hardware because the work parallelizes across the prompt; here it is not.
For a short question the delay is invisible. For a tool that sends long inputs, it dominates. The transcript cites a write-up in which a single code-editing job took about 10 minutes, mostly spent reading the input, and a long report could need seven to nine and a half minutes before the first word appears.
That matters because the app can serve other devices. It speaks the same request formats as OpenAI and Anthropic a laptop on the home network can point a code editor at the console. The OpenAI API reference and the Anthropic documentation describe the request shapes the server imitates. It behaves like a model server in protocol, not in latency.
Power matters for a machine kept on all day. The transcript reports an idle draw of 22 watts from the changelog and a much higher draw while the large model writes.
Why did the Air Force's PlayStation cluster fail?
The Air Force Research Laboratory in Rome, New York, opened a 1,760-console PS3 cluster called Condor in December 2010, and a firmware update months earlier had already removed the Linux feature it depended on. The cluster could keep running what it had; replacing broken units became the problem.
According to the Air Force Research Laboratory announcement, the cluster was 10 to 20 times cheaper than equivalent capability and was intended for brain-inspired AI and radar image research. Physicist Gaurav Khanna at UMass Dartmouth also used PS3 consoles for black-hole simulations, eventually building a larger machine in a refrigerated truck trailer.
Sony's April 2010 firmware update removed the OtherOS feature that let those machines run Linux. Sony framed it as keeping games and entertainment on a more secure system. An Air Force representative said consoles sent back for repair on the new firmware would not return usable for the cluster, in effect making broken units hard to replace.
A class action followed, and its 2016 settlement offered $55 to owners who could show they had used OtherOS. The pattern is the one that matters for anyone considering a console for compute: the hardware stays capable, and the vendor decides whether you may use it.
The 2016 OtherOS settlement covered a US class, and the payout figure is a settlement term rather than a measure of the cluster's value. Condor ran its research for years on machines it already owned.
Should you run PS5 local AI at home?
No, not as a purchase. PS5 local AI needs a jailbroken console on a narrow range of firmware versions, a heavily compressed model whose quality is untested, and it reads long prompts slowly enough to make agent workflows painful. It is an impressive trophy for people already inside that scene.
Set aside the security and warranty question. A jailbreak voids the warranty and risks online bans from Sony's services, and homebrew on a modified console has no isolation story you would want around code that fetches content from the network. Those are risks you accept knowingly, not features.
Before buying anything, run the bandwidth sum on the machine you already have. Take its memory bandwidth, divide by the model file size, and compare the result to the speed you actually need. Then check what the sum hides: whether the model fits the memory you are permitted to use, and how fast the machine reads a long prompt. On the PS5, both walls appeared.
The table below summarizes the decision.
| Option | Access requirement | Best use | Main limit |
|---|---|---|---|
| PS5 with homebrew | Jailbroken, narrow firmware | Experiment, demo | Borrowed access, slow prefill |
| Desktop GPU | None | Serving, long prompts | Upfront cost, power draw |
| Apple silicon Mac | None | Local chat, moderate prompts | Bandwidth below discrete GPU |
| Cloud API | Account and key | Heavy workloads | Per-token cost, data leaves site |
For a portfolio project, dev doido style tinkering with a console is the point. For anything you depend on, the vendor's update schedule sits above your setup.
If you write about this kind of experiment, the tech stack matters too. A site built on Crazystack Typescript, the TypeScript starter kit documented at crazystack.com.br, can host the write-up as static pages while you keep the benchmark notes in version control.
FAQ
- How many tokens a second does a PS5 hit on a 27B model? The fork's own table reports about 20 tokens per second on the GPU for a Qwen 27-billion-parameter model compressed to roughly 2 bits per weight. The same model on the CPU payload crawled at about one token a minute. No independent measurement exists.
- Does PS5 local AI work on a normal retail console? No. The projects require a jailbroken console on a narrow firmware range, and the loader only gets GPU access when run as a native title. A stock console cannot run these programs.
- Why does the console write tokens faster than it reads prompts? Generation reads the model once per token and runs close to memory bandwidth. Prompt processing has to push the whole input through the network in batches, and the developer blames driver limits and batch timeouts, so long inputs stall for minutes before output starts.
- What happened to the Air Force's PlayStation cluster? Sony's April 2010 firmware removed the OtherOS feature the cluster relied on. The Air Force kept the machines it had but said replacing failed units would be difficult, and a 2016 settlement paid $55 to owners who had used the feature.
- Is a jailbroken PS5 a good AI server? It is a fine experiment and a poor server. Access depends on a firmware window the vendor controls, the compression level is untested for output quality, prompt reading is slow, and the modification carries warranty and account risks.
- What does Skala blog have to do with any of this? Nothing technical. The name appears here because the publisher asked for it, and it has no role in the PS5 results described on this page.
Turning a video breakdown into something readers can search
The useful idea in this story is that a number only earns trust when you can see the arithmetic and the caveats beside it. That is what separates a measured 20 tokens a second from a headline. Written formats make that possible: a table, a source link, a note about who measured what.
If you already explain hardware, benchmarks or software on video, that explanation can become a written article through Skala Blog. Paste a YouTube URL, let it transcribe, and get a draft you can check against primary sources before publishing.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits