实例故障

故障现象及原因

表1
故障现象	故障原因
请求响应延迟显著上升（可达正常值的数倍）	客户端请求频率过高，超出实例处理能力大量请求处于 Pending 状态，排队等待处理
请求错误码 5xx > 10%	大量长输入请求导致模型推理占用大量显存 KV Cache 资源耗尽，新请求无法分配内存
请求错误码 5xx = 100%	进程因死锁、内存溢出等原因进入挂起状态
偶发请求错误码 5xx	按照处理方法排查定位失败原因
偶发请求出现TTFT，TPOT突增	按照处理方法排查定位失败原因

处理方法

为确保业务连续性并尽快恢复服务，建议您调整 RPM 流控策略，限制请求数量，同时执行以下操作重启异常实例：以下给一个示例按照步骤来定位到对应的pod节点上

先调下接口查看是否有错误信息，错误信息中包含id，可以根据id关键信息在日志中查找，如下图返回体中有id：chatcmpl-63323863626663362d323635352d3438
然后执行以下命令查看下pod的状态和名称，proxy的日志在PD分离的场景下是默认放在role-0的节点上，所以先确认所有的role-0节点，有几个instance实例就会有几个role-0节点
```
kubectl get pods -o wide | grep vllm
```
根据role-0所在的节点名称到这个节点里面的日志目录下去查看proxy日志，日志目录地址可以看--vllm-log-path这个参数设置的值，根据步骤一中返回的id进行搜索，然后根据instance实例名称进到对应的文件夹中，需要注意的是如果是多个instance，也就是步骤2中有多个role-0节点，那么要到每个role-0节点的日志目录中的proxy.log查找日志。
```
grep -i "chatcmpl-63323863626663362d323635352d3438" proxy.log
```
查看日志中的prefill和decode，可以看到里面有发送到具体节点上的请求URL，看日志中是哪一个发送请求报错，或者没有内容返回，那么就根据拿到的这个IP地址去查找下对应的pod，然后看这个pod的日志，上图中可以看到x.x.x.156是prefill节点，x.x.x.155是decode节点，根据步骤2中的命令可以知道是哪一个pod，然后用下面的命令查看下当前pod的日志信息，当然确认节点已经不是Running状态了就无需看日志，直接做摘流即可。
```
kubectl logs -f ${POD_NAME}
```
确认有问题的pod后，可以根据pod的前缀部分查看是哪个instance出现了问题，可以用下面命令确认出现问题的instance
```
kubectl get instance | grep infer-vllm-1p1d-bct4e
```
根据多实例推理服务手动摘流指导将该实例从服务负载均衡中摘流，确认没有新的请求进入该实例，并且已经进入的请求全部处理完毕。
执行以下命令查看摘流后的实例名称，状态为Concerning。
```
kubectl get instance
```
执行以下命令删除异常实例，删除后会重新拉起一个新的实例。
```
kubectl delete instance ${INSTANCE_NAME}
```