304B参数，256K上下文窗口，单块GPU全部吃下，还能跑出168 tok/s——这不是某个实验室放出的概念验证。一个开源仓库已经把DeepSeek-V4-Flash-0731搬上了单颗AMD MI300X，带着完整的生产配置和补丁，开箱可跑，不量化、不卸载、不缩水。
过去一年，大模型部署的主旋律是用无数张卡拼显存，或者把权重压缩到面目模糊。但这次，有人偏偏逆着来：就让一张MI300X，用它的192 GB HBM硬扛304B模型，还要扛住256K长序列。它扛住了，而且扛得漂亮。单流解码168.6 tok/s，8并发聚合吞吐542 tok/s，实测跑通全套256K上下文。这个性能数字放到任何一张企业级GPU上都不寒碜，更何况它来自一张被AI生态嘲笑了很久的“非NVIDIA”卡片。真正让我兴奋的不是数字本身，而是这背后那一层层的技术偷手——FP8格式修复、推测解码调优、混合KV缓存，每一刀都砍在推理瓶颈的骨头上。
192GB HBM，怎么装下304B参数还要跑长序列？
FP8不是拿来就能用
304B参数如果用FP16存储，光权重就要吃掉大约608 GB显存，MI300X那192 GB根本是杯水车薪。显然得压低精度。但问题不是简单切到FP8就完事。DeepSeek-V4-Flash自身支持FP8，可AMD的推理栈对这套格式并不原生兼容——厂商给的工具链对特定算子、数值范围的FP8支持存在缺口，直接跑会撞上精度崩塌或莫名其妙的算子报错。这个开源仓库做了一件格外“脏”但极其关键的事：补齐FP8格式断层。不是重新量化，而是修复工具链里缺失的FP8数据路径和格式转换逻辑，让模型按DeepSeek原生的数值分布丝滑地跑在MI300X的矩阵引擎上。这一层修补，把权重的内存占用压到了不到150 GB，显存终于有了喘气的空间。
混合KV缓存：把上下文劈成两半
光塞下权重还不够。256K上下文一旦跑起来，KV缓存膨胀速度会远远超过想象力。用最朴素的full cache方案，单请求的KV缓存就能轻松冲上几十GB，八路并发可以直接把剩余显存榨干。仓库采用的混合缓存策略，本质上是一种“热冷切分”：高频访问的前缀缓存保持在高带宽的HBM里，长尾的远端上下文则用更低精度、更紧凑的结构存放，甚至在必要时对极少访问的分片进行在线压缩。这样，256K上下文的KV缓存总空间被拦腰砍到可控范围，又不至于让重要的注意力模式被过度稀释。这里的工程味儿很重，没有什么单一的魔法技巧，就是一寸一寸地抠出来。
不卸载，一滴也别漏
我看到的最聪明的一步，是彻底放弃了权重卸载。很多方案会让权重在计算时从系统内存或NVMe盘按需换入换出，这种策略在吞吐压力面前就像用吸管喝瀑布。仓库直接把全部权重驻留在HBM里，利用MI300X的统一内存架构避免数据搬运，所有层的计算都在卡上闭环。代价是要求极致的显存分配和碎片整理，但换来的是计算单元始终有活可干——每一条流都不会被I/O拖累，168 tok/s的单流解码就是这么来的。
168 tok/s单流和542 tok/s聚合吞吐，同一张卡的两种性格
草稿模型把解码链路拉直了
大模型自回归解码的最大痛点是串行依赖：每生成一个token都要等前一步的结果，这导致计算密度极低，流式接口的延迟却很高。仓库在MI300X上引入了一套轻量的推测解码流水线——用一个小得多的草稿模型一次生成多个候选token，再由304B主模型一次性验证。草稿模型小到可以在缓存里几乎零开销地来回跑，MI300X上的计算阵列则被主模型的批量验证喂得饱饱的。单流168.6 tok/s，相当于每秒产出超过一百六十个完整token，日常对话场景下用户感知就是“瞬间出来整段话”。这个过程没有黑魔法，纯粹是把延迟拆成两步走，把顺序依赖打碎。
并发拉到8，吞吐为什么没翻8倍？
8并发流聚合吞吐542 tok/s，约等于单流吞吐的3.2倍，而不是理想中的8倍。这恰恰暴露了MI300X的物理底牌：显存带宽。304B模型极深的网络层数产生了巨大的中间激活和注意力运算，这些数据流强依赖HBM吞吐。当多个请求并排跑，总计算量上升，但显存带宽被多个竞争者疯狂撕裂，线性增益很快撞墙。仓库为此做了两件事：一是针对AMD架构优化kernel融合，尽可能把多个操作在速写器和共享内存里一次消化，减少写回HBM的频次；二是调整并发调度，让不同请求的草稿模型推理在主模型验证的间隙穿插执行，用计算把带宽闲置填满。542 tok/s这个结果，已经是把这张卡的骨头敲开吸髓了。
一张卡撑起256K上下文，然后呢？
长上下文不是显存杀手，是带宽杀手
很多人以为256K上下文最大的障碍是显存不够装KV缓存，其实更致命的限制在带宽。长序列的注意力得分计算，需要在HBM上反复搬运巨大的K和V矩阵，这个搬运量随序列长度近乎平方增长。仓库把一部分KV操作移到了SRAM级别的共享内存里执行分块计算，尽可能让K、V矩阵的读取是一次性地、密集地完成，再配合前面说的混合缓存降低调取频次。换句话说，显存是有了，但把显存里的东西真正喂给计算单元的速度，才是决定256K能不能跑稳的关键。MI300X这次没掉链子，实属难得。
重写单卡规则
一个能跑304B模型、撑住256K上下文的单卡方案，对开源部署的冲击是直接的。从前企业不得不租用8卡节点、或者踩着各种量化框架的坑上线服务，现在一张MI300X裸卡就能扛起生产级的对话、长文档分析和代码补全任务。这个转变不仅关乎成本，更意味着部署模型的选择权回到了工程团队手里：不用再被NVLink的拓扑牵制，也不用在细碎的模型并行拆分里浪费生命。仓库开放的不只是配置文件和补丁，是一种“单卡就可以当真”的信念。我想，这种信念远比168 tok/s这一个数字更值得传播。
