跳转至内容
  • 版块
  • 最新
  • 标签
  • 热门
  • 用户
  • 群组
皮肤
  • 浅色
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • 深色
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • 默认(不使用皮肤)
  • 不使用皮肤
折叠
品牌标识

抡锤者

  1. 主页
  2. AI硬件
  3. 被抡锤者种草后,我用 X99 + 4090D 48G 搭了一台本地 LLM 服务器

被抡锤者种草后,我用 X99 + 4090D 48G 搭了一台本地 LLM 服务器

已定时 已固定 已锁定 已移动 AI硬件
31 帖子 11 发布者 974 浏览
  • 从旧到新
  • 从新到旧
  • 最多赞同
回复
  • 在新帖中回复
登录后回复
此主题已被删除。只有拥有主题管理权限的用户可以查看。
  • Ivan YinI 离线
    Ivan YinI 离线
    Ivan Yin
    编写于 最后由 编辑
    #19

    在chatgpt中提问q8、q6精度问题的核心观点如下,供大家参考:

    结论:Qwen 3.6 27B 的 Q8 和 Q6,在“可感知精度”上差距不大;Q6_K 已经非常接近满血,Q8_0 更接近 BF16/FP16,主要优势体现在长尾稳定性、复杂代码、长上下文、多轮工具调用这些高压场景。

    1. 本质区别:不是“智商档位”,而是权重还原误差不同

    量化就是把原始 BF16/FP16 权重压缩成低 bit 表示。llama.cpp 官方说明里也明确说,量化会降低权重精度,可能引入准确率损失,通常用 perplexity、KLD 等指标衡量。(GitHub)

    对你现在用的 GGUF 来说:

    版本 精度含义 对模型输出的影响
    Q8_0 约 8-bit 权重量化 最接近原始 BF16/FP16,概率分布扰动最小
    Q6_K 约 6-bit K-quant 压缩更强,但仍属于高质量量化,通常很接近原模型
    Q4/Q5 更激进压缩 可用,但更容易在复杂推理、代码、长上下文中出错

    所以 Q8 不是让模型“更聪明”,而是更少破坏原模型已经学到的能力;Q6 也不是明显降智,而是略微增加了权重误差。


    2. 用现有 Qwen3.6-27B GGUF 量化指标看:Q8 确实更接近满血,但 Q6 已经很高

    一个 Qwen3.6-27B GGUF 量化仓库给出的相对 BF16/full precision 指标里,Q6_K 和 Q8_0 的差距如下:(Hugging Face)

    指标 Q6_K Q8_0 怎么理解
    Same Top P 97.34% 98.38% Q8 的 token 概率分布更接近满血
    Mean KLD 0.0056 0.0034 Q8 平均分布偏移更小
    99.9% KLD 0.50 0.20 Q8 长尾极端错误概率更低
    RMS Δp 1.988% 1.538% Q8 输出概率整体扰动更小
    Mean PPL 6.924 6.914 两者都很接近 BF16 约 6.900

    这组数据可以直接解释:Q8 比 Q6 精度更高,但不是断崖式差距,而是“边缘稳定性”和“长尾可靠性”的提升。

    最关键的是 99.9% KLD:Q8_0 为 0.20,Q6_K 为 0.50。这个差距说明 Q8 在少数高敏感 token 上更稳。平时聊天你未必感知得到,但写代码、工具调用、长上下文检索、数学推理时,恰恰容易被这些“少数关键 token”影响。


    3. 实际体感:Q6 大多数时候够用,Q8 主要减少“莫名其妙的小错”

    你日常用 Qwen3.6 27B 做这些事情时,差异大概是这样:

    普通问答、总结、润色、公文初稿:
    Q6_K 和 Q8_0 差距很小。很多时候你盲测不一定能稳定分辨。文本流畅度、语气、一般知识问答基本不会出现明显差别。

    代码生成、改 bug、项目级理解:
    Q8 更稳一点。不是说 Q6 不会写代码,而是 Q6 更容易在边缘处犯小错,比如漏一个参数、误判一个库 API、JSON schema 细节不准、复杂文件关系里少看一层。Qwen3.6-27B 官方定位里也强调 agentic coding、repository-level reasoning、tool use 等能力,这类能力对 token 级稳定性更敏感。(Hugging Face)

    长上下文,尤其 128K—262K:
    Q8 更值得用。Qwen3.6-27B 的默认上下文是 262,144 tokens,官方还建议复杂任务至少保持 128K 以保留 thinking 能力。(Hugging Face) 长上下文下,模型需要在大量信息中维持注意力、引用关系和中间推理,Q8 的低扰动会更有价值。

    数学、逻辑、精确推理:
    Q8 有优势,但不是质变。量化误差不会直接改变模型结构,也不会凭空增加推理能力;它只是减少原模型 logits 被扰动的程度。对于“下一步 token 很明确”的问题,Q6 与 Q8 几乎一样;对于“多个候选 token 概率很接近”的问题,Q6 更可能把模型推向另一条错误路径。

    小说、角色扮演、长文续写:
    Q6 已经很好。Q8 的优势更多是长篇一致性、人物设定不漂、前文细节保持更稳,但体感差异通常小于采样参数、提示词、上下文管理的影响。


    4. 对你这台 4090D 48G 的建议

    按“精度优先”排序,我会这样建议:

    第一选择:Q8_0 + Q8 KV
    适合:代码、长上下文、公文材料精修、复杂推理、重要输出。
    这是你显存允许时最稳的本地 GGUF 方案。

    第二选择:Q6_K + Q8 KV
    适合:日常主力、速度优先但不想明显牺牲能力。
    从精度角度看,Q6_K 已经接近满血,很多时候比你想象中稳。尤其你已经观察到 Q8 比 Q6 慢约 30%,那么 Q6_K 是很合理的日常档。

    不建议为了模型权重 Q8,而把 KV cache 降得太狠。
    长上下文场景里,KV 精度、上下文长度、RoPE/YaRN 设置、prompt 结构,都会影响最终质量。很多情况下,Q6_K 权重 + Q8_KV 比 Q8 权重 + 激进 KV 压缩 更均衡。


    5. 一句话判断

    对 Qwen3.6 27B:

    Q6_K 是“高质量实用档”,能力基本保住;Q8_0 是“接近满血保险档”,主要提升复杂任务、长上下文、代码和工具调用的稳定性。

    你要是本地长期作为 coding / 公文 / 知识库主力,我建议:默认 Q6_K,遇到重要代码、多文件重构、长上下文材料、需要一次性成功的任务,切 Q8_0。

    1 条回复 最后回复
    0
    • Ivan YinI 离线
      Ivan YinI 离线
      Ivan Yin
      编写于 最后由 Ivan Yin 编辑
      #20

      llama.cpp有更新,与mtp性能相关,我编译新版本后比较一下
      截图 2026-06-13 14-34-33.png

      在平时使用时,没有什么区别,q8依然还是43左右t/s
      截图 2026-06-13 16-58-07.png 截图 2026-06-13 16-58-11.png

      1 条回复 最后回复
      0
      • A applejuice

        @williamlouis 说:

        4080S 16G 是个神器哈。网上都找不到的好货。让 AI 看看是不是可以变32G。
        很多问题你在Mac 上装个 Hermes 接入你的4090就可以了。或Mac用在线 api 。本地AI作局域网提供算力等。
        NAS 是需要的。可以做工作配合存储中枢。如果你需要多 AI 配合工作。用这nas 是个配置比较简单的方案。设置好只读和可写 就能让 AI看另一个 AI的工作结果,然后接力式工作。或围观审核等。手写不太详细:分区。每个区作为一个AI 算力的可写区。其他AI看需要接力的工作区,设置可读,不可写。想法告诉 Hermes 用 DeepSeek flash 就可以实现。你可以描述的更精细点就可以了。
        模型够用就好。这点你做的很好。不要疯狂的搞什么长上下文。够用就行。用不到搞那么长干么?对于不是需要马上就能生产的东西。没什么测试必要。现在更新太快了。无休止的测试是永远测不完的。

        4080s 升级是自己能搞的吗? 会不会搞完就废? 😆

        williamlouisW 在线
        williamlouisW 在线
        williamlouis
        超级版主
        编写于 最后由 编辑
        #21

        @applejuice 找个你本地的能干的工作室给你搞。换显存 自己搞什么?不过升级意义很大。变32G就是神器一件了。

        个人主页:xlkj.org Telegram https://t.me/xlkjorg

        Ivan YinI 1 条回复 最后回复
        0
        • williamlouisW 在线
          williamlouisW 在线
          williamlouis
          超级版主
          编写于 最后由 编辑
          #22

          京东我看见 有以旧换新的商铺 就你把16G给他。它直接给你一块 32G的。变相的少折腾升级。当然到手的就是别人的16G魔改后的到你手了。你的后续也是魔改了给别人。

          个人主页:xlkj.org Telegram https://t.me/xlkjorg

          1 条回复 最后回复
          0
          • williamlouisW williamlouis

            @applejuice 找个你本地的能干的工作室给你搞。换显存 自己搞什么?不过升级意义很大。变32G就是神器一件了。

            Ivan YinI 离线
            Ivan YinI 离线
            Ivan Yin
            编写于 最后由 Ivan Yin 编辑
            #23

            @williamlouis 说:

            @applejuice 找个你本地的能干的工作室给你搞。换显存 自己搞什么?不过升级意义很大。变32G就是神器一件了。

            这卡我还想留着打游戏呢,哈哈。稳定第一,干活交给4090d好了,不能把风险都放在同一个魔改卡的篮子里。原装三风扇的4080s无论怎么说都是可以长期稳定使用的,哪怕像老特4090d出问题,4090能干的所有活4080都能降低质量接续上。

            1 条回复 最后回复
            0
            • Ivan YinI 离线
              Ivan YinI 离线
              Ivan Yin
              编写于 最后由 编辑
              #24

              更正上面的测试,编写汉语文章是43t/s,但是coding的速度远大于这个,稳定在60左右,完全是可用状态,没有必要为了节省显存或追求最高速度,降低精度了

              截图 2026-06-13 21-41-56-s.jpg
              截图 2026-06-13 21-44-30.png

              截图 2026-06-13 21-45-40.png

              J 1 条回复 最后回复
              0
              • Bryant WuB 离线
                Bryant WuB 离线
                Bryant Wu
                编写于 最后由 编辑
                #25

                感谢细致的分享。小白敬上

                1 条回复 最后回复
                0
                • 你 离线
                  你 离线
                  你的名字我的名字都是一样的
                  编写于 最后由 编辑
                  #26

                  可以关掉桌面UI,也可以考虑换一块5700G集显负担桌面UI的性能。感觉5700G也足够了,除非用X3DCPU才会有所区别,延迟会好一点。

                  Ivan YinI 1 条回复 最后回复
                  0
                  • 你 你的名字我的名字都是一样的

                    可以关掉桌面UI,也可以考虑换一块5700G集显负担桌面UI的性能。感觉5700G也足够了,除非用X3DCPU才会有所区别,延迟会好一点。

                    Ivan YinI 离线
                    Ivan YinI 离线
                    Ivan Yin
                    编写于 最后由 编辑
                    #27

                    @你的名字我的名字都是一样的 说:

                    可以关掉桌面UI,也可以考虑换一块5700G集显负担桌面UI的性能。感觉5700G也足够了,除非用X3DCPU才会有所区别,延迟会好一点。

                    也是个思路,现在9x00x系列的amd也带核显了,如果是新amd平台或者带核显的intel平台(非e5),确实可以这样操作

                    1 条回复 最后回复
                    0
                    • ,系统 取消固定了此主题
                    • Ivan YinI Ivan Yin

                      更正上面的测试,编写汉语文章是43t/s,但是coding的速度远大于这个,稳定在60左右,完全是可用状态,没有必要为了节省显存或追求最高速度,降低精度了

                      截图 2026-06-13 21-41-56-s.jpg
                      截图 2026-06-13 21-44-30.png

                      截图 2026-06-13 21-45-40.png

                      J 离线
                      J 离线
                      joker_chang
                      德高望重 劳动模范
                      编写于 最后由 joker_chang 编辑
                      #28

                      @Ivan-Yin

                      【--spec-type draft-mtp ^
                      --spec-draft-n-max 3 ^】
                      实施效果呢......

                      我的3090跑Qwen3.6-27B-unslothMTP-Q4_K_M.gguf,Hermes coding能稳定60~70t/s;最快能到80多t/s

                      当然,受限于显存大小,只能
                      【
                      --ctx-size 131072 ^
                      --batch-size 4096^
                      --ubatch-size 2048 ^
                      --flash-attn on ^
                      --cache-type-k q4_0 ^
                      --cache-type-v q4_0 ^
                      】

                      d5b46d03-1270-49d8-90b9-bcbb8294483b-image.jpeg

                      1 条回复 最后回复
                      1
                      • J 离线
                        J 离线
                        joker_chang
                        德高望重 劳动模范
                        编写于 最后由 joker_chang 编辑
                        #29

                        刚才试用了lordx64\Qwable-v1.IQ4_XS.gguf

                        启动参数【
                        --reasoning off ^
                        --n-gpu-layers -1 ^
                        --ctx-size 262144 ^
                        --batch-size 4096^
                        --ubatch-size 2048 ^
                        --flash-attn on ^
                        --cache-type-k q8_0 ^
                        --cache-type-v q8_0 ^
                        --temp 0.7 ^
                        --parallel 1 ^
                        --kv-unified ^
                        --mlock ^
                        --jinja
                        】

                        生辰tokens能跑到120多/秒;但是这个模型有些蠢,我放弃了。

                        1 条回复 最后回复
                        0
                        • nami ryuuN 离线
                          nami ryuuN 离线
                          nami ryuu
                          编写于 最后由 编辑
                          #30

                          @ivan-yin 我想问你是在哪家买的4090d 48g,声音大吗?

                          williamlouisW 1 条回复 最后回复
                          0
                          • nami ryuuN nami ryuu

                            @ivan-yin 我想问你是在哪家买的4090d 48g,声音大吗?

                            williamlouisW 在线
                            williamlouisW 在线
                            williamlouis
                            超级版主
                            编写于 最后由 编辑
                            #31

                            @nami-ryuu 大。峰值工作噪音过75分贝

                            个人主页:xlkj.org Telegram https://t.me/xlkjorg

                            1 条回复 最后回复
                            0

                            你好!看起来您对这段对话很感兴趣,但您还没有一个账号。

                            厌倦了每次访问都刷到同样的帖子?您注册账号后,您每次返回时都能精准定位到您上次浏览的位置,并可选择接收新回复通知(通过邮件或推送通知)。您还能收藏书签、为帖子顶,向社区成员表达您的欣赏。

                            有了你的建议,这篇帖子会更精彩哦 💗

                            注册 登录
                            回复
                            • 在新帖中回复
                            登录后回复
                            • 从旧到新
                            • 从新到旧
                            • 最多赞同


                            • 登录

                            • 没有帐号? 注册

                            • 第一个帖子
                              最后一个帖子
                            0
                            • 版块
                            • 最新
                            • 标签
                            • 热门
                            • 用户
                            • 群组