前阵子刷到有人用 PS5 跑本地大模型，正好我也有一台吃灰很久的 PS5。放着也是放着，就想把它翻出来试试，给它找点游戏以外的活干。
具体安装交给 Windows 上的 Codex。它查资料、下载、传文件、读日志，我负责拿手柄开应用和重启 PS5。原本想先用小一点的模型测试，后来干脆改成直接上 27B，测试和实际使用都用它。
10 月 17 日开始折腾，到第二天凌晨，Qwen3.8 27B 已经能在 PS5 GPU 上回答请求。中间花时间的地方，包括 Windows 的 DNS 端口和几个组件的版本搭配。
这次用的机器和版本
PS5 固件是 13.60，保留原样，用未登录 PSN 的本地用户，关掉系统更新的自动下载和安装。电脑是 Windows 11，两台机器在同一个家庭内网。整套安装都靠一层自制程序运行环境撑着，下面这张表就是为此准备的。
| 组件 | 这次最终使用的版本 | 做什么 |
|---|---|---|
| WebKit Autoloader | 0.6.1 | 安装并启动后续运行环境 |
| Payload Manager | 0.5.2 | 加载 Payload，管理自动加载顺序 |
| etaHEN 社区适配版 | 2.5B-unified.1 | 提供这台 13.60 主机需要的自制程序支持 |
| kstuff-lite | 上述 etaHEN 内置的 1.11 | 底层运行支持，不再重复加载一份 |
| ShadowMountPlus | 1.7beta4 | 挂载应用和数据目录，让应用出现在主屏幕 |
| ftpsrv | 0.21.1 | 用 FTP 传应用和模型 |
| PS5LM | 0.9.0 | 加载 GGUF 模型，通过 GPU 推理并提供 API |
这张表是几轮调整后的组合。最初下载的 etaHEN 和 ShadowMountPlus 都在后面换过，原因各不相同。
我的 PS5 地址是 192.168.50.5，Windows 是 192.168.50.58。后面的地址沿用这两个例子，照着配置时换成自己的内网地址。
先让安装页在 PS5 上打开
首次安装需要在 Windows 上运行 WebKit Autoloader Host。它提供临时的 DNS 和 HTTPS 服务，把 PS5 的 DNS 指向这台电脑后，从系统的“用户指南”进入本地安装页。
第一处卡点出在电脑：Host 要用的 UDP 53 已经被 Windows 的 SharedAccess，也就是 Internet Connection Sharing 占着。Agent 查了端口、服务和网络共享状态，确认情况后临时停止 ICS 和相关的 HNS，释放端口。服务原来的启动类型也记了下来，安装结束再恢复。
所以 Host 起不来，先看是谁占了端口，别顺手把一批网络服务永久禁用了事。
Host 的 DNS 和 HTTPS 检查通过后，我在 PS5 上打开用户指南，看到安装控制台。中途我一直盯着下面的 Installing，还以为没装完；发了整张照片才看清，上面已经是绿色的 Installed successfully，进度条也到了 100%。底下那一行只是旧日志。
重启后，Payload Manager 的 8084 端口开始响应，/version 返回 0.5.2。电脑这边终于能继续传文件、加载后面的组件。
etaHEN 和数据目录各卡了一次
先遇到的是 etaHEN。原版 2.5B 发过去以后没有正常留在运行状态，查到的固件支持表也缺少这台机器的 13.60。后来换成 GronedWaffel 的 v2.5B-unified.1 社区适配版，正常重启，再加载，才确认了它的启动状态和进程。
这个版本已经带了 kstuff-lite 1.11，自动加载列表里单独加载 kstuff 的安排就去掉了。教训挺朴素：几个东西都叫”必需组件”，也得先看看它们是不是已经打包在一起。
PS5LM 的应用目录也要认准。这次用的是 cobanov 的 v0.9.0，Title ID 为 PPSA99575。解压发布包后，通过 2121 端口的 FTP，把整个目录放到：
/data/homebrew/PPSA99575/
└── eboot.bin然后又碰到数据目录问题。FTP 能传文件，PS5LM 应用里却不能正常访问需要的 /data。这次卡在 ShadowMountPlus：最初用的 1.7beta2 缺少所需的沙箱挂载，后来换成 1.7beta4，它的更新里明确补了 /data 的自动挂载。
换好后正常重启，让旧版本退干净，再打开 Autoloader 和 PS5LM，检查应用内的数据访问，过了才传模型。图标能出现在主屏幕，和应用真能读写自己的数据，是两件事，得分别确认。
把 27B 放进去
模型用的是 Unsloth 的 Qwen3.8-27B-UD-Q2_K_XL.gguf，文件约 9.83 GB。先在电脑下载并检查 SHA-256，再通过 FTP 传到：
/data/PS5LM/models/Qwen3.8-27B-UD-Q2_K_XL.gguf应用包的 27 个文件，是传回电脑逐文件核对过的。模型文件大得多，就偷了个懒：让 Agent 跳过远端整文件回读，只保留本地哈希、PS5 接收大小，再用后面的实际加载和推理结果兜底。
模型第一次加载到 Ready，实测用了 115.8 秒。日志识别到 PlayStation 5 GPU，最后运行的配置是 32K 上下文，KV Cache 为 q4_0。
我接着又问能不能把上下文开大。算了一遍当前模型和内存预算，结果是：
| 上下文档位 | 规划器估算的内存需求 |
|---|---|
| 32K | 约 10.76 GiB |
| 64K | 约 11.32 GiB |
这台机器加载前可用约 11.00 GiB，32K 已经贴着天花板了。规划器按预算也会选回 32K，这次就留在这一档。换更小的量化或模型能开多大？到时候重新算、重新测。
电脑直接连 PS5 就能聊
PS5LM 自己有 OpenAI 兼容接口。我这台的连接参数是：
| 配置项 | 填什么 |
|---|---|
| API 地址 | http://192.168.50.5:8081/v1 |
| 模型 ID | PS5 |
| API Key | 客户端允许就留空；必填时用占位值 ps5lm |
这套配置没有启用 API Key 鉴权，ps5lm 只是为了填过客户端的必填项。服务放在可信家庭内网里，路由器没有给它做公网映射。
可以先读两个地址：
Invoke-RestMethod 'http://192.168.50.5:8081/health'
Invoke-RestMethod 'http://192.168.50.5:8081/v1/models'前者看服务是否就绪，后者就是客户端“自动获取模型”时读取的列表。再发一条很短的实际请求：
$requestBody = @{
model = 'PS5'
messages = @(
@{ role = 'user'; content = 'Reply with exactly PS5_OK' }
)
max_tokens = 16
} | ConvertTo-Json -Depth 5
$reply = Invoke-RestMethod `
-Uri 'http://192.168.50.5:8081/v1/chat/completions' `
-Method Post -ContentType 'application/json' -Body $requestBody
$reply.choices[0].message.content部署时测过普通 Chat、SSE 流式和 Responses 接口，都拿到了实际回复。暖机后的短请求，直接接口首字约 0.445 秒。不过测试输出只有几个 token，不能拿这个数字推算长文章的生成速度，32K 的长文本压力测试也还没做。
模型 ID 还有个小插曲。最初客户端自动检测出来的是一整条 GGUF 文件路径，看着很怪。我问能不能直接返回 PS5，最后在 /data/PS5LM/env.txt 里设置了：
LLAMA_ARG_ALIAS=PS5正常重新启动应用后，GET /v1/models 的 data[].id 就变成了 PS5。客户端重新获取列表即可。这个名字只是对外的别名，里面跑的仍是同一个 27B。
日常用就直接连这个地址，推理全在 PS5 上跑，电脑只负责发消息。
自动加载要接到应用启动后面
模型能回答以后，我又想把日常启动的手动操作减掉。这里要接好两步：打开 PS5LM，再由应用加载默认模型。
先在 PS5LM 的设置里保存默认模型，对应 /data/PS5LM/settings.json 的相关字段是：
{
"auto_load": true,
"default_model": "/data/PS5LM/models/Qwen3.8-27B-UD-Q2_K_XL.gguf",
"ctx_cap": 32768,
"kv_type": "q4_0"
}这些设置负责在 PS5LM 已经打开后加载模型。前面还缺把应用打开这一步。
Agent 用 ps5-homebrew-dev-protocol 的启动器源码，固定目标 PPSA99575，编译并传到主机。启动请求经过现有 Payload Manager 和主机本地的 elfldr，不需要额外开放网络 9021 端口。
然后把它接进 Payload Manager 的自动加载列表，顺序配置为：
etaHEN（内置 kstuff-lite）
↓ 等 40 秒
ShadowMountPlus 1.7beta4
↓ 等 5 秒
ftpsrv
↓ 等 10 秒
PS5LM 启动器
↓
PS5LM 按设置加载默认 27B最后实际走了一遍应用正常退出、远程重新打开、自动加载模型，再发请求确认回复。没有额外发送手动加载命令，从请求打开应用到 Ready 用了 112.7 秒。
自动加载测试后的实际画面。屏幕上的 26.3 tokens/s 是最后一条仅输出 4 个 token 的请求统计，不作为持续吞吐结果。
完整开机后还是要进本地用户、手动开一次 WebKit Autoloader，后面的步骤才按列表走。从冷启动到可调用的完整流程这次没复测；实际跑通的是上面那段应用重启加自动加载。
用完安装工具，再回到日常使用
首次安装用的 Windows Host 可以退出了。关闭窗口后，Agent 重新检查了进程、端口和服务：安装进程已经退出，HNS 和 ICS 都恢复到安装前的运行状态及启动类型。日常调用模型不用一直挂着这个安装器。
中间我还让 PS5 休眠过一次，电脑这边马上连不上服务。唤醒后，PS5LM 的监听恢复，也重新拿到了模型回复。需要用它的时候，就得让主机保持清醒；休眠期间当然接不了请求。
到这里，这台吃灰的 PS5 能加载 27B，也能从电脑发请求拿到回答——游戏以外的活，算是找到了。