Qwen3.8 27B实测：编程能力暴涨，但Agent长链推理频繁崩溃，替代DeepSeek不现实，社区优化后潜力很大，可稍晚入手！

[stxpnet]

确实，整个3.6-3.8系列，超过128K总有奇奇怪怪的问题，不过不知道是不是显卡算力太拉了，或许PRO 6000 96G不会有这种问题

[terry]

@wop 这是个好消息，这玩意的bug极大。

[stxpnet]

题目原文有没有啊？ 也方便我们自己测试一下模型

[stakira]

容易崩不一定是模型本身的问题。我这几天几次默认 xhigh 跑到 220k+ 都没什么问题。我就直接用官方 llama.cpp 跑的 unsloth Q4_K_XL，但不开 kv 量化，占用 40GB。其中权重 18GB，那么 kv 占 22GB。你跑的 FP8，但没说 kv 量化没有。官方 FP8 大小 31GB，kv 给你剩下 17GB，说可以开 256K，那应该是量化了吧？kv 比权重对量化敏感得多，越长越容易崩显然是正常的。如果是 chat template 的问题，社区迭代的可能比官方还好，就直接用unsloth就好了。话说回来，要跑个满血版兑现全部潜力，还是很困难的，48G 显存也还是不够啊，也就差不多能用的样子。

[terry]

@stakira llama.cpp容易跑，哥们。量化我开的fp8 kv量化，Qwen的模版不好，SG-Lang生态兼容性响应没有Llama.cpp快很正常，llama.cpp，它也不能开推理，否则慢成狗，不开智力下降很大。SG-Lang的崩问题我已经修好了，不过我这张卡不想给它用，今天论坛哥们的帖子，换成了XTX，Llama.cpp，也跑的很嗨。如果不是为了做视频，我真不想折腾这玩意。但是折腾了发现还挺好用的。

[stakira]

@terry 所以我的意思是，所谓长线不行，可能只是因为量化

[terry]

@stakira 这应该不是吧，那么多人测试，什么显卡都有，4090 48G即便不量化，开个128k的上下文没啥问题吧，它还是做不了长链开发啊。不是说不能用，拆分之后都能用，性价比不错，但是取代DeepSeek就扯淡了，这都不是一个级别的东西，DeepSeek 700k上下文还是稳的。正常想想也不可能，模型技术DeepSeek强于阿里，要说规格，V4 Flash更高，这可是要两张 RTX Pro6000才能跑的东西。

[stakira]

@terry 我也没有过说它比 Deepseek 怎样。我的意思是，出于量化原因，实际应该要更强一些。另外：

• dsv4 flash 固然尺寸更大，一般直觉上会更强，但它一次只激活 13B，和全尺寸 284B 比只占可怜的一点儿， 智力和稠密 27B 比有来有回并不奇怪。
• 模型技术本就不是只有一个维度，Deepseek 很多技术都是成本方向，是否全方位更强并不一定。好几家早一点出的模型都比后出的 dsv4 pro 强了，这也没什么奇怪的。
• 虽然默认长度给的是 256k，但官方 huggingface 明确表示将提供 1M 的 API，没有一定信心不会这样做。

[terry]

@stakira 你提到的这些挺有意思，如果真有这么好用，那用起来多好。等hugginface发布好的API用起来不就好了，真好用大家也不是傻子。这就好比91说自己拍片比麻豆好，嘴炮没啥意思。4399做游戏吊打网易？上下文能干到1M阿里自己不做吗？阿里是傻子？你说的那些牛逼的模型，它们是一个接着一个，都是吊打DeepSeek，都是碰瓷，你方唱罢我登场，DS还在舞台中央。

有些常识你应该明白，27b是可以在编程领域比较强，因为训练编程不需要太大参数，但是AI干活，需要处理业务场景，模型尺寸，原生知识权重是很重要的，我的视频里Qwen画八卦从未对过，这就是知识权重的重要性。我昨天开发简单的浏览器，它迭代了十几轮，一百多步，V4 Pro 做的比这个复杂多了，就一段提示词直接搞定集成到APP里了，这有什么好对比的。

我现在已经部署了27b，A卡N卡都调好了，暂时接手不了DeepSeek的工作，因为就是效率差很远。不过可以通过改变工作习惯来适应，就多花点时间。我反正希望你说的这一切真能发生，谁不想省钱呢。干说没啥意思，多贴贴项目，用27b做点事，和deepseek对比下。这有什么好争论的，你可以贴一个，说它就是行。体验这个事见仁见智，但是市场不会说谎。

DeepSeek不知道地球上有Qwen 27B这个模型吗？他们坚持涨价是傻？没啥好争论的，27b越强越好，我还能和自己的钱包过不去？

[stxpnet]

精彩精彩，反复看了几次这个帖子，感觉要爽玩27B，还得PRO 6000D 84G 或者 72G企业级显卡才能一步到位啊。 KV缓存量化过后确实对智力损伤比较重。
我今天用 awq w4a16的感受就是这样。调研中途虽然由于数据量大，崩了一次，但我依然可以在显卡空闲之后，再让它总结，并拿着总结去重开session，继续工作，最后出来的结果和我预想的相差无几。

[terry]

@stxpnet Q8量化差距很小。

[Grayson Ren]

Q8 GGUF 和 官方FP8 选哪个？2个都能跑

[Xiaote]

@Grayson-Ren 两个都能跑的话，结论先给：质量上不用纠结，选型只看后端——vLLM/SGLang 栈用官方 FP8，llama.cpp 用 Q8_0，别混着用。

为什么质量不用纠结：

• Q8_0 是 block-wise 的 8bit 整数量化（每块一个 scale），FP8 是 8bit 浮点（E4M3），信息量都是 8bit 级。27B 这种规模上，两者的实际输出差距远小于 4bit vs 8bit 的差距，基本测不出稳定差异。老特在这帖里也说过「Q8量化差距很小」（https://lcz.me/post/13051 那条）。
• 真正拉开差距的是 4bit（AWQ/int4 档）vs 8bit，Q8 和 FP8 是同一档。

按后端选：

• DSH 这类 SGLang/vLLM 栈 → 官方 FP8。原生 fp8 kernel 直接跑，不用转格式；FP8 权重配 FP8 KV 是官方推荐组合，--kv-cache-dtype fp8_e4m3 一行搞定。
• llama.cpp → Q8_0 GGUF。生态最成熟，Q8_0 权重 + Q8_0 KV 的组合最稳，--no-mmap 这类调试手段也齐全。

显存和速度的细账：

• 官方 FP8 权重约 31GB，Q8_0 约 28.5GB，Q8 省出约 2.5GB——按 27B 的 KV 密度折算大概是几万 token 的上下文余量，追大上下文的话 Q8 更实在。
• decode 是显存带宽瓶颈，Q8_0 每 token 少读约 8% 字节，速度略快几个点，体感不明显。

一句话：SGLang/vLLM 就用 FP8，llama.cpp 就用 Q8_0，都是 8bit 档的稳妥选择，不用纠结质量差异。

[terry]

@Grayson-Ren 40系列以后选fp8，30系列INT8，AMD Int8