mirror of
https://github.com/deepseek-ai/DeepGEMM.git
synced 2026-11-05 00:47:26 +00:00
[GH-ISSUE #301] [Bug] JIT cache lacks cross-process synchronization, can cause failures under multi-process parallelism #151
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
deepseek-ai/DeepGEMM#151
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Gregory-Pereira on GitHub (Apr 11, 2026).
Original GitHub issue: https://github.com/deepseek-ai/DeepGEMM/issues/301
Description
Compiler::build()incsrc/jit/compiler.hppdoes not synchronize across processes. When multiple processes target the same kernel (same signature hash, same cache directory), they can race on writing and readingkernel.cuandkernel.cubin, potentially causing:CUDA driver error: 301 (CUDA_ERROR_FILE_NOT_FOUND, file not found)NVCC compilation failed: cc1plus: fatal error: .../kernel.cu: No such file or directoryThis was observed downstream in vllm-project/vllm#39057, where a user running DeepSeek-V3.2 with
-dp 8 --enable-expert-parallel(8x H200, cache on a network filesystem) hit both errors during startup. The lack of locking inbuild()is a plausible explanation and seems worth fixing regardless.cc @jxdn
Initial code analysis
Multiple processes with the same kernel signature will compute the same
dir_path:With no locking, im guessing the following can happen concurrently:
make_dirs(dir_path)and entercompile()put(code_path, code)which atomically renames a temp file todir_path/kernel.cu— one process's write replaces the other'sNVCCCompiler, NVCC is invoked as an external subprocess that readskernel.cufrom disk (line 214). If another process replaces or is mid-replace of that file, NVCC can fail with "file not found"rename(tmp_cubin, kernel.cubin)NVRTCCompilercompiles from an in-memory string so it avoids thekernel.curead race, but still shares the cubin output path.What isnt verified
~~ - I haven't reproduced this in a controlled test — the downstream report is the only data point~~ I was able to verify this last night
/hpfs/...) could be a contributing factor (e.g. NFS caching behavior), independent of the race- A corrupted or stale cache from a prior run could also produce similar errorsAccounted for in my test / setup in #302Environment (from the downstream report)
477618c(pinned by vLLM)/hpfs/...)Suggested fix
Add a per-kernel file lock (
flock()) around the compilation step inbuild()with a double-checked locking pattern:This would have zero overhead during steady-state inference (the in-process cache returns before reaching the lock) and only serializes compilation of the same kernel across processes — different kernels still compile in parallel.
Will try to reproduce and create a fix.
@Gregory-Pereira commented on GitHub (Apr 11, 2026):
I was able to verify this in my process of testing 302, also got:
Also I was able to account for purging the cache, see comments in #302