在4张 A800上跑DeepSeek-V4-Flash-Vision系列总览在一块没有 FP8 / FP4 Tensor Core的硬件上把一个按 FP8 / FP4 打包的多模态大模型跑了起来并让它稳定提供 512K 上下文、单请求 96 张图、单流 ~220 tok/s 的服务。文章目录在4张 A800上跑DeepSeek-V4-Flash-Vision系列总览开源项目地址一 背景二 最终结果三 系列地图第一编 · 适配与部署01–04第二编 · 排查方法论05第三编 · 修复06–10第四编 性能与复盘11–12四 阅读推荐五 贯穿全系列的七条经验开源项目地址gitee开源仓库地址dsv4-vision-exp-sglang-sm80一 背景三个角色角色是什么模型DeepSeek-V4-Flash-Vision-Exp——DeepseekV4ForCausalLM43 层带 ViT / Aligner 视觉张量引擎SGLang v0.5.16commitfdebc938官方镜像lmsysorg/sglang:v0.5.16-cu130硬件4 × A800 80GBSM80Amperecompute capability 8.0TP4这三者本来是不成立的权重里普通线性层是fp8 e4m3 block 量化MoE experts 是packed MXFP4A800 只有 BF16 / INT8 Tensor Core没有 FP8 / FP4SGLang 原生的 MXFP4 路径明确拒绝 SM80。所以结论只有一条官方镜像直接docker run是起不来的。要么换硬件要么把整条数据路径重新规划一遍。我们选了后者并且额外做了第二件事把官方还没进 v0.5.16 的视觉支持回移植进来。二 最终结果维度实测结果单流解码DSPARK 投机解码稳态~220 tok/s三次复测 217.8 / 219.6 / 220.3非投机 ~57 tok/s上下文512K524288KV 池容量871,680 token图片单请求最多96 张TTFT 亚线性增长8 张 0.41s → 48 张 4.21s → 96 张 5.32s并发DSPARK 32 并发 0 失败切非投机可到 192 并发、聚合 ~936 tok/s显存稳态平线~56.5 / 80 GiB运行时余量 ~23.5 GiB这是设计使然见第 04 篇启动4m55s 19m17s两段独立瓶颈之和权重读取 JIT不是机器时快时慢协议OpenAI Chat Completions / OpenAI Responses / Anthropic Messages 三端兼容稳定性长跑RestartCount0无 crash三 系列地图第一编 · 适配与部署01–04把跑不起来变成跑得稳讲的是方案成立的理由和可复现的落地方式。#篇目一句话01适配当 A800 遇上按 FP8/FP4 打包的权重不是配置错了是官方数据路径里没有一条能在 SM80 上执行的算子链02构建把补丁叠成可复现的一层官方镜像一份不动四类改动叠成自包含补丁镜像再用闸门防漂移03部署启动链路、两种形态与运维起停只需三条命令就绪的唯一判据是日志 /v1/models04容量512K 上下文与那本显存账显存平线是 KV 池启动即全额预分配的结果871,680 是怎么算出来的第二编 · 排查方法论05#篇目一句话05排查36 个坑的六种形状大多数问题不是参数写错了而是版本 / 硬件 / 协议 / 测量口径的错配第三编 · 修复06–10每一篇都是同一套结构症状 → 为什么难查 → 根因在哪一层 → 怎么修 → 数字验证。#篇目覆盖的问题06网关与 Responses 协议层浮点created_at丢终态事件、pydantic 懒迭代器致多轮 400、Anthropic 通道 40107工具调用与结构化输出历史渲染污染导致参数嵌套、流式丢参、DSPARK 不支持 grammar08思考等级与推理内容思考被塞进正文、reasoning_tokens恒 0、7 档 effort 的三端映射09视觉链路从能读图到崩不了融合 off-by-one 整机重启、图片数上限、占位符特殊 token 致全会话 40010稳定空回答、推理重复与字符损坏high档推理逐字重复烧完预算、0.35% 采样抖动被误判为管线损坏第四编 性能与复盘11–12#篇目一句话11性能数字是怎么测出来的同一套服务口径不同能从 ~100 变成 ~220 tok/s单流快与高聚合不可兼得12复盘这套栈教给我的十条经验把散落在各篇的教训收拢成可迁移的判断规则四 阅读推荐目标建议理解这套方案为什么成立01 → 02 → 09 → 07要把它部署起来01 → 02 → 03 → 04线上出问题快速定位05症状对照表→ 对应的修复篇06–10只关心容量与速度04 → 11只想接入调用12五 贯穿全系列的七条经验硬拒绝 vs 善后默认实现偏爱raise占位符多了就崩、文本里有特殊 token 就 400。真正消除故障的往往是补齐 / 转义这类带不变式的善后逻辑。历史回放会投毒工具结果和模型自己的回显被逐字回放进下一轮请求于是编码器的一个小错会被模型学走、自我强化单轮正常、带历史必翻车是这个模式的指纹。协议层和引擎层必须分开归因先证明引擎直连是好的再动网关。口径决定结论同一套服务测量口径不同能得出完全相反的结论~100 vs ~220 tok/s显存平线其实是预分配。同名不等于同实现不同引擎里都叫 “DSPARK” 的东西是两套代码跨引擎类比前先验证。复现性靠闸门靠人记住改了哪儿是不可靠的要靠可执行的逐字节校验。没坏也是一种结论显存平线、档位坍缩、思考模式下采样参数无效。先排除符合预期再列真故障。