1. 拆开 A3B 这个后缀35B 总参数为什么敢往家用卡里塞标题里那串1923我猜多半是某个任务仓库里的条目编号跟技术本身没太大关系真正有信息量的是后半段35B-A3B。很多朋友第一次看到这个型号会懵35B 的模型一个 24G 显存的卡凭什么跑是不是又是那种跑起来了但一句话要等半分钟的能跑这两个问题的答案都藏在 A3B 这三个字符里把它读懂了后面的部署和调优才有地基。我把它拆成两个数字看35B 是总参数量A3B 指的是每次前向计算实际激活的参数量大约在 3B 量级。也就是说这是一个典型的稀疏混合专家MoE结构——模型内部有很多组专家子网络每处理一个 token路由网络只挑其中少数几个专家参与计算剩下的专家安静地待在显存里不干活。这带来一个非常反直觉的结论这个模型的显存占用像 35B 模型计算开销却接近 3B 稠密模型。对本地部署来说这是一个贵的部分刚好可以省钱便宜的部分刚好可以多花的结构理解这一点你才知道该往哪个方向调优。1.1 MoE 的显存贵、算力便宜错配用一个生活化的类比35B 稠密模型像一个所有科室都要会诊的医院每来一个病人全院专家都得到场人越多越慢诊室也得越多MoE 模型像分诊台先判断病情只叫对应科室的两三个医生其他医生在办公室坐着。诊室显存还是得给全院专家准备但真正同时在手术台上的人算力很少。这个结构对你的硬件意味着什么分两句话显存是硬门槛几乎不能让。所有权重都得驻留在显存或内存里一个专家没加载上就是加载失败或者被迫走 CPU 卸载速度瞬间掉一个数量级。显存够了以后算力余量很大。因为激活参数只有 3B 级别你的 GPU 计算单元吃不满往往先撞上的是显存带宽和 KV Cache 的墙而不是 FLOPS 的墙。这解释了一个常见现象同样一张卡跑 35B 稠密模型是卡死跑这个 A3B 版本却是居然还挺流畅。不是模型变聪明了是计算路径变窄了。1.2 一张表算清你的显存够不够估算方法其实不复杂权重占用 参数量 × 每参数字节数再留出 KV Cache、激活值、框架开销的余量。下面这张表是我按常见量化档位算的你可以直接对号入座。注意 35B 我只按整数近似算实际以模型权重文件大小为准误差几十 MB 很正常。量化档位每参数约占用权重显存估算建议最低显存实际体感FP16 / BF162.0 byte约 70 GB80 GB 级原汁原味家用基本无缘Q8_0 / INT8约 1.06 byte约 37 GB48 GB 级质量几乎无损双卡或大显存单卡Q6_K约 0.82 byte约 29 GB40 GB 级甜点偏上长上下文更稳Q5_K_M约 0.71 byte约 25 GB32 GB 级质量与体积平衡得很好Q4_K_M约 0.60 byte约 21 GB24 GB 级需压缩上下文家用最现实的主力档Q3_K_M约 0.48 byte约 17 GB20 GB 级能跑但中文长文容易掉细节Q2_K约 0.36 byte约 13 GB16 GB 级应急用不建议正式使用看这张表有个关键信息容易被忽略24G 卡跑 Q4_K_M 只有 3G 左右的余量。这 3G 要装 KV Cache、装框架自身的运行时缓冲、装 CUDA 上下文这一项在部分框架里就能吃掉 500MB 到 1GB。所以真正留给上下文的钱很少这也是为什么很多人权重加载成功了一开长上下文就 OOM。我在第一次部署时就是栽在这里后面第 4 节会细讲怎么算这笔账。1.3 量化档位的选择逻辑不是越小越好新手最容易犯的错是为了保险直接上 Q3 甚至 Q2结果发现模型中文表达开始飘、代码块括号对不上、长文总结漏要点然后怀疑是模型本身不行。实际上量化损失是非线性的Q8 到 Q4 的损失很平缓Q4 到 Q3 开始有肉眼可见的退化Q3 以下在中文和数学上会明显掉链子。我的建议顺序是这样的优先保证 Q4_K_M 及以上。宁可把上下文从 32K 降到 16K也别把量化降到 Q3。上下文短了你可以靠分段喂量化掉了是真救不回来。如果显存刚好卡在临界点先试 Q4_K_S 而不是 Q3_K_M。Q4_K_S 比 Q4_K_M 小一点损失比跨档小得多。Q5 及以上只在你确实需要高精度任务时才值得。比如做结构化抽取、代码审查这类对细节敏感的场景Q6_K 的稳定度比 Q4 高一截代价是显存需求直接跳一个档。再补一句实操心得同一个模型的不同量化版本不要混着测试然后下结论。我见过有人用 Q4 跑出乱码就断定这个模型中文不行其实是他下载的那份 GGUF 转换脚本版本太老词表处理有问题。换一份来源可靠的权重同一个量化档表现完全不同。2. 环境盘点真正把部署卡住的通常不是显卡大部分人做本地部署的第一反应是查显卡型号、查显存大小然后就开始下载权重。我自己踩过的坑里真正让部署卡住半天以上的显卡问题反而最少。磁盘空间不够、内存太小导致加载时疯狂换页、编译工具链版本对不上、下载的权重文件其实是半截这些才是高频故障源。这一节我按部署前必须盘一遍的顺序过一遍。2.1 磁盘、内存与加载耗时先说磁盘。一个 Q4_K_M 的权重文件就是 20 GB 出头如果你的机器上还留着 FP16 原版70 GB、几个不同量化版本、加上转换过程中的中间文件200 GB 的盘很快就见底。我习惯的做法是单独划一个目录只保留当前在用的那一两个版本转换脚本的输出目录设成临时盘跑完就删。格式也很关键。权重放在机械盘上冷启动加载 20 GB 大概要几分钟放在 SATA 固态上几十秒放在 NVMe 上十几秒。这个差别在调试阶段会被放大——你改一个参数要重启一次服务一晚上重启二十次机械盘就是纯受罪。我的经验是权重目录必须放固态不要省这个钱。内存这一项经常被低估。加载权重时框架通常要先把文件读进内存再拷贝到显存峰值内存占用可能接近甚至超过权重体积。如果你只有 16 GB 内存去加载 20 GB 的模型系统会开始疯狂换页表现是进度条卡在 60% 不动了看起来像死机其实是在拿硬盘当内存用。建议内存至少是权重体积的 1.5 倍64 GB 是个比较舒服的档位。另外如果你打算做专家卸载把部分专家放内存内存需求还要往上加这个第 4 节细说。2.2 编译工具链与运行时版本对齐llama.cpp 这类需要自己编译的后端版本对齐是绕不过去的。我整理了一份版本三件套的检查清单出问题时按这个顺序查能省掉大量瞎试驱动版本先看驱动支持的运行时上限再决定装哪个版本的运行时。装了个比驱动新的运行时报错信息通常非常隐晦只说找不到设备。运行时版本CUDA 运行时的大版本要和编译时用的一致。用 12.x 编译的二进制拿到只有 11.x 运行时的机器上跑会直接报缺库。编译参数-DGGML_CUDAON这类开关一定要显式打开默认编译出来是纯 CPU 版本。我第一次编译完兴冲冲跑起来发现速度只有 2 token/s查了半天才发现编译日志里 CUDA 那一行写的是 OFF。一个很实用的小技巧编译完成后不要急着跑模型先跑后端自带的设备信息查询llama.cpp 的llama-cli --list-devices之类确认它真的识别到了你的卡、显存读数对不对。这一步 30 秒能挡掉后面几小时的困惑。2.3 权重完整性校验与被忽略的静默损坏这一条我认为是最值得单独拎出来讲的。大文件下载中断、分片合并出错、磁盘坏块都会导致权重看起来在、实际是坏的。表现非常有迷惑性加载不报错推理不报错但输出质量诡异——比如前面几句正常后面开始胡言乱语或者同样的 prompt 每次结果差异巨大。我的处理流程是这样的下载完成后核对文件大小和发布页标注的字节数对齐差 1 字节都不行。如果有校验值就核对校验值这是最可靠的。如果没有校验值做一次冒烟测试用一句固定的话让模型续写比如让它解释一个简单概念看输出是否通顺、是否在合理长度内自然结束。这一步能挡掉大部分静默损坏。分片权重合并后检查合并后的文件头和分片数是否匹配有些合并脚本出错时会安静地生成一个截断文件。提示遇到过好几次模型变笨的案例最后查出来都是权重文件不完整。排查顺序上先怀疑文件再怀疑参数最后才怀疑模型能力这个顺序能帮你少走很多弯路。3. 三套后端跑同一份权重选型不靠感觉靠场景同一个模型换不同推理后端体验能差出好几倍。市面上主流的几条路线各有明确的适用边界选错了不是稍微慢点而是根本没法用。我按自己的使用经验把三条路线拆开讲最后给一个对照表。3.1 llama.cpp 路线单机单卡的性价比之王llama.cpp 是我在单机单卡场景下的默认选择。它最大的价值不是速度而是对混合精度和分层卸载的控制粒度。对于 MoE 模型它支持把注意力层和部分专家留在显存、把其余专家放到内存或 CPU这个能力在显存刚好不够的时候就是救命稻草。典型启动命令长这样我按 24G 卡跑 Q4_K_M 的配置写的./llama-server \ -m ./models/qwen3.6-35b-a3b-Q4_K_M.gguf \ -c 16384 \ -ngl 99 \ --n-cpu-moe 10 \ -t 12 \ -b 2048 -ub 512 \ --flash-attn \ --host 0.0.0.0 --port 8080这里每个参数背后都有一笔账我不建议你抄完就走-ngl 99意思是尽量把所有层都放显存99 是个全放的习惯写法。--n-cpu-moe 10是把 10 层专家推到 CPU用来给显存腾空间。这个数字不是拍脑袋是从显存缺口 ÷ 单层专家占用算出来的第 4.2 节有具体算法。-c 16384是上下文长度这个值直接决定 KV Cache 大小是显存第二大开销。-b 2048 -ub 512是批大小和微批大小影响 prefill 阶段的并行度。调大 prefill 更快但瞬时显存峰值更高24G 卡上 512 的微批是个比较安全的起点。--flash-attn打开后注意力和 KV Cache 的显存效率会明显改善长上下文场景基本必开但要注意它和某些量化格式存在兼容问题开之前先小上下文验证一次。速度预期方面24G 卡跑 Q4_K_M、16K 上下文、纯 GPU 的情况下生成速度大概在 25 到 40 token/s 这个区间具体取决于你的卡和内存带宽。一旦启用 CPU 专家卸载速度会掉到 10 到 15 token/s这是正常的因为专家计算被拉到了内存带宽这条慢路上。3.2 vLLM / SGLang 路线吞吐场景的唯一选择如果你要做的是多人同时用或者批量跑几千条数据那 llama.cpp 就不合适了。它的架构是围绕单请求低延迟设计的并发上来以后吞吐上不去。这时候该换 vLLM 或 SGLang核心能力是PagedAttention 加连续批处理——把不同请求的 KV Cache 切成固定大小的块统一管理显存碎片大幅减少多个请求可以混在一个批次里推进。vllm serve ./qwen3.6-35b-a3b \ --max-model-len 16384 \ --gpu-memory-utilization 0.90 \ --max-num-seqs 16 \ --enable-chunked-prefill \ --quantization gptq几个关键点--gpu-memory-utilization控制框架愿意占用的显存比例0.90 是个常用值留 10% 给其他进程和碎片。这个值不要设到 0.98 以上很容易在长请求时 OOM。--max-num-seqs是并发序列上限调大吞吐上升但单请求延迟变差需要按业务权衡。--enable-chunked-prefill对长 prompt 场景很关键它把 prefill 拆成块避免一个超长请求把整个批次堵住。这条路线的问题也很明确对量化的支持不如 llama.cpp 灵活很多量化格式需要预先转换启动时间长权重加载动辄几分钟显存管理激进配置不当容易在压测中途崩。它适合部署一次长期跑的场景不适合改个参数试一下的调试节奏。3.3 Ollama便捷性是被封装掉的自由度Ollama 的最大优点是五分钟能跑起来改个模型名就行。但它的代价是把关键参数藏起来了。上下文长度、专家卸载层数、批大小这些在 llama.cpp 里能精细控制的东西在默认配置下你基本碰不到只能通过 Modelfile 里的有限几个字段去调。我的一般态度是Ollama 适合做快速验证和轻量日常使用不适合做深度调优。如果你想搞清楚这个模型在你的机器上到底能跑多快、能撑多长上下文最终还是得回到 llama.cpp 那一层去。用 Ollama 做出模型不行的判断大概率是冤枉了模型——它默认的上下文长度往往只有 4K 左右你喂一篇长文进去它当然答非所问。3.4 四维对比与我的选择顺序维度llama.cppvLLM / SGLangOllama上手成本中等需编译中等偏高需转换量化极低单请求延迟优秀一般良好并发吞吐弱优秀弱参数控制粒度非常细细偏服务化粗显存不足时的容错强可分层卸载弱中等适合场景单机单人、深度调优多人服务、批量推理快速体验我的选择顺序很固定先在 Ollama 上花五分钟确认模型能正常说话再切到 llama.cpp 做参数调优确定最佳配置最后如果要上线服务才考虑 vLLM 那条路。跳过第一步直接上 vLLM往往会把环境没配好误判成模型有问题。4. 启动参数逐项拆解上下文长度与专家卸载是最容易翻车的两处参数这块我不想给你一张推荐配置表就完事因为不同卡、不同场景的最优值差别很大。我更愿意把三个最关键的参数背后的算法讲清楚你自己算一遍比抄十个配置有用。4.1 context 不是越大越好KV Cache 的显存账KV Cache 的占用可以按这个式子估KV Cache 字节数 ≈ 2 × 层数 × KV头数 × 每头维度 × 序列长度 × 批大小 × 每元素字节数拿一个典型配置举例层数 48KV 头数 8用了分组查询注意力比注意力头数少很多每头维度 128FP16 每元素 2 字节。那么单条序列、每 1K token 的 KV Cache 是2 × 48 × 8 × 128 × 1024 × 2 ≈ 200 MB也就是说每增加 1K 上下文显存多吃 200MB 左右。32K 上下文就是 6.4 GB这个数字放在 24G 卡上、权重已经占了 21G 的情况下直接就是不可能。这就是为什么很多人权重加载成功一开 32K 就 OOM。所以上下文长度的确定逻辑应该反过来算可用显存 总显存 - 权重 - 框架开销 - 余量再用可用显存反推能吃多少 K。我 24G 卡的实际配置是权重 21G框架开销约 1G留 0.5G 余量剩 1.5G 给 KV Cache算下来 7K 左右所以我把上下文设成 8K 并接受偶尔的紧张而不是硬上 16K。有个小技巧能缓解这个矛盾如果后端支持 KV Cache 量化比如把缓存降到 8 位同样显存能多吃接近一半的上下文代价是长文场景的召回精度轻微下降。我在做长文摘要时会把这一项打开实测效果损失可以接受。4.2 专家卸载的粒度与踩坑专家卸载是 MoE 模型本地部署最核心的调优手段也是坑最多的。逻辑很直白显存不够就把一部分专家放到内存里用到的时候再传过来算。问题在于传过来这件事的开销极大PCIe 带宽相比显存带宽差一个数量级一旦卸载的层数过多速度会雪崩。卸载层数的估算方法先算出显存缺口比如权重 24G、可用 22G缺口 2G。查单层专家的占用MoE 层参数量通常远大于注意力层假设每层 200MB。缺口 ÷ 单层占用 10 层。但这只是起点。实际调的时候要小步试探从缺口算出来的层数往上加两三层跑一次压测看速度再往回减找到刚好不 OOM 且速度可接受的那个点。我在 24G 卡上的经验是卸载 8 层以内速度损失在 30% 左右还能用超过 15 层就进入每句话要等好几秒的区间不如直接降到 Q3 量化。注意不同后端对层的定义不一样有的按 MoE 层算有的按总层数算。第一次用某个后端时先用小上下文、少层数跑一次看它的日志里报的显存占用和你的估算对不对得上对不上就说明口径不同别硬套公式。还有一个隐蔽的坑卸载层数配置和--flash-attn有时会冲突表现为加载时直接崩或者输出全乱。遇到这种情况先把 flash attention 关掉验证一次确认是兼容问题再去找对应版本的修复不要盲目怀疑权重。4.3 采样参数MoE 模型比稠密模型更怕重复惩罚过度采样参数这块MoE 模型有个和稠密模型不太一样的特点它对重复惩罚更敏感。原因是 MoE 在不同 token 上激活不同专家输出分布的连贯性本来就比稠密模型弱一些你把重复惩罚调高容易把原本正常的措辞也压掉表现为用词突然变得非常单调、句式重复、或者干脆开始输出奇怪符号。我的起步配置是这样的{ temperature: 0.7, top_p: 0.9, top_k: 40, repeat_penalty: 1.05, presence_penalty: 0.0, frequency_penalty: 0.0 }几个判断依据repeat_penalty我给到 1.05 就够超过 1.15 在中文场景下经常出问题top_p0.9 是个比较稳的档需要确定性输出比如结构化抽取时把temperature降到 0.2 以下同时把top_k收窄到 10 以内。另外如果模型带思维链输出注意思维链部分和最终答案部分对采样的敏感度不同有些后端支持分段设置值得花时间调一下。5. 压测与调优把首字延迟和生成吞吐分开看调优最容易犯的错是跑一段对话感觉一下快慢这种主观感受完全无法定位问题。必须把指标拆开**首字延迟TTFT**反映的是 prefill 阶段的效率**生成速度TPOT 或 tokens/s**反映的是 decode 阶段的效率两者的瓶颈往往完全不同优化手段也完全不同。5.1 压测脚本与指标口径我平时用的最小压测脚本大概长这样重点是把两个指标分开计时import time, json, statistics import requests URL http://127.0.0.1:8080/v1/chat/completions def bench(prompt, max_tokens256, rounds5): ttfts, speeds [], [] for _ in range(rounds): payload { messages: [{role: user, content: prompt}], max_tokens: max_tokens, temperature: 0.2, stream: True } t0 time.time() first None tokens 0 with requests.post(URL, jsonpayload, streamTrue, timeout300) as r: for line in r.iter_lines(): if not line or not line.startswith(bdata: ): continue body line[6:] if body b[DONE]: break chunk json.loads(body) delta chunk[choices][0].get(delta, {}) if delta.get(content): tokens 1 if first is None: first time.time() t1 time.time() if first and tokens 1: ttfts.append(first - t0) speeds.append((tokens - 1) / (t1 - first)) return statistics.mean(ttfts), statistics.mean(speeds) print(bench(用三百字解释一下稀疏激活的基本原理))关键是必须用流式接口非流式拿不到首字时间只能拿到总耗时这个指标对你的调优几乎没指导意义。跑的时候注意预热第一次请求会把权重从内存搬到显存、建立各种缓存数据一定偏慢所以前一两轮直接丢掉。5.2 瓶颈定位的顺序我的定位顺序固定是这三步从上往下查能覆盖九成情况看显存占用是不是贴着上限。如果显存用到 99%说明已经在 OOM 边缘任何波动都会触发重试或降级速度自然不稳。先把上下文或卸载层数降一档让显存留出 5% 到 10% 的余量。看首字延迟是不是异常高。首字延迟主要花在 prefill 上如果 prompt 只有几百字首字延迟就有好几秒说明 prefill 的并行度不够可以调大微批大小如果首字延迟正常但长 prompt 特别慢那可能是没开分块 prefill。看生成速度是不是远低于预期。生成阶段是逐 token 的理论速度受内存带宽限制。如果实测只有理论值的三分之一基本可以判定有专家被卸载到了 CPU去看日志里的卸载信息确认。下面这张表是我遇到过的一些症状和对应的排查方向可以直接拿去对照症状最可能原因处理方向加载成功、首字延迟 5s 以上prefill 批太小或未开分块调大微批、开启分块 prefill生成速度 10 tokens/s专家被大量卸载到 CPU降量化档位或少卸载几层长上下文后半段开始乱答上下文实际被截断核对运行时真实 context 值并发两个请求就崩并发上限配置过高降 max-num-seqs或换服务化后端输出重复、句式单调重复惩罚过高降到 1.05 附近5.3 一组实测配置对照我在一张 24G 卡上做过几组对照同一份 Q4_K_M 权重、同一段测试 prompt数据供你参考不同卡差异会很大绝对值不重要看趋势配置上下文卸载层数首字延迟生成速度结论A4K00.6s33 tok/s速度最好上下文太短B8K00.7s31 tok/s临界点偶发 OOMC8K80.9s14 tok/s稳定速度可接受D16K121.2s9 tok/s能用但难受仅长文场景E8K8开 KV 量化0.9s13 tok/s稳定且能撑 12K综合最优从这组数据能看出一个很反直觉的结论B 和 C 之间只差 8 层卸载速度掉了一半多但稳定性天差地别。日常使用我会选 C 或 E宁可慢一点也不要跑到一半崩掉。A 那种看着快的配置实际用起来每次都要担心反而最烦人。6. 六个真实坑位的完整排查链路这一节我按自己踩坑的时间顺序写每个坑把排查路径完整列出来因为结论本身没价值路径才有——你遇到的问题大概率不是我遇到的这个但排查思路是可以复用的。6.1 显存看着够却 OOM第一次遇到时我的判断是显存明明还有 2G怎么会 OOM。排查路径是这样的先看报错的具体位置。如果是加载阶段就 OOM说明是权重本身就放不下估算错了如果是推理中途 OOM说明是动态开销KV Cache 增长导致的。这两种情况的处理完全不同。再看上下文是不是真的按你设的值在跑。我用过一个前端工具它在请求里偷偷塞了个很大的 max_tokens导致实际分配远超预期。后来改成直接在命令行压测问题消失。检查框架的预留显存。有些后端会预留一大块显存做缓冲这个值是可配的默认值在小卡上可能就是压垮骆驼的那根稻草。最后用显存监控工具看曲线。如果显存是缓慢爬升然后崩那是 KV Cache 没释放属于后端 bug 或者缓存策略问题如果是瞬间跳上去然后崩那是单次请求的峰值太高降批大小。我最后定位到的原因是gpu-memory-utilization设成了 0.95框架按 0.95 去规划 KV Cache 块但实际运行时还有其他进程占了显存规划值和实际值对不上于是在边界上反复触发重分配。改成 0.88 之后一次都没再复现。6.2 长上下文后半段开始乱答症状很典型喂一篇两万字的长文让它总结前半部分总结得挺好后半部分要么跳过、要么答非所问、要么直接开始幻觉。我一开始以为是模型长上下文能力不行差点放弃。排查过程先确认运行时真实生效的上下文长度。很多工具的默认值是 4K 或 8K你在配置文件里改了但没生效或者前端把超长 prompt 直接截断了。我用了最笨的办法——让它复述 prompt 的最后一句如果复述不出来就是被截断了。确认位置编码的缩放配置。模型训练时的上下文长度和你要用的长度不一样时需要开启位置插值或相应的缩放。这一项没开超出训练长度的部分表现会急剧下降。检查 KV Cache 是否被量化过度。我试过把 KV Cache 压到很低的位数8K 以内没问题16K 就开始丢细节。恢复默认精度后恢复正常。最后的结论是第二项——我没有启用对应的长上下文配置模型虽然在跑但位置编码是外推的理论上能算实际精度崩了。开启正确的缩放配置后同样的长文任务表现完全不一样。这个坑让我记住一件事能跑通和跑对是两回事长上下文尤其如此。6.3 输出反复重复与思维链跑飞这个坑最烦人因为表现不稳定时好时坏。症状是模型偶尔陷入循环反复输出同一句话或者思维链部分越写越长绕来绕去不收敛。我按这三步排查先排除采样参数。把重复惩罚从 1.2 降到 1.05温度从 0.9 降到 0.7看是否缓解。这一步解决了我七成的情况。再排除 prompt 问题。有些 prompt 的结构会诱导模型进入循环比如让它尽可能详细地列出所有可能这种开放式要求容易跑飞。改成给出明确的长度限制和结构要求情况明显好转。最后怀疑推理引擎。换一个后端跑同样的 prompt如果问题消失那基本可以定位到后端的采样实现或者批处理逻辑有偏差。我遇到的那次最终定位到第三个某个版本的后端在处理流式输出时对已生成 token 的惩罚统计有偏差导致长输出越到后面越容易重复。升级版本后解决。提示判断是模型问题还是引擎问题有个很省事的办法——同一份权重、同一个 prompt在两个不同后端各跑一次。表现一致就是模型或权重的问题表现不同就是引擎的问题。这个二分法能帮你砍掉一半的排查范围。6.4 权重格式转换时的静默降级还有一个不太常见但很阴的坑做量化转换时某些层因为格式不支持被静默跳过了转换日志里只有一行不起眼的警告你不仔细看根本发现不了。结果是模型能跑但那几层其实是原始精度或者干脆是随机初始化输出质量明显下降但又不至于完全乱来。我的应对办法是转换完成后必须看完整日志特别关注 warning 和 skip 字样并且对比转换前后的张量数量是否一致。这一步花两分钟能避免后面花两小时怀疑人生。7. 最后几句实在话本地部署这类稀疏激活的大模型真正的门槛从来不是能不能跑起来而是跑起来的这个配置你敢不敢拿它干活。我见过太多人花了半天把模型跑通截个图发出去然后再也没打开过——因为速度太慢、上下文太短、动不动就崩。我的建议是把精力放在找到一个稳定可用的平衡点上而不是追求极限参数。宁可接受 15 tokens/s 和 8K 上下文也不要追求 33 tokens/s 然后每分钟崩一次。上面第 5.3 节那张对照表里我最后长期在用的是配置 E它不漂亮但一个月没出过事。另外分享一个我自己的习惯每换一次硬件、每升一次后端版本都重新跑一遍那三组基准测试短 prompt、长 prompt、并发两个请求把数据记在一个小表格里。时间长了你会发现很多感觉变慢了其实是错觉而真正的性能回退只有数据能告诉你。这套记录帮我抓到过两次版本升级导致的性能退化都是官方更新说明里没提的。