把模型部署到本地之后很多人想的第一件事就是赶紧跑个推理看结果。但“能出结果”和“正常运行”之间隔着一条很长的沟。前两天一个朋友找我说他的本地模型“看着没问题”进程在、显存也占了、接口也能通但实际用起来回答越来越短有时候干脆卡半天才吐一个字。这种状态就是典型的“半正常”光看表面根本发现不了。所以判断本地模型是否正常运行靠的不是一两条命令而是一套覆盖系统状态、性能指标、输出质量、长时稳定性四个维度的检查方法。这篇内容就是把这套方法完整拆出来讲清楚每一步该看什么、为什么看、异常了怎么办适合刚接触本地部署、也适合部署完跑了几周但总觉得不踏实的同学。1. 判断前的准备工作先把“正常”的定义拆开1.1 “正常运行”至少包含两层含义很多对模型部署不熟的同学习惯把“进程存在”当成“运行正常”这是一个非常容易踩的误区。进程存在只能说明操作系统层面有一个活跃的脚本进程但它背后对应的推理请求、显存分配、生成逻辑是否健康完全看不出来。实际情况里进程活着但推理线程死锁、请求排队堆积、显存碎片化导致分配失败这些问题通通不会杀死进程却会明明白白地让模型“不能用”。所以我在判断本地模型是否正常运行之前一定会先做一次需求拆解把“正常”分两类。第一类是服务可用性即服务进程活着、监听端口可以被访问、API能及时响应请求这是基础。第二类是推理健康度包括生成速度没有明显退化、输出内容语义合理、显存/内存没有异常增长、并发场景下不会轻易崩溃。第一类只保证“服务没死”第二类才保证“服务还能好用”。1.2 为什么光看“有没有报错”也不够还有一类检查误区是“没报错就等于正常”这在本地模型场景下同样不够可靠。我现在跑的推理服务里有过一次典型的无报错异常日志里全是INFO没有任何ERROR但请求一旦进入上下文中后段生成速度骤降最终等来一个超时。这种慢请求在很多框架里不会默认打错误日志只有把响应时间一起捞出来做统计才会暴露。也就是说判断本地模型运行状态本质是一个多层次的体检而不是一次简单的“活着/死了”二值判断。模型只要还能张嘴说话就没有任何一条日志会主动告诉你“我快不行了”你必须拿着检查工具主动去测。后续所有章节就是围绕系统层、性能层、质量层、长时层四块来展开把检查动作落到具体命令和具体阈值上。2. 系统层面体检5分钟快速确认服务还“活着”2.1 进程与监听端口最基本的两条命令系统层检查的第一步永远是从进程开始。我常用的命令很简单ps -ef | grep -E python|model|server看到至少一个常驻的Python进程或者模型服务进程基本确认服务在跑。但这一步要注意一个细节很多本地模型框架会启动多个worker进程比如前置API进程加后端推理进程。如果你发现只有一个进程就要想一下框架本身的设计是否支持多进程别因为看到两个进程就以为是异常。反过来如果进程PID频繁变化或者出现大量僵死状态标记Z说明进程健康已经有问题。端口监听是第二道确认。用netstat -tlnp | grep 8080或者lsof -i:8080确认监听地址是否正常。我习惯把监听地址设置为127.0.0.1而不是0.0.0.0因为本地模型多数只给本机服务对外监听等于扩大了暴露面。如果发现监听在 :: 或 0.0.0.0 且不是刻意配置这本身也是一种“不正常”的信号。2.2 API接口探活用最小请求测试服务响应进程和端口确认都通过了还存在一种情况服务虽然挂着但推理线程已经卡死请求发过去永远不返回。所以探活不能只检查端口必须真正打一个API请求进去。最简单的方式是发一个极小生成量的请求比如curl -s -o /dev/null -w 耗时: %{time_total}s | HTTP状态: %{http_code}\n \ -X POST http://127.0.0.1:8080/v1/chat/completions \ -H Content-Type: application/json \ -d {prompt: ping, max_tokens: 1}吸引点在于max_tokens: 1这个参数会让服务只生成一个token用来验证“能不能完成一轮推理”而不是“能不能完整回答”。如果连最大token为1的请求都返回超时或直接连接失败说明服务已经处于假死状态需要进一步看日志和显存。探活请求也可以顺手加上temperature: 0.1固定输出确定性。这样每次探活的输出内容都应当是接近固定的“ping”回复如果连这么短的内容都出现明显异常字符系统层基本可以判定为过不了。2.3 GPU状态显存占用与算力利用率分别怎么看GPU是本地模型运行的“心脏”nvidia-smi是大部分时候的第一选择。很多同学一看到显存占用90%就紧张其实这个数值本身没有绝对的好坏必须结合上下文判断。显存占用高只是说明模型权重和KV cache已经加载进去了模型在加载完成状态下显存占用高位是正常的。更值得关注的是“显存是否持续上涨”。比如刚启动时占用8GB跑几轮对话后变成8.5GB、9GB、10GB这个趋势是显存泄漏的典型信号。关于显存泄漏的验证方法我在第五部分会专门展开这里先记住一个爆发点只看瞬时值没用要看趋势线。GPU利用率则判断的是“模型是否在干活”。正常推理过程中利用率会有明显波动短时冲高又回落。如果你看到GPU利用率常年在0%左右但接口又迟迟不返回大概率是推理已经卡在某一步CPU逻辑上面根本没有进入GPU计算。反之利用率始终打满100%也不是好事尤其在单并发场景下说明可能存在循环内死耗算力、生成卡在某个重复环节的问题。2.4 日志文件很多隐藏问题其实都写过预告日志是系统层检查最容易忽略的部分。默认情况下很多本地推理框架会把日志打到终端或者logs/目录下但很少有人会真的定期去看。我的习惯是启动服务后隔一段时间就tail -n 100看几种关键日志启动阶段有没有显存分配失败、推理阶段有没有CUDA error或OOM关键字、请求完成有没有不正常的长耗时记录。有一种非常隐蔽的场景日志里偶尔出现CUDA out of memory但服务没有退出。这种情况通常是某个并发请求临时申请显存失败框架做了捕获并把请求丢掉。表面看服务还是活的实际上某些请求已经被悄悄丢弃。这种情况不靠日志根本发现不了。所以日志检查不能以“没有红色ERROR”为标准而是要看有没有“不该出现的重试或丢弃”。3. 性能指标量化用数据代替“感觉变慢了”3.1 首token延迟TTFT到底怎么测系统层检查能解决“服务活不活”的问题但“服务响应快不快”需要靠性能指标。判断本地模型性能状态我重点盯两个数字首token延迟和平均生成速率。首token延迟指的是从用户发出请求到模型吐出一个新token的时间。它直接反映这套系统的“启动速度”包括预填充、显存调度、输入处理全链路耗时。手动测量时不需要复杂工具直接在python里写一段计时即可import time import requests url http://127.0.0.1:8080/v1/chat/completions payload { prompt: 请用三句话介绍本地模型部署, max_tokens: 256, temperature: 0.3 } start time.time() resp requests.post(url, jsonpayload, streamTrue) first_token_time None full_text for line in resp.iter_lines(decode_unicodeTrue): if line and first_token_time is None: first_token_time time.time() - start # 简易解析SSE格式 if line.startswith(data:) and line[5:].strip() ! [DONE]: full_text line[5:] total_time time.time() - start print(f首token延迟: {first_token_time * 1000:.0f} ms) print(f总耗时: {total_time:.2f} s) print(f生成速率: {len(full_text) / total_time:.1f} token/s)以我平时跑的量化模型为例7B级别量化模型在消费级显卡上首token延迟在800ms到2s之间算正常范围。如果首token延迟突然从前一天的几百毫秒涨到5秒以上哪怕最终回答还是出来了也代表某个环节已经出现性能退化。3.2 生成速率与整段回答耗时的计算逻辑生成速率通常用每秒生成的token数来表示。注意不要用“字符数”代替“token数”中文字符和token之间没有固定比例会比较误导。业内比较通用的估算方式是一个中文汉字大概对应0.6到1个token但要看具体分词器最稳妥的做法还是直接看response返回的usage字段。usage: { prompt_tokens: 128, completion_tokens: 512, total_tokens: 640 }用completion_tokens除以实际生成耗时就是准确的平均生成速率。7B量化模型在常规消费级显卡上跑出10到25 token/s都算正常跑出个位数比如3到5基本可以确认服务已经处于降级状态。生成速率下降的常见原因有几个并发请求太多导致资源争抢、上下文长度特别长导致每步计算量变大、温度参数设成了随机性太高让采样过程变慢这个影响小而最容易被忽略的是KV cache缓存满了之后开始频繁做重算。这些原因光看“生成速率慢”是不够的还要结合显存状态和并发曲线一起判断。3.3 建立基线和“上周的自己”比才有意义性能指标的绝对值参考意义有限真正有价值的是和基线对比。我的习惯是部署完模型后立刻跑一组标准测试把所有权重记录下来——首token延迟多少、生成速率多少、8并发下的平均响应多少、显存峰值多少。这组数据就是这台机器上“健康状态”的基准。后续做日常检查不需要每次都全部重测每周抽一天跑一遍同样的脚本把结果跟基线比对。偏差超过30%就要警惕超过50%就基本可以判定有严重资源泄漏或者配置漂移。这里有个操作心得测试集要和上线的实际任务保持一致。如果你实际上线任务都是几百字的短问题那就别用5000字长文去测基线反过来如果日常就是长文总结那短问题测试没有参考意义。固定同一条测试prompt、固定随机种子和temperature得到的数据才有可比性。4. 输出质量检查回答变“奇怪”才是最大的坑4.1 语法层异常乱码、重复、截断、特殊符号系统层看的是“活没活”性能层看的是“快不快”到质量层就轮到“准不准”。很多时候本地模型跑着跑着性能指标一切正常生成速度飞快但回答内容完全不能看。语法层面的异常是最容易识别也最需要第一时间处理的。常见的语法异常有四种。第一种是乱码比如输出一堆空方块、unk标记或者莫名其妙的十六进制字符这种通常跟分词器加载异常相关。第二种是无限重复模型可能一直在“好的好的好的”或者反复回显prompt本身这类问题经常出现在显存不足强行裁剪上下文之后模型的状态已经错乱。第三种是回答戛然而止生成到一半突然结束表面上像是正常完成实际上可能是max_tokens触底或者eos_token被错误触发。第四种是输出内容和输入语言不对应比如中文prompt返回英文长篇这种常见于system prompt模板被干扰。处理语法异常的关键是“先记录后复现”。把出现异常的那一次完整请求保存下来用同样的参数重新跑一次。如果复现不了说明是偶发状态问题如果稳定复现说明是模型加载或者模板层面的固定问题。4.2 语义层检查上下文连贯性、逻辑闭环和自洽性语义层检查比语法层更难因为没有一个明确的对错标尺。但依然有几个可以重点观察的维度。第一个是上下文连贯性请模型基于前面已给的三条信息进行总结然后看它是否真的引用了这三条还是自顾自地乱编。第二个是逻辑闭环让模型完成一个“先分析、再决策、最后给出行动步骤”的任务看输出是否真的形成了完整链条有没有前文说一套、后文又否认前文的问题。有同学会问这些判断靠人肉看不就完了确实小规模检查可以人肉看。但如果有发布需求我更建议做一个小的固定评测集准备30到50条覆盖你实际业务场景的问答定期跑一遍把结果存下来用简单的字符串规则加人工抽检来判断质量漂移。我自己就受过一次教训某天做人工抽检时发现回答质量没问题但拿固定评测集一跑发现涉及长文本代码生成的场景分数掉了将近40%。原因其实只是某个配置文件里参数被意外改掉这种质量退化光靠随机抽几个问题根本看不出来。4.3 定量评估用PPL、评测集和模型打分辅助判断除了人工看还有几个定量工具可以用。困惑度PPL是最传统的一个指标可以简单理解为模型对输出内容的“惊讶程度”。PPL越低说明模型输出越符合它的训练分布。很多推理框架内置的perplexity工具可以用来判定输出有没有偏离正常分布但只能作为辅助因为PPL对生成型任务来说并不是万能的。更实用的是“固定评测集开源评估工具”的组合。准备一批标准题让模型回答然后通过字符串匹配、关键词命中、或者用另一个更可靠的模型给输出打分最后汇总成平均分。这个平均分的变化趋势比任何单次人肉检查都更能反映模型健康度。这类LLM-as-judge的方式有一定争议因为它依赖打分模型自身质量。但作为“判断本地模型是否正常运行”的一种相对手段它已经足够了。我日常的做法是不单独依赖某一种指标而是三类指标同时看语法异常数、评测集平均分、生成速率偏差。三者中有两项出现退化就立刻把模型拉回低负载状态排查。5. 长时运行稳定性部署一晚上之后才是真正考验5.1 显存泄漏的验证办法和常见成因本地模型部署完第一天的状态通常都不错真正暴露问题的是连续跑几小时甚至几天之后。显存泄漏是长时运行中最常见的慢性病也是最难定位的问题之一。验证显存泄漏不需要复杂工具记录数据看趋势即可。步骤如下启动模型后记录一次初始显存占用之后每隔一段时间比如10轮对话后记录一次持续观察累计10组数据点。如果显存占用随着对话轮次稳定上涨且不会回落到初始值基本可以确定有泄漏。常见成因通常集中在三个地方。第一是KV cache的管理问题某些框架在context窗口内动态分配KV cache但释放逻辑写得不够干净导致每轮对话都残留一部分显存。第二是连续请求间的前后状态没清理干净推理引擎内部积累了中间张量。第三是显存碎片化Python侧缓存或者CUDA缓存策略导致大量小碎片无法复用每次新请求又重新申请逻辑上的“新内存”。遇到碎片化问题的时候重启进程通常最立竿见影但治标不治本还是要看框架版本的更新日志。5.2 内存与CPU异常增长容易被忽略的“隐形杀手”显存是大家都会盯的但内存和CPU的异常增长往往被忽略。本地模型部署时很多依赖库会在推理过程中逐步积累缓存比如日志缓冲、tokenizer缓存、中间结果缓存。如果内存持续上涨最终会触发OOM killer把进程杀掉。这个现象最隐蔽的地方在于表面看是进程消失了实际根因却是内存泄漏积累到临界点。我的检查经验是看进程的RSS变化。使用ps -o pid,rss,vsz,comm -p PID或者top里的RES列观察进程的常驻内存。长期运行的服务内存会有一个相对稳定的平台期如果出现持续增长的爬坡就说明一定有什么东西在悄悄积攒状态。CPU异常增长也需要留意正常推理时CPU占用会随请求波动但如果没有任何请求时CPU占用率依然居高不下大概率是有后台任务在空转轮询比如某些监控线程写得不够优雅。5.3 磁盘和日志增长存储被慢慢“吃掉”也是一种宕机长时运行还有一个容易被忽略的检查项磁盘。很多本地推理服务会把历史请求、生成结果或者日志完全记录下来。如果没有做日志滚动和清理策略几周后磁盘被日志占满是再常见不过的事。磁盘满了之后的表现非常多样可能是模型缓存写入失败、可能是服务启动到一半卡死、也可能直接表现为API接口迟迟不返回。检查方法很简单df -h看磁盘使用率du -sh logs/看具体目录体积。如果发现日志目录以每天几百MB的速度增长就一定要配置日志轮转比如保留最近N天或者按大小切割。这个属于典型的“平时毫无存在感、关键时刻一击致命”的问题。还有一个更隐蔽的场景某些模型框架会把prompt缓存或embedding缓存写入用户目录下的隐藏文件夹磁盘突然爆满时会更容易定位到~/.cache下面。所以排查磁盘问题时别只盯着项目目录用户目录和临时目录也要一并检查。6. 一次完整排查实录一个“半正常”状态的定位全程6.1 现象描述和开头那个案例类似的情况有次某开发者找到我说他的本地模型服务“能跑但很怪”。具体表现是模型刚启动的第一小时一切正常回答速度快、内容也准但跑了大半天之后回答越来越慢而且内容开始变短有些问题只回一两句话就停住了。用ps看进程进程在用curl探活接口也能通看nvidia-smi显存占用高但没有报错。这是个非常典型的“系统层全绿、但实际体验不下去”的状态。我上去之后没有直接改配置而是先做了一次完整的信息归档。拉取了当前显存占用、进程内存、日志的最后100行、以及一个标准测试prompt的响应时间。这几个数据必须同时看因为只有对照数据才能确定“异常发生在哪一层”。6.2 排查过程从性能指标逆推到资源泄漏我先跑了一个固定测试prompt记录到两个关键数据首token延迟还在正常范围但生成速率掉到了模型刚部署时的四分之一左右。这个数据组合很说明问题总耗时高的部分是生成阶段而不是预填充阶段所以问题大概率不在输入处理和显存加载上。我接着做显存趋势记录每跑一轮长对话就记录一次显存占用连续跑了5轮后显存从初始的9.2GB涨到了11.8GB而且没有再回落。到这里基本锁定显存持续增长的问题。进一步看日志里没有显存不足的报错但CPU占用率在请求间隙一直维持在一个异常高度说明有大量的缓存清理和重分配逻辑在后台运行。整个定位过程用了不到二十分钟。最终结论是框架的缓存策略在长上下文场景下没有及时释放KV cache导致每轮对话都在增加额外显存负担进而拖慢了后续生成速度。6.3 问题解决和复盘这个案例带来的经验解决方式看起来不值一提重启进程回到基线状态。但这里有一个关键经验重启只是缓解如果每天都要重启说明框架层面的资源管理没做好。后面我查了所在开源社区的相关讨论确认这个问题是某个版本的已知行为升级到修复版本之后连续运行三天没有再出现明显显存增长。复盘下来最有价值的教训是对本地模型做健康检查不能只停留在“有没有报错”的层面要把性能指标的趋势和资源占用的趋势一起记录。单个时间点的快照只能发现问题是否已经发生趋势对比才能判断问题正在朝什么方向发展。现在我做状态评估时一定先建基线、再定期重测、最后拿趋势说话这个习惯帮我避开了很多隐性故障。7. 高频问题自查速查表与自动化检查方案7.1 常见异常现象速查表为了方便日常排查我把最常见的异常表现整理成了一张速查表。遇到问题先对号入座再决定深入排查的方向比盲目翻日志高效得多。异常表现可能原因优先排查动作API请求全部超时推理线程卡死或请求队列堆积看日志尾部有无长耗时记录发max_tokens1的探活请求进程存在但接口拒绝连接服务崩溃后未退出或端口被占用确认监听端口是否变化检查是否有第二个实例抢占端口首token延迟突然变高输入prompt变长或预填充阶段变慢对比相同长度prompt的历史耗时查看是否有并发排队生成速率明显下降KV cache管理问题或显存碎片化记录显存趋势检查并发请求数考虑重启后观察回答内容开始无限重复上下文处理异常或参数量化精度问题用相同prompt固定参数复现检查是否触发了长上下文裁剪输出出现大量乱码分词器加载异常或采样参数异常查看当前加载的模型路径是否正确检查tokenizer配置显存伴随对话轮次持续增长显存泄漏或缓存释放不及时每10轮对话记录显存观察是否回落测试修复版本无请求时CPU占用仍然很高后台监控线程空转或缓存清理线程用htop查看线程级CPU分布确认具体哪个线程在消耗7.2 一张可复制的自动化健康检查脚本如果每次都手动跑一遍上文的检查很麻烦可以用一个简单的bash脚本把这些检查整合起来。脚本要做的事情很明确检查进程存在、检查端口监听、发起一个轻量探活请求、记录GPU占用情况和日志尾部。不需要做得很复杂定时跑一次把输出集中到一个文件里就够了。#!/usr/bin/env bash SERVICE_PORT8080 PROCESS_KEYWORDmodel_server HEALTH_FILE/var/log/model_health.log echo $(date %Y-%m-%d %H:%M:%S) $HEALTH_FILE if pgrep -f $PROCESS_KEYWORD /dev/null then echo [OK] 进程存在 $HEALTH_FILE else echo [FAIL] 进程不存在 $HEALTH_FILE fi if netstat -tln | grep -q :$SERVICE_PORT then echo [OK] 端口 $SERVICE_PORT 正常监听 $HEALTH_FILE else echo [FAIL] 端口 $SERVICE_PORT 未监听 $HEALTH_FILE fi curl -s -m 10 -o /dev/null -X POST http://127.0.0.1:$SERVICE_PORT/v1/chat/completions \ -H Content-Type: application/json \ -d {prompt: ping, max_tokens: 1} \ -w 探活耗时: %{time_total}s\n $HEALTH_FILE nvidia-smi --query-gpumemory.used,memory.total,utilization.gpu --formatcsv $HEALTH_FILE脚本输出追加到同一个日志文件第二天起来看一遍cat /var/log/model_health.log | tail -n 30基本就能判断昨晚服务状态有没有波动。如果追求更细致的性能记录也可以把脚本换成python版本把TTFT和生成速率也一并算进去本质思路是一样的。7.3 再加一道保险用监控面板看趋势脚本适合按需跑但长时趋势更推荐交给监控面板。选一个顺手的面板工具把GPU利用率、显存占用、内存占用、请求耗时、日志错误数都挂上去。这样不用手动记录也能轻松看到“最近三天显存是不是在爬坡”“请求耗时有没有异常尖峰”。这里给一个实操建议监控面板不要只看平均值要看趋势和峰值。平均值很容易掩盖偶发的尖峰问题。像首token延迟这种指标如果P95和P99相差非常大说明一部分请求已经被卡了很长时间整体体验其实已经很差了。看面板的习惯应该是“先看趋势再看异常点最后看对应的具体时间段的日志”。我个人在实际排查里最大的体会是判断本地模型是否正常运行其实是被动排查和主动体检的集合。很多人是在“出事了”之后才开始翻数据但更省事的做法是部署当天就建好基线然后定期把性能趋势和资源趋势拉出来看一眼。真正难的不是看懂数据而是坚持把数据记下来。别等模型变傻了才想起来它以前是什么样子只要手上有基线任何指标漂移都会第一时间暴露在你面前。