A developer known as abhi245y reports running a 27B-parameter large language model (LLM) on the GPU of a jailbroken PlayStation 5, generating about 20 tokens per second. (The B stands for billion.) The tool is PS5LM Plus, a fork of PS5LM, which ports the LLM runtime llama.cpp to the PS5. It runs as a console app with access to the GPU and memory, and it accepts questions sent from other devices on the same home network. But there is a large gap between how fast the model generates text and how long it takes to read a long prompt and produce a first reply.
The GPU and app memory allocation behind the 27B run
The original PS5LM, developed by Mert Cobanov, began as an add-on payload that runs models on the PS5's CPU. According to its published documentation, the amount of memory it can keep a model resident in without disrupting the home screen is about 1.6GB, and it initially targeted small models such as Qwen's 0.8B and 2B.
PS5LM Plus adds a console app that uses the GPU. According to the developer's explanation, a payload is given about 6GiB of memory but cannot use the GPU. Launched as a console app, it gets 12GiB of direct memory plus GPU access. The original's "about 1.6GB" is the amount for keeping a model resident, while this "about 6GiB" is the memory allotted to the program, so the two figures are not different expressions of the same limit.
Plus uses llama.cpp's Vulkan support and drives the GPU with a PS5 port of RADV, a community-made AMD driver. The region it actually uses is described as a single combined 11.44GiB. By moving computation from the CPU to the GPU and changing how the program is launched, it secures room to hold the model.
The model documentation lists the PS5's total memory as 16GB, shared across the whole system. That does not mean a model can use all 16GB. Separating total capacity, the app's allocation, and the region that can actually be secured also explains why quantization was needed to fit a 27B model.
Reading quantization and cache settings together
The Qwen3.8-27B used here is a low-bit quantized version, which represents weights with fewer bits to cut size. The 27B figure refers to the parameter count, so the same name does not guarantee the same weight precision or memory requirement.
The table below lists measurements from the PS5LM Plus documentation as of October 15, 2026, alongside model size and context settings. All are the developer's own measurements on the PS5 GPU, not results from independent reproduction tests.
| Model / quantization | Model size | Context length / KV cache format | Generation speed |
|---|---|---|---|
| Qwen3.8-27B UD-Q2_K_XL | 9.2GiB | 32k / q4_0 | 20.3 tokens/s |
| Qwen3.8-27B UD-IQ2_XXS | 6.8GiB | 64k / q8_0 | 20.7 tokens/s |
| Gemma 4 E4B QAT q4_0 | 4.8GiB | 64k / q4_0 | 61 tokens/s |
| Llama 3.2 3B Instruct Q4_K_M | 1.9GiB | 64k / q8_0 | 124 tokens/s |
Source: PS5LM Plus per-model measurement table. The Gemma and Llama results were measured with the models loaded from USB. A token is the unit in which a model processes text and does not map one-to-one to Japanese characters or words.
Of the two 27B results, the smaller version secures a longer context. However, the quantization method and KV cache format also differ. The KV cache, which holds already-processed context, takes up space separately from the model weights, so fitting the weights does not mean conversations of any length can be handled. Plus checks free memory and chooses a context length and cache format that fit for each model.
That the generation speeds were close under these conditions does not mean the answer quality of the two quantized versions is equivalent. The published measurement table includes no comparison of how much accuracy or reasoning ability changes with lower bit counts. Also, 124 tokens per second is the result for the small Llama model, not the speed of a 27B model. Useful comparisons for a given purpose only become possible once model size, quantization, and context settings are matched.
Even at 20 tokens per second, the first reply takes time
Separate from the speed at which text is generated once it starts, a model needs time to read its input. This is barely noticeable for short questions, but code-editing tools send instructions, tool definitions, and files together, so this step tends to be long.
The developer's connection guide puts the 27B model's input processing at 35 to 50 tokens per second. Assuming the developer's 35–50 tokens per second holds steady, reading 20,000 tokens alone would take roughly 6.7 to 9.5 minutes. This is an estimate calculated from the "Which model" section of the guide, viewed on October 15, 2026, as 20,000 ÷ 50 ÷ 60 and 20,000 ÷ 35 ÷ 60, rounded to one decimal place.
It excludes model loading time and answer generation time, and is not a measured first-response time. Moreover, the real-device testing section of the same guide also mentions processing input at about 30 tokens per second. The figure should not be read as a guaranteed constant speed, but as a sense of scale: with long inputs, the first reply can take minutes. The developer says later exchanges can reuse the cache and run faster than the first.
The difference shows up in a small code-editing test on real hardware. On October 10, 2026, the developer reportedly tried a task of adding an addition function to a two-line Python file, using Qwen3.8-27B UD-IQ2_XXS, a 64k context length, and a q8_0 cache.
opencode 1.18.35 completed the edit in 208 seconds, while Claude Code 2.1.296 took 613 seconds, most of it spent processing the initial long input. codex 0.161.0 is recorded as having gone on to verify the result by running it after the edit, but because each tool sends different instructions and does different processing, these results cannot be used as a performance ranking.
Even if the file itself is short, the wait grows if the surrounding instructions are long. Being able to hold a 64k context and being able to read that context quickly need to be evaluated separately.
What it takes to turn a PS5 into a home server
PS5LM Plus shows its operating status and a model list on the TV, and serves a browser-based chat screen to smartphones and PCs on the same network. It supports choosing GGUF-format models from internal storage as well as M.2 and USB, and the list also shows whether each model fits in memory.
It also provides an endpoint for connecting development tools. The guide says it supports three API formats: OpenAI Chat Completions, OpenAI Responses, and Anthropic Messages. The significance is that existing tools can send requests to the PS5, but the model that actually answers is the one loaded on the PS5. The model name written in a request is ignored, so one cannot expect the same capability as a commercial service's model just because the API name matches.
Use requires a so-called jailbroken PS5, with restrictions lifted so unofficial software can run. The additional software Plus lists as required is kstuff-lite, etaHEN, and ShadowMountPlus, and this is not something that can be installed as an official app on a standard PS5.
The milestone here is that a large model runs on a game console's GPU and can be used from other devices. To judge practical uses next, it would help to compare time to first reply, answer accuracy, and stability under repeated use, with identical inputs and quantization conditions. With that verification in hand, one could decide whether to leave short conversations to a PS5 at home or also use it for long code edits, based on more than the parameter count.