PS5LM Turns a Jailbroken PS5 Into a Local LLM Server, Running Qwen 3.8 27B at 20 tok/s

TL;DR

PS5LM is a GPL-3.0 homebrew app from Mert Cobanov that runs llama.cpp on a jailbroken PS5's GPU and serves the model to the rest of your house. The v0.9.0 release on October 16 moved the project from a CPU-only payload with a 1.6 GB model cap to a native title with 11.4 GB of GPU-addressable memory, OpenAI-compatible and Anthropic-compatible endpoints on port 8081, a dashboard on the TV, and a decision-model API borrowed from Ollaya. On a PS5 Slim it gets Qwen 3.5 0.8B to 207 tokens a second, Qwen 3.5 9B to 55, and a 2-bit Qwen 3.8 27B to about 20 with a 64k context. The Hacker News thread hit 365 points, and the repo passed 500 stars a little over two weeks after its first commit.

What shipped

The repo's first commit landed on October 1 with the stated goal of running llama.cpp, and with it any GGUF, on the console. The October 2 releases were an ELF payload: CPU inference, a browser chat page, and a hard limit on model size. Two weeks later the v0.9.0 app is something you could leave running under the TV.

It loads a GGUF onto the console's RDNA 2 GPU through llama.cpp's Vulkan backend, running on the RADV driver from PS5_Vulkan. Clients on the network hit /v1/chat/completions (OpenAI's shape) or /v1/messages (Anthropic's shape, and the README says Claude Code works against it) at http://<console>:8081, or use a plain browser chat page. Whatever model name a client sends, the loaded model answers.

The TV shows every request as a chat: which device asked, what it asked, and the reply as it streams. A Console page charts temperature, power draw and GPU and CPU load over the last two minutes or the last hour. A planner reads each GGUF header and assigns the longest context and best KV cache that fit the memory left, and the app downloads from Hugging Face on its own to internal storage, an M.2 drive or a USB stick. Models with an image projector (Gemma 4, MiniCPM-V, d1) accept pictures.

The project credits abhi245y, whose PS5LM Plus was the native GPU app this one grew from, and a stack of PS5 homebrew work: ps5-homebrew-ui for the interface, driver patches from PS5CEMU-HAR, and the ps5-payload-dev SDK.

The numbers, on a PS5 Slim

The README's table is the headline: Qwen 3.5 0.8B at Q4_K_M (0.5 GB) runs at 207 tokens a second, Qwen 3.5 9B at Q4_K_M (5.3 GB) at 55, and Qwen 3.8 27B in Unsloth's UD-Q2_K_XL (9.2 GB) at about 20 with a 64k context. The project's console notes add the less flattering detail: the 27B at an even smaller IQ2_XXS quant loaded in 82 seconds, ran prompts at 35 to 50 tokens a second, and generated at 21 tokens a second on a short prompt but 9 after the web UI's 371-token prompt. These are the maker's own measurements on one console.

The ceiling is memory bandwidth, and the project site says so. Decoding a dense model reads every active weight once per token, so tokens per second is roughly bandwidth divided by bytes per token. The PS5 has 16 GB of GDDR6 on a 256-bit bus at 448 GB/s, shared between an 8-core Zen 2 CPU and a 36-compute-unit GPU rated at 10.28 TFLOPS. The site says the 9B model reads weights at about 70% of that bandwidth. Picture a librarian who has to re-read the whole 5 GB book before saying each next word: the length of the book and the speed of the reading set the pace, and being clever about the words does not help.

That arithmetic is also why the models doc expects mixture-of-experts files to be the better fit. Qwen 3.6 35B-A3B at IQ2_XXS (10.02 GiB) and gpt-oss 20B at MXFP4 (10.7 GiB) both squeeze into the heap and read about a gigabyte per token instead of seven to nine. Qwen 3.8 Flash-Next at 180B does not fit at any quant, and the doc says so.

Why the GPU took two weeks

The interesting engineering is in the gap between the October 2 payload and the October 16 app. The console notes read like a lab notebook, each finding attached to a crash.

A payload launched through elfldr starts with a memory budget of zero, the budget of a system app, so it gets no direct memory at all and has to live in the 8 GiB flexible pool it shares with the operating system. The notes measured a malloc ceiling of 6.25 GiB, found that holding about 6 GiB froze the home screen until the process ended, and found that locking 2.7 GB of weights in RAM (Qwen 3.5 4B) froze the whole console. The payload build refused files over 1.6 GB for that reason.

Locking was not optional, either. While the PS5 browser sat in front, the system paged the payload's memory to disk, so models over about a gigabyte ran 10 to 65 times slower than their size suggested. An idle server was found holding 6 MB of a 600 MB model. Pinning the weights with -lm mlock took Qwen 3.5 2B from 0.9 to around 9 tokens a second.

The CPU side was no kinder. A payload is pinned to five of the console's 16 logical CPUs, all shared with system services, and llama.cpp's default busy-wait on every core starved those services until the console shut itself down, twice. A patch now sets the default thread count to the allowed CPUs minus two and turns polling off. The CPU-only result at the end of all that was Qwen 3.5 0.8B at 13 to 14 tokens a second. The same model on the GPU does 207.

The fix was to stop being a payload. A native title (PS5LM ships as its own title ID, PPSA99575, installed through ShadowMountPlus) gets 12 GiB of direct memory and the GPU. RADV reports an 11.44 GiB device heap once the unified-heap flag for APUs is set, and 8 GiB without it. Titles bring their own list of traps: calling exit() ends in SIGSYS, so the app never exits; several libc functions resolve to null and had to be reimplemented; the SDK's getaddrinfo always fails; there is no HOME, which made llama.cpp throw looking for its cache directory. Unloading a model also leaves part of its GPU memory held (11.01 GiB free fell to 5.77 GiB after one load and unload), so the app changes models by writing the choice to a file and re-executing itself.

Even the download path fought back. The kernel caps the socket receive buffer at 64 KB, so one connection to Hugging Face's CDN topped out at 0.9 MB/s. Sixteen parallel connections pulling 8 MiB pieces got that to about 12.5 MB/s.

How a request flows

The decision-model endpoint is the odd feature. PS5LM answers /v1/systemone, the API Ollaya serves on a PC for Jev-style decision models: you send a state and a set of typed questions (a choice, a score, a yes-or-no), and the model answers them all in one forward pass with calibrated probabilities and no generated text. The Suggested list carries d1 Omni 600M, d1 3B and Clef Flash. The README's figure for d1 Omni is three questions in 0.3 seconds, or a 720p image plus seven questions in 2.9 seconds. The changelog admits a decision model can stop answering after about 55 requests in a row while the server waits on the GPU; language models are not affected.

What you need, and what it costs

A PS5 on firmware 7.00 to 13.60, jailbroken, with kstuff-lite, etaHEN and ShadowMountPlus loaded. elfldr and ftpsrv are recommended for telemetry and for copying models over FTP. Install is a zip from the releases page, one folder copied to /data/homebrew, and a model pulled from the Suggested list. The repo ships no Sony SDK files, keys, firmware or weights.

The economics are the part Hacker News chewed on. Since Sony's April 2 price increase, a PS5 Slim Digital Edition lists at $599.99 in the US and the disc model at $649.99. That buys 16 GB of GDDR6 at 448 GB/s with the computer already attached, which several commenters compared favorably with a 16 GB GPU or a Mac mini at this year's memory prices. Others pointed at the AMD BC-250, an ex-mining board built on a cut-down PS5 APU, as a cheaper way to get similar silicon without a jailbreak, as a guess rather than a tested path. The site also notes that sustained loads make the console run warm and spin the fan up. The PlayStation has finally found something to do with all that fan noise besides Call of Duty.

The main caveat came from the thread as well: a 2-bit quant of a 27B is a noticeably worse model than the 4-bit one, and the 27B needs long reasoning traces to be good, so 20 tokens a second feels slower than it sounds. The commenters who had used it put it in the right frame: a 20 tok/s model that never stops is fine for reading a codebase overnight or watching a camera feed, and a poor stand-in for a frontier coding agent, which is the question half the thread asked.

Key Takeaways

• PS5LM runs llama.cpp's Vulkan backend on a jailbroken PS5's RDNA 2 GPU, with 11.4 GB of memory for a model and its context, and serves OpenAI-style and Anthropic-style APIs on port 8081.
• Project figures on a PS5 Slim: Qwen 3.5 0.8B at 207 tok/s, Qwen 3.5 9B at 55, and a 2-bit Qwen 3.8 27B at about 20 with 64k context, dropping to 9 after a long prompt.
• The jump from the October 2 payload to the October 16 native app is the story: payloads get no direct memory, froze the console past 2.7 GB locked, and were pinned to five CPUs; a title gets 12 GiB and the GPU.
• Mixture-of-experts files should fare better than dense 27Bs on this hardware, since decode speed is bandwidth divided by bytes read per token.
• It also serves Ollaya's decision-model API for d1 and Clef models, with a known stall after about 55 consecutive requests.
• You need firmware 7.00 to 13.60 and a jailbreak. The benchmarks are the maker's own, and a 2-bit 27B gives up noticeable quality against the 4-bit file.

Sources: PS5LM on GitHub, PS5LM project site, PS5LM console notes, PS5LM models doc, PS5LM changelog, PS5LM v0.9.0 release, Hacker News discussion, PlayStation 5 (Wikipedia), PlayStation Blog, price changes effective April 2, 2026.