01 · 适配当 A800 遇上按 FP8/FP4 打包的权重A800SM80 / Ampere有 BF16 和 INT8 Tensor Core没有 FP8 / FP4而模型权重是 fp8 e4m3 block 量化 MoE experts MXFP4 打包。两者之间不存在任何一条原生可执行的算子链我们尝试把整条数据路径重规划到 SM80 真实存在的算子上。文章目录01 · 适配当 A800 遇上按 FP8/FP4 打包的权重零 开源项目地址一 两个约束撞在一起二 重规划每一段都换成 SM80 真有的算子三 注入sitecustomize PYTHONPATH 契约四 视觉一层独立的改动面五 四条不能碰的红线六 为什么不选另一条路七 适配之后实测足迹八 适配的边界哪些东西补不了九 这次适配的形状小结零 开源项目地址gitee开源仓库地址dsv4-vision-exp-sglang-sm80一 两个约束撞在一起先把事实摆在一起后面所有的选型都是这一节的推论。一侧事实后果硬件4 × A800 80GBSM80compute capability 8.0BF16 / INT8 Tensor Core 齐全没有 FP8 / FP4Hopper(SM90) / Blackwell 上的低比特性能路径在这里无处落地主权重普通线性层quant_methodfp8、fmte4m3、weight_block_size[128,128]、activation_schemedynamic、UE8M0 block scaletorch_dtypebfloat16原生实现会走 FP8 内核MoE expertsrouted expert 是 packedMXFP4E2M1 UE8M0 block scale原生实现会走 MXFP4 Marlin 内核模型结构architectures[DeepseekV4ForCausalLM]、model_typedeepseek_v4、43 层另有稀疏注意力、compressor、indexer 等专属结构ViT / Aligner 是 BF16加载器和算子都按 DSV4 专属语义工作拿通用 VLM 顶替不了上游实现SGLang 的 MXFP4 Marlin明确拒绝 SM80只允许 SM90 / SM120官方镜像直接起内核初始化阶段就失败关键判断官方数据路径里没有任何一条能在 SM80 上执行的低比特算子链。所以问题不是精度要不要降而是哪条路根本不存在。这就决定了解法形态不是调参是重规划。二 重规划每一段都换成 SM80 真有的算子补丁做的事情一句话说就是逐段换算子子路径原生SM90 / SM120SM80 补丁路径为什么普通线性层FP8block scaledBF16加载时反量化A800 的 BF16 算力是强项反量化/repack 是加载期 CPU 密集阶段MoE expertsMXFP4 MarlinINT8marlin WNA16MXFP4 权重重排后走 INT8 Tensor CoreSM80 原生支持KV cacheFP8 / 其它低比特BF16分页 KV与可见窗注意力配套Indexer cacheFP8INT8DSA indexer 的压缩 KV 走整数路径稀疏注意力新架构专属内核SM80 Triton kernelDSV4 的 DSA 稀疏注意力在 Ampere 上用 Triton 实现值得强调这不是统一降级将就而是把每一段路由到 A800 上最强的可用算子——普通层回 BF16专家层保住 INT8 Tensor Core。代价写在明面上加载期变重反量化 repack换来的是能跑。运行期开关在镜像入口固化exportENABLE_SGLANG_DSV4_A100_PATCH1exportSGLANG_DSV4_A100_INT8_INDEXER1exportSGLANG_DSV4_MXFP4_MOE_BACKENDmxfp4_int8小提醒SGLANG_DSV4_MXFP4_MOE_BACKENDmxfp4_int8和上表里的 “MoE experts → INT8 (marlin WNA16)” 是同一件事的两种叫法环境变量与内部参数名不要当成两套路径。三 注入sitecustomizePYTHONPATH契约补丁不 fork SGLang、不覆盖官方镜像而是靠 Python 启动时自动执行sitecustomize.py来注入 monkeypatch。容器内的PYTHONPATH三段顺序是一条固定契约顺序路径角色1/sgl-workspace/platform平台 overlay先应用 A100 补丁再装视觉相关 overlay2/sgl-workspace/sm80-patchSM80 补丁主体dsv4_a100_patch/patch.py3/sgl-workspace/sglang/pythonv0.5.16 源码树含视觉回移植覆盖三条性质值得记住官方基底一份不动构建前后各取一次 base 镜像的 Image ID 并断言一致变动即报错退出。可以整体关掉做对照ENABLE_SGLANG_DSV4_A100_PATCH0会让补丁空转、退回原生行为。这给了我们一个干净的二分法——用来区分补丁引入的问题和模型 / 请求本身的问题。原生路径在 A800 上预期失败这个失败本身就是选型的复现。失败是 fail-fast 的入口先跑兼容性检查sglang commit、可见 GPU 是否正好 4 张、compute capability 是否 8.0、architectures是否为DeepseekV4ForCausalLM、补丁是否生效再做模型路径与密钥检查。宁可起不来也不要带病服务。为什么用 monkeypatch 而不是改源码因为补丁替换的是内部接口模型层、KV pool、indexer、attention backend、JIT。SGLang 小版本一动这些接口就变。把版本钉死 运行期注入是这套方案里成本最低的可复现方式反过来这也意味着版本是红线。四 视觉一层独立的改动面DeepSeek-V4-Flash-Vision-Exp的 checkpoint 里有vision.* / aligner.* / image_*视觉张量而SGLang v0.5.16 完全没有 DSV4 视觉支持——模型注册里只有纯文本的DeepseekV4ForCausalLM加载必然KeyError: aligner.gate_up_proj.weight。所以视觉不是开个参数而是第二个独立改动面。我们按上游 PR #37253 的语义回移植到 v0.5.16落成四件事deepseek_v4_vl.pyVL wrapper单独装载视觉键只把文本键交给内层文本基座逐层bias_vl模态分叉的专家偏置路由image span 的 bidirectional visible-window 注意力对应的 mm processor。误解要纠正社区笔记里流传的纯文本 0731 → MXFP4/BF16 权重转换路径不适用于视觉版权重。 那个转换脚本是纯文本专用的跑在视觉版上会损坏视觉编码器张量。本部署不做任何权重转换直接使用官方原生 safetensors。五 四条不能碰的红线#红线原因1必须SGLang v0.5.16 commitfdebc938补丁直接替换内部接口小版本换 API 即崩2视觉版权重禁止运行纯文本专用的转换脚本会损坏视觉编码器张量3镜像内SGLANG_ROOT/sgl-workspace/sglang不可改指别处入口与补丁按此路径定位源码树换路径等于换基线4不要与官方 dev 预览镜像混用那是 v0.5.17 的基线与本补丁的 v0.5.16 接口互斥第 4 条值得多说一句两条路要选定一条走到底。拿 dev 预览镜像去打 v0.5.16 的补丁接口不匹配是必然结果而且失败方式会很隐蔽。六 为什么不选另一条路方案稳定性视觉完整性复杂度推荐场景v0.5.16 SM80 补丁 视觉回移植上游生产级验证回移植后真实可用读图正确、进冒烟断言中长期稳定、要单流性能与可复现官方 dev 预览镜像 环境变量通用 fallback官方原生适配低快速尝鲜选择逻辑很简单要在这台 A800 上长期提供服务且要求视觉 工具 512K 上下文 单流 ~220 tok/s同时成立 → 本方案只想快速看视觉效果、不在意 SM80 性能路径与可复现性 → dev 预览镜像。七 适配之后实测足迹补丁跑通之后一次冷启动的日志给出了这套栈的真实成本4 卡 TP4单卡口径项实测主模型权重fp8 e4m3 加载后38.49 GiB / 卡DSPARK 草稿权重2.82 GiB / 卡KV 池物理占用target draft11.83 GiBCUDA Graphtarget draft1.81 GiB稳态显存~56.5 / 80 GiB运行时余量 ~23.5 GiB已验证的运行环境项值Python3.12.3CUDA runtime13.0镜像 tag 即cu130PyTorch2.11.0cu130Triton3.6.0flashinfer-python0.6.14transformers / xgrammar / numpy5.12.1 / 0.2.1 / 2.3.5GCC13.3.0这里有个容易算错的地方主权重不是总权重 ÷ 4 ≈ 42 GB/卡那种粗算。ViT / Aligner 是 BF16MoE 专家走了 INT8 重排实际落地是 38.49 GiB/卡。八 适配的边界哪些东西补不了诚实地说重规划数据路径解决的是可行性不是所有性能问题。有两类东西是这台机器的硬边界MoE 专家并行EP不可用。补丁栈里 marlin runner 没有 deepep 的融合函数会直接NotImplementedErrorEP 内核本身需要 SM90。想要单流提速正解是 DSPARK 投机解码而不是 EP。MTP / EAGLE 没有收益。实测 accept rate 0.00、反而更慢~40 tok/s低于非投机的 ~57所以最终配置里投机算法是NONE只用 DSPARK。这两条合起来说明一件事**适配的目标是在这块硬件上取到它真正能取到的最优不是复刻 SM90 的能力。九 这次适配的形状这一层能总结成一句话不是让模型迁就硬件而是让数据路径迁就硬件。具体是三件事承认约束低比特算子在 SM80 上不存在补丁不是优化而是可行性方案逐段重路由每段前向都换成 SM80 真有的算子同时保住能用上的最强算力专家层 INT8把不可复现的部分挤出栈外官方镜像不动、权重不转换、版本钉死、diff 逐字节可校验。小结A800 跑不了这份权重不是配置问题是算子链不存在解法是逐段重规划数据路径BF16 线性层 INT8 专家 BF16 KV INT8 indexer Triton 稀疏注意力用sitecustomize.py做运行期注入官方镜像一份不动还能一键关掉做对照视觉是独立的第二层改动PR #37253 回移植不是开关且它的验收标准是真的认出了红色版本、权重、路径、基线四条红线违反即 100% 失败。