# 本地 OpenAI-compatible 模型的 thinking/端口/守护诊断工具 ## 诊断流程样例 ### 输入 | 字段 | 示例 | |---|---| | base_url | `http://127.0.0.1:8000` | | 候选端口 | `8000,8080` | | model | `gemma4` | | 日志 | `/tmp/vmlx_serve.log` | ### Step 1: 端口和协议探活 - 检查 `lsof -nP -iTCP:8000 -sTCP:LISTEN` 与 `lsof -nP -iTCP:8080 -sTCP:LISTEN`。 - 请求 `GET /v1/models` 或最小 `POST /v1/chat/completions`。 - 结论示例：`8080` 不通，`8000` 返回 HTTP 200，后续诊断以 `8000` 为准。 ### Step 2: thinking 对照测试 | 测试 | 请求差异 | 期望观察 | |---|---|---| | 默认请求 | 不传 `enable_thinking` | 如果返回 `reasoning_content` 且耗时很长，说明默认仍在思考 | | 禁 thinking 请求 | 传 `enable_thinking:false` | `reasoning_content:null`，耗时和 completion tokens 明显下降 | 示例结论：默认 thinking 约 104.89s / 213 tokens；`enable_thinking:false` 约 3.21s / 16 tokens。瓶颈主要来自 reasoning 输出，而不是单纯端口或模型不可用。 ### Step 3: 客户端映射判断 如果 Cherry Studio UI 显示“关闭思考”，但服务端默认请求仍返回 `reasoning_content`，判定为客户端开关没有映射到服务端真正识别的 `enable_thinking:false`。建议不要只改客户端 UI，优先做服务端默认兜底。 ### Step 4: 守护方式检查 - `screen -ls` 能看到服务会话，且端口监听存在：判定为常驻有效。 - LaunchAgent 日志出现 `PermissionError: Operation not permitted: .../.venv/pyvenv.cfg`：判定为 macOS TCC/launchd 路径权限问题，不建议继续用当前 Documents 下 venv 直接托管。 ### 建议输出 ```md 诊断结果：服务实际监听 127.0.0.1:8000；客户端关 thinking 未可靠映射；服务端支持 `--default-enable-thinking false`；当前机器上 detached screen 比 LaunchAgent 更稳。 建议动作：用 `vmlx serve ... --default-enable-thinking false` 重启，并用 `screen -dmS vmlx-gemma4 ...` 常驻；重启后再次验证默认请求返回 `reasoning_content:null`。 ```