网上做兼职网站正规做结构设计有没有自学的网站
背景介绍
- 硬件
A800 80G - 模型
chat-glm4-9b-128K - 环境
生产 - 正常显存占用情况
glm4 占用32GB
其他显存工占用38GB左右
总共剩余10GB。
问题描述
推理时报错日志，由于内网环境无法拿出日志，与下面的类似。
File "/data/miniconda3_new/envs/vllm-new/lib/python3.10/site-packages/vllm/engine/async_llm_engine.py", line 654, in add_requestself.start_background_loop()File "/data/miniconda3_new/envs/vllm-new/lib/python3.10/site-packages/vllm/engine/async_llm_engine.py", line 476, in start_background_loopraise AsyncEngineDeadError(
vllm.engine.async_llm_engine.AsyncEngineDeadError: Background loop has errored already.
再往前追述日志，发现有超长文本请求，字符长度10万左右，显存不够报类似如下错误
torch.cuda.OutOfMemoryError: CUDA out of memory. Tried to allocate 10.78 GiB
问题分析
根本原因还是显存不够，但是一个请求推理显存不够后这个请求失败应该释放调占用的显存，不应该影响之后的请求才对。
引擎启动代码如下：
if __name__ == "__main__":MODEL_PATH = sys.argv[1]tokenizer = AutoTokenizer.from_pretrained(MODEL_PATH, trust_remote_code=True)engine_args = AsyncEngineArgs(model=MODEL_PATH,tokenizer=MODEL_PATH,# 如果你有多张显卡，可以在这里设置成你的显卡数量tensor_parallel_size=1,dtype="bfloat16",#dtype="half",trust_remote_code=True,# 占用显存的比例，请根据你的显卡显存大小设置合适的值，例如，如果你的显卡有80G，您只想使用24G，请按照24/80=0.3设置gpu_memory_utilization=0.4,enforce_eager=True,worker_use_ray=False,disable_log_requests=True,max_model_len=MAX_MODEL_LENGTH, # 这里是128000)engine = AsyncLLMEngine.from_engine_args(engine_args)uvicorn.run(app, host='0.0.0.0', port=8000, workers=1)
引擎调用部分代码如下：
sampling_params = SamplingParams(**params_dict)
try:async for output in engine.generate(inputs=inputs, sampling_params=sampling_params, request_id=f"{time.time()}"):output_len = len(output.outputs[0].token_ids)input_len = len(output.prompt_token_ids)ret = {"text": output.outputs[0].text,"usage": {"prompt_tokens": input_len,"completion_tokens": output_len,"total_tokens": output_len + input_len},"finish_reason": output.outputs[0].finish_reason,}yield ret
except Exception as e:logger.error(f"错误:{e}")raise e
finally:gc.collect()torch.cuda.empty_cache()
- 引擎崩溃后每次也是这里的logger.error输出的Background loop has errored already.
- 第一次内存不够报错日志也是这里有显示，并且有调用finally模块中的清空缓存逻辑。
- 还是重复上面的问题，一个请求不应该导致整个引擎崩溃，从而导致之后的请求也无法处理，不知道是否是vllm的bug？？？ 看到能多人也在github上提了issue，但是目前无解决方案。参考：
https://github.com/vllm-project/vllm/issues/6361
解决方案
经过上面的分析我们知道是显存不够引起的，我们这里只对显存不够做调优来减少这种情况发生，并不能解决显存不够后引发的引擎崩溃问题。
做如下参数调整
- enable-chunked-prefill = True
- max_num_batched_tokens = 8192
- max_num_seqs = 10
参数介绍
enable-chunked-prefill
- 是 vLLM 中的一个优化功能，主要用于处理长上下文或大提示(prompt)情况下的内存和计算效率问题。默认False
max_num_batched_tokens
预填充阶段的最大批处理token数：
-
当 enable-chunked-prefill=True 时，决定每个chunk(块)的最大token数
-
解码阶段的最大批处理token数：限制解码阶段同时处理的token总数
-
工作原理
当启用 chunked prefill 时：
系统将长prompt分割为多个chunk
每个chunk的token数不超过 max_num_batched_tokens
依次处理这些chunk
例如：
如果prompt有5000 tokens，max_num_batched_tokens=2048
将被分割为：2048 + 2048 + 904 tokens的三个chunk -
默认值
不同的显卡，不同的内存默认值不一样
详细逻辑见官方代码：https://github.com/vllm-project/vllm/blob/main/vllm/engine/arg_utils.py -
建议
高端GPU(如A100 80GB)：可设较大值(4096-8192)
消费级GPU(如3090 24GB)：建议较小值(1024-2048)
max_num_seqs
控制并发数量，如果你的显存不够是由于并发引起的，可以设置这个参数。
其他参数：
- max_model_len ： 允许模型处理的最大token数量，可根据实际情况限制，由于我们就是要处理长文本的，所以我这里没有调整。
- gpu_memory_utilization GPU显存占比，尽量初始化时小一点，预留足够的显存空间。
总结
经测试以上参数调整后可以显著控制GPU的占用情况，减少OutOfMemory情况的发生，提高系统可用性，后续也会尝试升级VLLM版来解决崩溃后无法处理后续请求的问题，但是显存都是稀缺资源，本身也要做好调优。