诚实说明：不同网关对错误模型ID的报错措辞差别很大，有的返回404，有的400，有的直接回落默认模型不报错。本站还没逐个采集原文，所以这里给排查顺序，不给「标准报错长这样」——那种写法八成是从别处抄的。
按这个顺序查，别跳步
- 先确认实际生效的模型ID：
dsh --dump-config里模型那一段。你改的文件和它打印的，很可能是两回事。 - 再确认ID拼写与大小写：网关的模型ID通常区分大小写，且带版本后缀。
deepseek-chat与DeepSeek-Chat不是同一个。 - 再确认该网关是否提供这个ID：同一家在不同区域或不同套餐下的模型清单可能不同。查网关侧的模型列表接口。
- 最后才怀疑key与网络：前面三条都排除后再查。顺序反了，你会花时间在没坏的东西上。
一个低成本判别
把模型ID换成网关文档里明确列出的一个，其他都不动，再跑同一条任务：
读取当前目录的 package.json，只报 name 字段。
换成已知可用ID就好了 → 问题在ID；换了还报错 → 问题在key、网关地址或网络。这一步能把问题范围砍一半，比逐项试快。
记录时要写什么
- 报错的原文，不是你的转述（「说模型不存在」这种转述丢掉了关键信息）。
- 当时的模型ID、网关地址（可打码）、宿主版本。
- 你做了什么让它恢复。