Open IcyFeather233 opened 4 months ago
infer阶段VLLM使用很正常,但是eval阶段就会卡住了,模型本身的推理也没有问题
如果不使用VLLM,在eval阶段使用HuggingFace也没有问题
另外,CritiqueLLM 已经开源,CritiqueLLM 是Alignbench论文作者自己训练的替代gpt4来评测的模型,https://github.com/thu-coai/CritiqueLLM ,希望 OpenCompass 可以把这个模型更新到 AlignBench 中
感谢您的建议,我们会尽快测试该模型并支持,正常的话eval阶段vllm也是没问题的,你可以试下用其他模型在eval阶段用vllm推理,可能是这个模型跟OpenCompass的vllm不适配,我们这边也会尽快验证这个事情。
@liushz 谢谢回复,经过我的测试,很多模型在eval阶段都无法使用vllm推理,我试过Qwen也不行
有些奇怪,eval起model的逻辑应该是和infer过程一样的,Qwen用vllm的时候是什么样的报错呢
此外critiquellm看起来也是hf格式的,直接用现有的config使用起来会遇到什么问题吗
有些奇怪,eval起model的逻辑应该是和infer过程一样的,Qwen用vllm的时候是什么样的报错呢
一样的,也是卡住不动了
此外critiquellm看起来也是hf格式的,直接用现有的config使用起来会遇到什么问题吗
hf用起来没有问题,缺点就是慢,所以我想用vllm试试
你vllm的版本是多少
你vllm的版本是多少
0.4.2
问题应该出现在 https://github.com/open-compass/opencompass/blob/edab1c07baaebe3e6b6b48983d56656f6c93fd76/opencompass/models/vllm_with_tf_above_v4_33.py#L64, 但应该是VLLM自身有奇奇怪怪的问题,参考https://github.com/vllm-project/vllm/issues/4974
我也是,主观评测时用vllm在eval阶段卡住了,报错以下信息:
08/27 15:25:57 - OpenCompass - INFO - No postprocessor found. INFO 08-27 15:25:58 config.py:729] Defaulting to use mp for distributed inference INFO 08-27 15:25:58 llm_engine.py:174] Initializing an LLM engine (v0.5.4) with config: model='Qwen/Qwen2-1.5B-Instruct', speculative_config=None, tokenizer='Qwen/Qwen2-1.5B-Instruct', skip_tokenizer_init=False, tokenizer_mode=auto, revision=None, rope_scaling=None, rope_theta=None, tokenizer_revision=None, trust_remote_code=True, dtype=torch.bfloat16, max_seq_len=32768, download_dir=None, load_format=LoadFormat.AUTO, tensor_parallel_size=4, pipeline_parallel_size=1, disable_custom_all_reduce=False, quantization=None, enforce_eager=False, kv_cache_dtype=auto, quantization_param_path=None, device_config=cuda, decoding_config=DecodingConfig(guided_decoding_backend='outlines'), observability_config=ObservabilityConfig(otlp_traces_endpoint=None), seed=0, served_model_name=Qwen/Qwen2-1.5B-Instruct, use_v2_block_manager=False, enable_prefix_caching=False) WARNING 08-27 15:25:59 multiproc_gpu_executor.py:59] Reducing Torch parallelism from 64 threads to 1 to avoid unnecessary CPU contention. Set OMP_NUM_THREADS in the external environment to tune this value as needed. INFO 08-27 15:25:59 custom_cache_manager.py:17] Setting Triton cache manager to: vllm.triton_utils.custom_cache_manager:CustomCacheManager [1;36m(VllmWorkerProcess pid=578709)[0;0m INFO 08-27 15:26:02 multiproc_worker_utils.py:215] Worker ready; awaiting tasks [1;36m(VllmWorkerProcess pid=578708)[0;0m INFO 08-27 15:26:02 multiproc_worker_utils.py:215] Worker ready; awaiting tasks [1;36m(VllmWorkerProcess pid=578707)[0;0m INFO 08-27 15:26:02 multiproc_worker_utils.py:215] Worker ready; awaiting tasks [E827 15:35:58.511112511 socket.cpp:957] [c10d] The client socket has timed out after 600s while trying to connect to (127.0.0.1, 35639). Traceback (most recent call last): xxxxxxxxxxx torch.distributed.DistNetworkError: The client socket has timed out after 600s while trying to connect to (127.0.0.1, 35639). ERROR 08-27 15:35:59 multiproc_worker_utils.py:120] Worker VllmWorkerProcess pid 578709 died, exit code: -15 INFO 08-27 15:35:59 multiproc_worker_utils.py:123] Killing local vLLM worker processes E0827 15:36:00.383000 140006882236224 torch/distributed/elastic/multiprocessing/api.py:833] failed (exitcode: 1) local_rank: 0 (pid: 578492) of binary: /xxx/anaconda3/envs/xxx/bin/python Traceback (most recent call last):
请问有解决方法么? eval阶段用hf没问题,但是太慢了。
@tonysy
qwen能用lmdeploy, lmdeploy不会卡的
qwen能用lmdeploy, lmdeploy不会卡的
试了下可以的,多谢 还是期待官方能修复下vllm的问题,业务线上用的vllm
从文档看加速比和精度还是有点差异
qwen能用lmdeploy, lmdeploy不会卡的
更正下:我在llama3.1, mistral02上测试没问题,但在Qwen2上报错了:
[TM][INFO] NCCL group_id = 0 [WARNING] gemm_config.in is not found; using default GEMM algo [TM][INFO] NCCL group_id = 0 E0827 22:46:43.539000 140671864051520 torch/distributed/elastic/multiprocessing/api.py:826] failed (exitcode: -8) local_rank: 0 (pid: 942435) of binary: xxx/anaconda3/envs/llm_eval/bin/python Traceback (most recent call last):
+1 我也是测align_bench无法用vllm的qwen2.5作为judge卡住了 手动ctrl+C显示是with ThreadPoolExecutor()那里卡住了
不太清楚该怎么解决
+1 我也是测align_bench无法用vllm的qwen2.5作为judge卡住了 手动ctrl+C显示是with ThreadPoolExecutor()那里卡住了
不太清楚该怎么解决
先用lmdeploy或者用vllm部署成API吧(vllm部署成API也比较简单就一行代码启动),local模型的vllm涉及的bug比较深,还在找原因
先决条件
问题类型
我正在使用官方支持的任务/模型/数据集进行评估。
环境
重现问题 - 代码/配置示例
config 文件:
重现问题 - 命令或脚本
重现问题 - 错误信息
第一次报错了,第二次我使用
-m eval -r xxx
复用之前的 prediction 结果,单独运行 eval 还是报下面的错其他信息
No response