AI大模型和本地部署怎么排查，一次说清做法

线上调用回答变差、本地部署起不来，这两类问题经常被混在一起查，结果换模型、重装环境折腾一圈还是没定位到原因。这篇按「先分层再动手」的思路，把大模型使用和本地部署的排查拆成可照着走的顺序：先判断是模型、接入链路还是算力环境的问题，再给每一层的检查项和不适用的情况。

线上调用的回答突然变差，本地部署的服务起不来，这两类问题经常被混在一起查。结果就是换模型、重装环境、升级驱动折腾一圈，最后发现根本没定位到原因。这篇按「先分层再动手」的思路，把大模型使用和本地部署的排查拆成可照着走的顺序，先判断问题落在模型、接入链路还是算力环境，再给每一层的检查项和不适用的情况。

核心原则只有一条：一次只怀疑一层，一次只改一个变量。每次改完用同一条输入重跑，把结果记下来。没有基线就没有对照，排查会变成凭感觉猜。下面每一节都给了判断标准和具体动作，照着走比凭经验试要快。

先分清是「模型表现问题」还是「部署环境问题」

这两类问题的排查起点完全不同。模型表现问题指的是接口能通，但回答质量、格式、速度不对；部署环境问题指的是服务根本起不来、连不上、显存直接报错。混着查最容易白折腾，因为两边用的工具、看的日志、改的配置压根不是一回事。

判断方法很朴素：拿同一段提示词，分别打线上官方接口和你自己的本地服务。两边结果差得远，说明是模型差异或量化损失；两边一样差，那问题在提示词或喂进去的数据，跟部署无关。这个对照做一次，能砍掉一半无效排查。

模型表现不对：按输入、参数、版本三处查

先查输入。上下文是不是被截断，系统提示有没有被上层应用悄悄覆盖，上传的文档是不是解析失败变成乱码。这三件事在日志里不一定报错，但会稳定地把回答带偏。把实际送进模型的完整请求打印出来看一遍，很多问题当场就露馅。

再查参数。温度调得太高会让结果飘，最大输出长度设小了会把话截在半截，思考模式或流式返回没处理好也会让用户看到残缺内容。参数问题通常表现为「有时候好有时候坏」，跟输入问题的「稳定出错」正好相反。

最后查版本。别只看界面上的模型名字，要确认请求里真正传的模型标识是什么，有没有被中转层改写过。各家模型的功能定位和适用场景可以到 /models 核对当时的资料，别看名字就下结论。

• 输入侧：打印完整请求，确认上下文长度、系统提示、文档解析结果
• 参数侧：固定温度、输出长度、流式开关，逐项回退测试
• 版本侧：抓包确认实际模型标识，与站内模型库的功能定位对照
• 稳定性判断：同一输入连跑三次，稳定出错查输入参数，时好时坏查服务侧

服务起不来：按进程、端口、日志三层往下压

顺序不能乱。先确认进程还在不在，再看端口有没有被占用、是不是只绑在了本机回环地址上，最后才读日志。很多人一上来就翻日志，结果被几百行连锁报错淹掉，反而漏掉第一条真正的原因。

日志只看第一段报错，后面的多半是连锁反应。模型加载失败通常集中在三类：权重路径写错、权重格式和加载器不匹配、运行时版本对不上。跨机器访问失败，先查绑定地址和防火墙，别急着改客户端代码，那通常是最后才需要动的地方。

1. 确认进程用进程查看命令确认服务在跑，不在就直接看启动日志的第一条报错。
2. 确认端口检查监听地址是 0.0.0.0 还是 127.0.0.1，只绑回环时外部必然连不上。
3. 本机自测在服务所在机器上用最小请求打通，通了再查网络和防火墙。
4. 读首条报错只看日志最前面的错误，定位到具体是路径、格式还是版本问题。

# 示例：查进程、查监听、发一条最小请求
ps aux | grep -i server
ss -lntp | grep <端口>
curl -s http://127.0.0.1:<端口>/v1/models

显存、量化与硬件：算完再动手换配置

显存要按「权重占用 + 上下文缓存 + 并发余量」三块估，不能只看权重。权重占用大致是参数量乘以每参数字节数，量化档位决定这个字节数。具体换算到 /tools/speed-test 按当时的数值核一遍，别拿记忆里的数字当准。

显存不够时的优先顺序是：先降量化档位，再缩短上下文，然后减并发，最后才考虑换卡。量化档位越低越省显存，但质量损失也越明显，判断标准是拿你自己的任务做对照测试，而不是看别人的结论。别人的任务能接受，不代表你的能接受。

• 先算总账：权重、缓存、并发余量三块分开估，别只算权重
• 降档顺序：量化档位 → 上下文长度 → 并发数 → 硬件
• 质量判断：用你自己的真实任务做对照，别只看通用评测结论
• 可复现：每次调整记下配置和测速结果，形成基线

接入链路：本地服务和调用方之间的常见断点

本地服务跑得好好的，应用却连不上，先分清是地址不对、认证头没带对，还是返回格式不兼容。很多客户端默认按某家官方接口的返回结构解析，本地服务少个字段就会解析失败，看起来像「连不上」，其实是格式问题。

排查顺序是先手工打通再回头查配置。用 curl 发一条最小请求，把返回原文看一眼，能省掉大量猜测。这条路只适用于你自己可控的服务；如果用的是第三方中转，要按对方的口径查，别照搬本地部署的步骤，两边的责任边界不一样。

什么时候该停下来承认这条路不合适

有些信号出现时就别再硬调了：模型能跑但速度不可用、显存余量长期贴着上限、每次升级都卡在硬件上。这时候要选的不是继续调参数，而是换更小的模型、换量化方案，或者退回按量调用。边界可以参考站内自建与调用对比的结论，对照自己团队的真实负载看。

判断标准是把「省下的调用费」和「维护投入」放进同一张表里对照。只算硬件成本、不算人力和时间，最容易误判。一家 5 人小团队如果没人专职维护，隐性成本往往比想象的高，这类情况更该优先考虑按量调用。

一份可以直接照着跑的排查清单

把上面几节压成一张能直接执行的清单。核心是两条纪律：一次只动一层，一次只改一个变量。做到这两条，排查就从碰运气变成了可累积的过程。提示词和测速结果定期重测，出问题时才有对照基线。

1. 记录现象写清报错原文、复现步骤、发生时间、实际模型标识，别只写「不好用」。
2. 分层定位在模型表现、服务进程、网络链路、硬件资源四层里选定一层，一次只查一层。
3. 单变量验证每次只改一个配置，改完用同一条用例重跑，结果记下来。
4. 建立基线常用提示词和测速结果定期重测存档，下次出问题直接对比。

模型资料和定位对照可以随时回 /models 查，测速与资源测算用 /tools/speed-test，接入方式如果考虑第三方中转，可信度检测和价格追踪分别在站内的相应页面核对当时的数字。