CMP 170HX 今天又有一个比较实在的进展。 8G版解锁64G之后，已经有人单卡把 Qwen3.8-27B 跑到 200K 级真实长上下文了。 vLLM 0.27.1，175W，不超频，1K 大概84 tok/s，64K 还有75 tok/s，200K 还能跑57 tok/s，而且做了160K左右的 needle retrieval，不只是显存能分配出来，是真的在跑长上下文。 温度也还不错，持续负载核心大概66度，显存71度，功耗173W左右。这个和之前170tune测出来的175W甜点位基本对上了。 但我还是那句话，别一看到256K、262K就高潮。 现在公开证据能确认的是200K级真实跑通，不是262K连续跑几天，更不是24到72小时 serving 0 Xid。 还有一点，这个案例用的版本并没有包含最新的 WPR2 修复，所以它证明的是长上下文能力，不代表满显存稳定性问题已经彻底解决。 目前我的判断还是没变。 8G版越来越像真正能拿去部署的64G AI卡了。 10G版的80G，继续当彩票看。没有多人独立复现，没有全显存唯一pattern，没有多CUDA context，没有24到72小时0错误，我就不加一分钱估值。

今天继续跟一下 CMP 170HX。 这次没有80G神迹，反而抓到一个挺有价值的软件坑。 8G版解锁64G以后，有人在 CUDA 13.3 + vllm.cpp 下第一次 CUDA Graph capture 就直接炸，报 CUBLAS_STATUS_INTERNAL_ERROR。第一反应很容易怀疑显存、地址映射，甚至怀疑170HX又抽风了。 结果现在基本查清楚了，不是卡坏了，是 CUDA 13.3 的 cuBLASLt 在 graph capture 里查 heuristic 的兼容性问题。 修复也已经出来了，提前把 GEMM heuristic cache 好，再进 CUDA Graph，同一张64G 170HX 连续测试正常，而且 token 输出一致。把 cache 关掉，又能100%复现原来的报错。 更有意思的是，后来 GB10 上也复现了同样的问题。 所以这个结论很重要。 以后170HX报 CUDA error，别第一时间就说显存坏了。现在这个生态已经进入一个新阶段了，很多问题不是硬件解锁本身，而是驱动、CUDA、vLLM、graph capture这些软件层一层一层互相打架。 8G版64G继续往生产卡方向走。 10G版40G正常推进。 10G版80G，还是老规矩，没看到多人独立复现，全显存唯一pattern，多CUDA context，再加24到72小时0 Xid 0 error之前，我还是当彩票。

今天继续跟一下 CMP 170HX。 先说结论，今天没有80G神迹，但是有两个比较实际的变化。 10G版这边，40G路线又往前走了一步。之前 Qwen3.8-27B 跑 W8A16 Marlin 会触发 Xid 31，甚至把 CUDA context 一起搞死，现在已经有人给出了 CPU repack 的绕过方案。同一张 Samsung 40G 卡，单流接近98 tok/s，8并发 aggregate 275 tok/s。至少说明10G的40G，不只是能亮机，软件坑也在一个个被补。 8G版这边反而要提醒一下。 今天突然冒出来一个所谓64G解锁 VBIOS，号称直接刷一下就能变64G。我目前不信，而且建议任何人都别拿批量卡去试。 原因很简单，现在比较可信的64G路线，本质还是驱动和GSP运行时解锁，不是刷个ROM就完事。那个所谓64G VBIOS，很可能只是从已经解锁的卡里dump出来的原厂ROM。 所以今天的判断还是很简单。 8G版64G，继续越来越像正经生产卡。 10G版40G，软件生态继续补齐。 10G版80G，还是彩票。 谁要是说80G已经稳定了，还是老规矩，先给我全显存 unique pattern，多CUDA context，再连续跑24到72小时 vLLM/SGLang，0 Xid，0 error。 截图不值钱，能一直干活才值钱。