Qwen3.8-Flash-Next 单机 DGX Spark 跑通近一小时

导语:Mia’a AI Lab(@0x0SojalSec)9 月 17 日放出 Qwen3.8-Flash-Next 的单机部署实测,声称 125B 参数 MoE 模型在单台 DGX Spark(128GB 统一内存的 Grace Blackwell 桌面开发箱)上,跑近一小时的真实仓库编码任务没崩盘,文本、图像、视频三模态全开,FP8 KV 缓存 + 推测解码,最大 512k YaRN 上下文。仓库与脚本全部开源,99GB NVFP4 量化权重 + 27GB PLE 表,直接 download.sh + start.sh 两步起服。

一、单卡 125B 跑近一小时没崩,这事到底什么水平

DGX Spark 是 NVIDIA 面向桌面开发的 Grace Blackwell 平台,整台机器就一块 GB10 芯片,128GB 统一内存(CPU/GPU 共享)。这个内存量是过去 125B 量级模型在单机上”勉强能跑”的临界点——但只是跑,跑稳定跑一小时不崩,过去基本没人敢打包票。

Mia’a AI Lab 给出的实测场景是:用 qwen-code 编程工具对一个真实仓库连续开 38 个请求,其中 19 个单条 prompt 在 5 万到 10 万 token 之间,最长并发 3 路,2.5 小时压力测试中——

启动 10 分 51 秒拉到 /health 状态
待机 40 分钟后剩余内存 15.5–16.4GB(触发不到 6GB watchdog 阈值)
2.5 小时压力跑完,驱动显存 96.6 → 97.5GB(单步,无抖动)
journalctl -k 里 NV_ERR_NO_MEMORY 出现次数:0

对桌面平台来说,这个稳定性数据是有说服力的——不是 demo 级,是真的能开服接客。

二、几个关键数字

按仓库 README 给的 sparkDash 实测,8 路并发解码:

并发流	每引擎步耗时	步内 token	聚合吞吐	单流吞吐
1	61.5 ms	3.00	48.7 tok/s	48.7 tok/s
2	74.3 ms	2.83	74.6 tok/s	37.3 tok/s
4	96.2 ms	2.84	113.7 tok/s	28.4 tok/s
8	131.0 ms	2.81	162.9 tok/s	20.4 tok/s

预填(prefill)也实测过:8k/16k/32k/64k/128k/256k 分别 2,200 / 2,304 / 2,314 / 2,257 / 2,146 / 1,944 tok/s。128k 上下文 TTFT 约 61 秒,256k 约 135 秒——单机能跑这个体量本身已经超过行业对”桌面开发机”的预期。

三、为什么能在 128GB 里塞下 125B

Mia’a 用了三招省内存:

NVFP4 量化:99GB 量化权重,比 BF16 砍了将近 7 倍。
PLE 表 offload + mmap:约 27GB 的参数表存到 NVMe,通过 mmap(MADV_RANDOM)按需读,常驻内存里只留 16.46GB 给 KV。
BF16 循环状态 + FP8 KV 缓存:KV_CACHE_DTYPE=fp8 配合 MAMBA_SSM_CACHE_DTYPE=bfloat16,在 8 路并发下比 9 月 5 日那一版解码吞吐提了 8.5%(151.6 → 164.5 tok/s)。

按仓库描述的预算:99GB 权重 + 27GB PLE 表 + 16.46GB KV 池 + 驱动 ~5GB,刚刚好压在 128GB 预算线内。还能再留 15GB 给系统缓冲,这就是为什么 watchdog 不触发。

四、起服有多简单

cp .env.sample .env        # 改 IMAGE / HF_TOKEN
./download.sh              # 拉 99GB 量化权重(可断点续传)
./start.sh                 # 10-12 分钟到 /health,监听 :8888
./stop.sh                  # 优雅停服 + 清理 POSIX 共享内存

整套 docker 化部署,不需要手工改 vLLM 源码。start.sh --no-launch 可以预览内存预算,stop.sh --force 跳过等待期。

仓库还附带了一个 6 页 CHANGELOG 记录了 9 月 4 日到 9 月 6 日的迭代:从 22GB KV 切到 20GB(更安全,避免吃满主机内存),再到 BF16 循环状态 + MAX_NUM_SEQS=8 的 8 流吞吐峰值——整个调优过程贴了实测量化数据,不是空口说白话。

五、这意味着什么

对本地开发者来说:

桌面级 125B MoE 真能跑生产任务了。过去 125B 量级要双卡 H100 或者多机 NVLink,现在一台 GB10 桌面机就行。
NVFP4 量化到 99GB 仍能保住 BF16 性能,意味着 NVFP4 这条量化路线在大模型上开始接近工程成熟。
三模态(文本/图像/视频)开箱即用,省掉了单独部署 CLIP/视觉编码器的麻烦。
仓库把部署脚本、显存预算、调参记录全部公开,社区可以直接复现或拉分支去改。

六、上手前要注意的坑

仓库 CHANGELOG 写得很实在——调参过程里他们其实踩了不少雷,贴出来给后面要复现的人:

KV 池不能拍脑袋设大。KV_TARGET_GIB=22 和 20 都遇到过 OOM,9 月 4 日有 3 个服务器直接挂掉。原因是宿主内存会随其他容器占用波动,设太大会被驱动拒绝分配。仓库现在加了 HOST_RESERVE_GIB=26 作为宿主端硬上限,KV 池只能拿剩下的——单台机实际只有 16.46GB KV 可用。
262k 原生上下文没 512k YaRN 测得全。KV_TARGET_GIB=20 那一组实测全在 512k YaRN 上跑,262k 那一行数据还是 9 月 4 日 BF16 时代的,9 月 5 日加的 MADV_RANDOM mmap 修改后没在 262k 上重测。生产用要心里有数。
并发解码会让预填尾延迟变形。两个解码流 + 一个 64k prompt 同时进来,那个 64k 预填的 34.5 秒里,解码流每步 p95 1111ms / p99 1400ms(对比安静服务器 78ms)。如果业务是长 prompt 扎堆,得手动把 chunk 从 2048 调到 1024——延迟能压到 p95 666ms,但 prefill 吞吐损失 5.5%。仓库没把这个当默认。
共享内存泄漏。vLLM 容器用 --ipc host,退出时残留的 POSIX 共享内存会留到主机的 /dev/shm 一直不释放,直到重启。stop.sh 默认 30 秒优雅停服;--force 强制,但要确认 vLLM 已下线。

七、对安全研究意味着什么

这种”消费级硬件能跑 125B”是个分水岭级的事。

过去做 LLM 红队评估的瓶颈不是 prompt 设计,是硬件。你要在 A100/H100 集群上才能跑大模型,意味着每次 fuzz、对齐测试、提示注入实验都要排队、烧钱、走合规流程。安全研究员能在自己机器上跑的小模型通常不超过 13B,得到的结论往 100B+ 模型上推得打折扣。

DGX Spark 把这条门槛往下砍了整整一档:

离线红队测试——对抗 prompt 生成、越狱测试、奖励黑客探测可以完全脱网跑,样本不外泄。
私有权重审计——企业内部微调模型能直接本地跑评估套件,不必上传到云。
fuzz 闭环——8 路并发 162.9 tok/s 撑得起每秒上千次”输入变异 + 输出异常检测”循环。
推理安全工具链本地化——Llama Guard、ShieldGemma、Granite Guardian 这类护栏模型能跟 125B 主模型并排部署,完整闭环在本地完成。

更深的信号是:NVFP4 这种 4-bit 量化在 125B 上几乎不掉点,意味着开源大模型跨过了”消费级硬件能跑生产级大模型”这条线。红队、研究、监管这三类过去要云资源的工作,以后都会往桌面/工作站下沉。