3月11日更新：

1. 对于问题1，感谢评论区老师的解答，已经可以通过如下方法解决：

   使用 image.sourcefind.cn:5000/dcu/admin/base/custom:vllm0.5.0-dtk24.04.1-ubuntu20.04-py310-20250225 这个容器，并且在vllm运行时加上参数  --dtype float16 。如此可成功运行DeepSeek-R1-Distill的各种版本，性能比原使用naive版flash attention以及3月6日更新使用triton版flash attention要高不少，4xK100运行70B版DeepSeek可以从原来的generation 2~3 token/s提高到大约7 token/s以上，已经到了可以日常使用的性能了。

3月6日更新：

1. 对于问题2和问题3，目前再次用了一个比较投机取巧的方案解决了：

   1. 若使用vllm==0.5版的容器，可以使用以下命令：

      sed -i "s/return 3/return 0/g" \
          /usr/local/lib/python3.10/site-packages/triton/third_party/hip/hip_backend.py
      

   2. 若使用vllm为更高版本的容器，可以使用以下命令：

      sed -i "s/pm, options.arch, options.matrix_instr_nonkdim/pm, \"gfx906\", options.matrix_instr_nonkdim/g" \
          /usr/local/lib/python3.10/site-packages/triton/backends/amd/compiler.py
      

      这个方法的思路是，先调研了一下报错的指令，例如 amdgcn.mmac  ，以及从triton的GitHub站上查了对应源码中检测那个 ver  变量的代码，大致确定报错的原因和AMD版的TensorCore（AMD的WMMA Layout之类的东西）有关，之后又根据Triton的工作流程，定位到问题发生在Triton IR -> Triton GPUIR的步骤里。回想之前处理问题1的办法，想着在Triton这里是不是也可以用类似的思路，强制让它生成更低版本的GPUIR来绕过。于是在容器中Python site-packages的Triton目录里找了一下py文件，诶🤓☝️还真能做类似的屏蔽，于是就有了上面的解决方案。

   3. 上述两个方案还顺带处理了问题一中使用naive版flash attention的弊端：vllm的 --gpu-memory-utilization  会失效，控制不住GPU VRAM的占用，比如部署DeepSeek R1 Distill Qwen 32B的时候，上下文设置到128k，此时看着VRAM的占用并没有很高，但是一旦给一个较长的输入，比如结合RAG放一篇文献进去，输入token到大约7~8万，不管 --gpu-memory-utilization  设置的是多少，VRAM会立刻填满然后报OOM，vllm服务也会因此终止退出。而把naive版flash attention换成triton flash attention之后（运行的时候设置环境变量   export VLLM_USE_TRITON_FLASH_ATTN=True  ），目前没有碰到过这样的问题了，测试了一下输入的token到9万也能正常运行。

   4. 不过遗憾的是，这种方法启用的Triton flash attention，总体的generation throughput并没有比naive flash attention快多少。

遇到的问题：

1. flash_attn的问题。常规的docker镜像在K100上运行推理时，会在flash_attn包的flash_attn_cuda.varlen_fwd函数出现

   HIP error: invalid device function
   

   详见 https://forum.sourcefind.cn/thread/877 和 https://forum.sourcefind.cn/thread/855 。如果使用 https://forum.sourcefind.cn/thread/515 的flash_attn包替换镜像中的flash_attn，能够正常启动vllm但是运行模型时会胡言乱语，可能是tokenizer或者BOS之类的问题？没有进一步测试了。临时解决方案是强制vllm用naive版的flash attention，但是推理的性能不是很高。

2. Triton的问题。在用上述临时方案解决R1的问题后，尝试部署DeepSeek Coder V2 Lite Instruct。会遇到：

   LLVM ERROR: Cannot select: intrinsic %llvm.amdgcn.mmac.f32.16x16x16bf16
   

   例如在 https://forum.sourcefind.cn/thread/877 的 image.sourcefind.cn:5000/dcu/admin/base/custom:vllm0.5.0-dtk24.04.1-ubuntu20.04-py310-zk-v1 镜像中可以复现，设置环境变量    export VLLM_LOGGING_LEVEL=DEBUG  输出debug可以注意到此时调用的flash attention时triton的（Using Triton FA in ROCmBackend），不过即使在 rocm_flash_attn.py  中进一步设定    self.use_triton_flash_attn = False  确保vllm一定会用naive版的flash attention（Debug的输出中确认有Using naive attention in ROCmBackend），也会有一样的问题。该问题似乎和DTK包中带的LLVM有关。

3. 依然是Triton的问题。，是在使用 https://forum.sourcefind.cn/thread/855 中提到的pytorch2.4.1-ubuntu22.04-dtk25.04-rc4-vllm0.6.6-py3.10.tar.gz 镜像中遇到的，此时同样是部署R1没有问题、部署Coder V2 Lite Instruct会遇到问题：

   /data/jenkins_workspace/workspace/triton@4/lib/Dialect/TritonGPU/IR/LinearLayoutConversions.cpp:627: std::optional<mlir::LinearLayout> mlir::toLinearLayout(llvm::ArrayRef<long int>) const: Assertion `ver == 1 || ver == 2' failed.
   

   大致追查到可能是triton对vllm的fused_moe进行 @triton.jit 的时候发生的，似乎也和DTK包中带的LLVM有关。

目前进行的尝试：

除了上文提到的内容，我在网上搜索了一下，找到了这两个仓库：

https://github.com/Said-Akbar/vllm-rocm

https://github.com/Said-Akbar/triton-gcn5

看了一下这个仓库中的 lib/Dialect/TritonGPU/IR/LinearLayoutConversions.cpp  ，似乎是有希望解决第二个和第三个Triton相关的问题的，不过在编译安装该仓库的triton-gcn5的时候，发现需要MLIR模块，看了一下 /opt/dtk/llvm/lib/cmake  中的内容发现DTK的LLVM确实没有MLIR相关的文件。能否提供包含MLIR的DTK，或者能否帮忙测试一下上述两个仓库是否能够真正比较完美地解决K100部署DeepSeek的问题？