A high-throughput and memory-efficient inference and serving engine for LLMs
Mirrored from https://github.com/tduncan-lum/Nvidia-Optimization-Stack---VLLM.git
Synced Nov 14, 05:30 UTC
[Bugfix][Hardware][RISC-V] Limit supported dtypes to float32 to avoid scheduler segfault (#26228)
Signed-off-by: lyd1992 <liuyudong@iscas.ac.cn> Signed-off-by: ihb2032 <1355790728@qq.com>
ihb2032 committed
Oct 5, 2025 at 18:36 UTC
3303cfb4ac11256050b0eb312482591e3a9f75d8
1 file changed
+25
vllm/platforms/cpu.py
+25
@@ -84,6 +84,31 @@ class CpuPlatform(Platform):
84
shell=True).strip() == b"1"):
85
return [torch.bfloat16, torch.float16, torch.float32]
86
return [torch.float16, torch.float32]
87
+ elif self.get_cpu_architecture() == CpuArchEnum.RISCV:
88
+ # Workaround for Issue #25655: RISC-V scheduler bug with float16
89
+ #
90
+ # Background:
91
+ # - RISC-V currently uses scalar code path
92
+ # - There is a latent bug in the vLLM scheduler that provides
93
+ # invalid
94
+ # physical_block_idx values under certain conditions
95
+ # - This bug causes segmentation faults when using float16
96
+ # dtype on RISC-V
97
+ # - Testing shows that forcing float32 successfully bypasses
98
+ # this issue
99
+ #
100
+ # Technical details:
101
+ # - The bug manifests as out-of-bounds physical_block_idx in
102
+ # block_tables
103
+ # - Only occurs on RISC-V hardware
104
+ # tested on Sophgo SG2044
105
+ # - Does not reproduce on x86 or other architectures
106
+ # - Root cause is in Python-level scheduling logic,
107
+ # not C++ kernels
108
+ #
109
+ # This is a temporary workaround until the scheduler bug is fixed.
110
+ # See: https://github.com/vllm-project/vllm/issues/25655
111
+ return [torch.float32]
112
# x86/aarch64 CPU has supported both bf16 and fp16 natively.
113
return [torch.bfloat16, torch.float16, torch.float32]
114