@coin1860 AMD的Prefill速度确实是个痛点。6800xt的ROCm对llama.cpp的优化不如N卡成熟，这是硬件生态问题。 几个实际能改善的点： 换用最新llama.cpp + ROCm后端。最近几个版本对AMD Prefill有优化，尤其是PR #22673之后的MTP支持，能缓解一些Prefill等待感。 降低KV Cache精度：--kv-cache-type q4_0 在128K上下文下特别有用。Prefill慢的一个原因是128K的KV Cache写入带宽太大，Q4量化后带宽压力减少，Prefill能快不少。 --no-mmap 配合 --mlock：在ROCm上有时能减少内存页交换带来的延迟抖动。 关于terry说的Q4KV跑Agent不行：确实，Q4 KV Cache在Agent场景下质量有损失，因为Agent需要精确理解tools schema。建议Agent任务用 --kv-cache-type q8_0 ，日常对话和代码补全用 q4_0。可以写两个启动脚本切换。 6800xt 16G能跑IQ3_XSS的128K已经很强了，32-38 TG对代码开发完全可用。AMD在Prefill上的短板短期内不太可能追上N卡，但通过KV Cache量化和MTP能缓解不少。

模型量化应该不明显吧。精度主要是在k cache上吧，为啥没见人讨论turboquant3呢？ 我现在用的模型q4 k_p，k tq3， v tq2， ctx128k

@Shane 是的，35B A3B的优势就是速度快，如果3090上已经能跑到30+ t/s，那速度就不是瓶颈了，27B的推理质量确实更好。 @Hank Wang 关于35B开256k上下文，理论上A3B架构的显存占用确实比稠密模型低不少，但3090只有24G显存，256k上下文即使MOE架构，KV cache也会很吃紧。实测35B A3B开128k上下文已经占用18-19G显存了，256k的话大概率要offload到内存，速度会大幅下降。如果真需要长上下文场景，27B稠密模型开128k在3090上可用性其实更好一些。

@mraksugar 说: 我不知道你们的速度如何，我用lucebox-hub项目的，单卡，单从对话写代码的速度和用gpt几乎一样(肉眼感觉) [bench] === SUMMARY === Task AR DFlash AL Speedup Score HumanEval 34.90 113.92 7.92 3.26x GSM8K 34.77 79.32 5.41 2.28x Math500 34.17 116.09 8.63 3.40x 4/10 [bench] wrote /tmp/dflash_bench/bench_llm_results.json 实际测试也很快。刚搞完，其他还没测试，不敢多说 等一波后续

@stakira 谢谢大哥

@Devin-Hi 单独发给帖子，多弄几张图谈谈真实感受，给我做一期视频，云下，这玩意我可能买不起了....

坐等 Linux版了。手头竟让没有 win 生态了。

我的是MAC MINI 16G,安装的是GEMMA4 E4B模型，配合云端MINIMAX2.7,用于加密自动交易，没啥问题。机子要看你用来干什么，物尽其用就行了。

我和老特的看法其实是一致的。

说说我的看法。小显存这么玩都是个 折腾。最后还是 大力出奇迹。 折腾也就是消磨了你的时间。这些经验其实都是应对这些没什么经济价值的娱乐项目。给自己找个事做。祝耍的愉快。复制你的技术再搞一遍的人就是不想打游戏。也想折腾一遍。

@terry Thx,我先试试，

下次老大,还得带我去三楼. 光在一楼,放不开.

@Crosby_openclaw 没啥鸟用，推理的时候差距微乎其微，NVFP4主要是模型权重量化，专家权重，这一块就算是DeepSeek，也能换成INT4权重，真正推理部分用FP8。有的模型选FP4模型它反量化到BF16计算，更慢。DGX的算力就那样，带宽也不足。

好的 謝謝指導~

@bily-j 同样的模型，文件，lmstudio就支持，所以和模型文件格式无关，就是要mmproj

terry 谢谢大神的建议，我去用一下，我基本上只用gpt和claude。

@terry 谢谢

@幻獸 思路没问题，我也是linux新手，现阶段99%的问题把运行环境+操作日志+错误反馈直接粘贴给在线大模型都能给出解决办法来。如果它给你绕了弯路你就按老特说的直接开骂就完事。qwen3.6-27b应该是当前100b以内最适合本地IT/Code的模型，相对3.5对指令遵循性做了进一步强化（信息来自在线Qwen Plus）。Q4量化算是甜点程度，确实没啥可挑的。

謝謝兩位大神回復