把一个大模型塞进一台没有独立显卡的小机器里还要它稳稳当当地往外吐字——三年前这听起来像在为难人现在只要平台选对、量化档位选对、显存这笔账算明白一个下午就能跑通。这篇记录的就是我在 AMD 平台上把 Qwen3.8-Flash-Next 从零部署起来并把出字速度从最初可怜的 8 tok/s 一点点调到 25 tok/s 的全过程。内容包括我为什么选这条路、显存和带宽该怎么算、驱动和推理后端怎么配、参数怎么调、服务怎么暴露出去以及那些只有真跑过才会遇到的坑。不管你手上是一台迷你主机、一台轻薄本还是一块嵌入式开发板只要它挂着 AMD 的核显或 NPU这里面的思路和命令基本可以直接抄。1. 方案选型为什么把 Qwen3.8-Flash-Next 放在 AMD 端侧1.1 端侧推理真正卡脖子的三件事很多人第一次尝试本地部署脑子里想的都是“参数量能不能塞下”实际上容量只是第一道门槛而且往往是最容易过的那道。真正决定这套东西能不能用的是三件事显存够不够放下权重加 KV Cache、内存带宽够不够喂饱解码过程、软件栈够不够成熟让你别把时间全花在编译报错上。这三件事里第一件靠量化解决第二件靠硬件架构决定且几乎无法绕过第三件靠生态积累。先说容量。端侧设备通常没有独立显存核显和 CPU 共享同一块内存所谓“显存”是从系统内存里划出来的一块。这意味着你的模型权重、KV Cache、系统本身、还有你开着的浏览器全都在抢同一块物理内存。我见过太多人把模型塞进去了结果跑两个回合系统开始疯狂换页速度直接掉到个位数。所以做端侧部署第一原则不是“能不能放下”而是“放下之后还能不能留出余量”。再说带宽。大模型的解码阶段本质上是内存带宽的搬运工每生成一个 token都要把几乎全部权重从内存读一遍。注意是“读一遍”不是“算一遍”。这就决定了在端侧你的出字速度上限几乎完全由内存带宽除以模型体积决定跟 GPU 有多少个计算单元关系不大。这条规律非常重要它能解释为什么你把核显频率拉高、把线程数调满速度可能只涨了 10%但换个更高频的内存条速度立刻涨 30%。最后是软件栈。这一块是 AMD 平台历史上最被人诟病的地方但这两年变化很大主流的推理框架基本都有了可用的后端。关键是你要知道自己的芯片对应哪个编译目标、哪个后端在该架构上已经跑顺了、哪个还在早期阶段。1.2 为什么是 Qwen3.8-Flash-Next 这个模型选模型这件事端侧和云端完全是两套逻辑。云端看的是能力上限端侧看的是“单位显存的能力密度”。Qwen3.8-Flash-Next 这个版本我理解是 Flash 系列的延续设计取向很明确参数规模控制在几 B 的量级同时通过分组查询注意力GQA把 KV Cache 压下来上下文窗口给得比较宽首字延迟做得比较低。这几个特性恰好是端侧最需要的。我把它拆成三个维度看权重体积可控原始精度转成 4bit 量化后大概 2.3~2.5 GB 这个量级意味着在一块从系统内存里划出 4~6 GB 给核显的机器上你能同时留出足够的 KV Cache 空间和系统余量。这个体积区间我认为是端侧的“甜点区”再大就得开始牺牲上下文再小能力又明显不够用。KV Cache 友好GQA 让每个 token 在每层只需要存很少的 K/V 头。同样是 8K 上下文普通多头注意力的 KV Cache 可能是它的四倍。端侧最怕的就是“权重不大但上下文一开就爆”这个模型在这一点上踩得比较准。指令跟随和结构化输出够用端侧场景绝大多数不是开放式创作而是分类、抽取、改写、摘要、意图识别、格式化输出这类任务。这类任务对模型的“知识广度”要求不高对“指令遵循稳定性”要求很高。这也是我建议端侧别去追最大参数版本的原因。需要说清楚它的边界如果你的场景是需要长文档深度推理、多轮复杂工具调用、或者高质量代码生成端侧几 B 的模型只能算“能用”不要指望“好用”。我一般会把端侧模型定位成“第一道过滤层”——简单请求本地消化复杂请求往上转这样既省延迟又省成本。1.3 三条硬件路线的取舍对比在同一块 AMD 平台上其实有三条路可以走各自的适用场景差别很大路线典型后端优点明显短板适用场景纯 CPUCPU 指令集优化后端最稳、零依赖、任何机器都能跑速度最慢通常只有个位数 tok/s一次性验证、CI 环境、临时应急核显iGPUHIP / Vulkan 后端速度提升明显通常能到 CPU 的 2~3 倍需要正确匹配芯片架构编号驱动版本敏感长期跑量的主力方案NPU厂商专用运行时 图编译功耗最低CPU 占用几乎为零算子覆盖不全模型需要预处理成特定图格式调试困难常开常驻、电池供电、对功耗敏感的产品我自己的选择是“核显主力 CPU 兜底”NPU 作为后续优化方向。理由很实在核显这条路的后端成熟度已经够用模型格式和社区生态完全打通改个参数就能跑NPU 虽然功耗香但一旦模型里有不支持的算子你会被迫做模型切分工作量直接翻几倍。做端侧项目最怕的就是前期在工具链上耗掉大半时间所以我一般建议先用核显把整条链路跑通、把业务验证做完再考虑把某些固定子图挪到 NPU 上。提示三条路线的选择不是一锤定音的。我通常会在项目开始时就把“可切换后端”作为架构前提写进设计里也就是推理层做一层薄封装底层换后端不影响上层业务代码。后面你会庆幸这一点。2. 动手前先算账显存、带宽与上下文的精确估算2.1 权重显存与量化档位的选择逻辑量化不是“越低越好”它是一个精度和速度的权衡曲线而且在端侧这条曲线上有个明显的拐点。我按 4B 参数这个量级给你算一笔账以下按双字节浮点、无稀疏的结构估算具体数值以你手上模型的张量形状为准精度格式每参数字节权重体积4B 规模我的评价FP16 / BF162.0约 8.0 GB端侧基本别想除非你机器内存特别大且只做验证Q8_0约 1.06约 4.3 GB质量几乎无损但体积偏大速度明显偏慢Q6_K约 0.82约 3.3 GB折中选择质量损失极小Q5_K_M约 0.72约 2.9 GB甜点偏上质量稳Q4_K_M约 0.60约 2.4 GB端侧首选速度与质量平衡最好Q3_K_M约 0.49约 2.0 GB体积优势不大质量下滑明显不推荐Q2_K约 0.36约 1.5 GB只在极度缺内存时用回答会开始“跑题”这里有个反直觉的点Q4_K_M 到 Q3_K_M 体积只降了 0.4 GB但质量掉得比 8bit 到 4bit 那一档还狠。原因是低比特量化对异常值通道特别敏感K-quant 系列在 4bit 附近做了混合精度补偿往下走补偿空间就被挤没了。所以我的一般建议是要么 Q4_K_M要么 Q5_K_M不要贪那几百兆去降到 Q3。省下来的空间还不够你多开 2K 上下文。再补一个经常被忽略的成本量化本身不是零成本的它是“用一次转换换长期收益”。转换 4B 规模的模型在普通 CPU 上大概要十几分钟到半小时我的习惯是先转 FP16 存一份母本之后所有量化档位都从母本生成避免反复从原始权重转换引入误差累积。2.2 KV Cache 的计算公式与实测偏差KV Cache 是端侧最容易翻车的地方因为它随上下文长度线性增长而且很多人根本没把它算进预算里。公式不复杂每 token 的 KV 字节数 2 × 层数 × KV头数 × 头维度 × 每元素字节数 总 KV 占用 每 token 字节数 × 实际上下文 token 数 × 并发数拿一个典型的 GQA 配置举例32 层、8 个 KV 头、头维度 128、KV 用 FP16 存单层单 token2 × 8 × 128 × 2 4096 字节 4 KB全层单 token4 KB × 32 128 KB8K 上下文128 KB × 8192 ≈ 1.0 GB32K 上下文128 KB × 32768 ≈ 4.0 GB这个数字很关键。它意味着你如果为了跑 32K 上下文去部署光 KV Cache 就要吃掉 4 GB加上 2.4 GB 权重总共 6.4 GB再算上运行时开销和系统余量你至少得给核显划 8 GB 以上。而如果你的业务其实只需要 4K 上下文那 0.5 GB 就够了省下的 3.5 GB 完全可以用来提量化档位或做双实例。实测中还有一个偏差要提醒框架为了减少内存碎片通常会按块分配 KV实际占用会比理论值高 5%~15%而且开flash-attn类优化后布局会变占用可能小幅下降但不会消失。所以我算预算时习惯在理论值上乘 1.2 的安全系数。2.3 带宽决定天花板一个能在纸上算出来的速度上限前面说过解码阶段是带宽搬运工。这个判断可以直接量化解码速度上限 ≈ 有效内存带宽 ÷ 单 token 需要读取的字节数 有效内存带宽 ≈ 理论带宽 × 0.65 ~ 0.75共享内存架构的实际达成率拿一台双通道 LPDDR5-7500 的机器举例理论带宽大约 120 GB/s7500 MT/s × 16 字节总位宽实际有效按 0.75 折算约 90 GB/s。模型 Q4_K_M 约 2.4 GB那么理论上限约 90 ÷ 2.4 ≈ 37 tok/s。实际跑出来 25 tok/s 左右效率大约 68%这个比例在核显上是很正常的水准。这个公式的价值在于它能帮你快速判断“还有没有优化空间”。如果你实测 12 tok/s而纸面算出来上限是 37说明有 3 倍的坑没填值得继续折腾如果你实测 30 tok/s基本已经贴着天花板了再花时间就是浪费。预填充prefill阶段则是算力瓶颈和带宽关系不大通常能跑到几百 tok/s所以首字延迟主要看这一段的效率。注意共享内存架构下核显和 CPU 争抢带宽是常态。你在跑推理的同时开个视频或者文件拷贝tok/s 立刻掉一截。做压力测试时一定要关掉其他内存密集型任务否则数据没有参考价值。3. 环境搭建从驱动到第一个 token 的完整路径3.1 系统与驱动基线端侧部署最怕的不是难而是“版本地狱”。我的做法是先固定一个基线把版本号写进项目文档之后所有环境都按这个基线来。基线一般包含四样东西内核版本、GPU 驱动版本、计算运行时版本、推理框架的提交号。以 Linux 环境为例几个必须确认的点芯片架构编号这是整个流程里最容易出错的地方。你需要知道自己核显对应的gfx版本号编译后端时要显式指定否则框架会退回到一个非常慢的通用路径甚至直接报错。查法有很多最直接的是看系统日志里的显卡初始化信息或者用厂商提供的系统管理工具查设备属性。用户组权限把当前用户加进渲染设备相关的用户组否则你会遇到“能查设备但跑起来报权限拒绝”的诡异现象重登录才生效。内核参数共享内存架构下核显能用的“显存”其实由两部分组成——BIOS 里划的固定显存加上运行时动态借用的 GTT。后者默认往往偏小需要在启动参数里调大。# 确认设备被正确识别记下架构编号 sudo dmesg | grep -i amdgpu | head -20 # 确认当前用户权限 groups | tr \n | grep -E video|render # 运行时信息查设备与显存 rocm-smi --showproductname rocm-smi --showmeminfo vram3.2 编译带 GPU 后端的推理框架我不建议用系统包管理器装预编译版本因为预编译包为了兼容性往往不带对应架构的原生内核你会白忙一场。老老实实从源码编译虽然要等十几分钟但后面省心。git clone 框架仓库地址 llama-src cd llama-src cmake -B build \ -DCMAKE_BUILD_TYPERelease \ -DGGML_HIPON \ -DAMDGPU_TARGETSgfx1103 \ -DGGML_HIP_ROCWMMA_FATTNON cmake --build build -j$(nproc)几个参数值得解释一下而不是照抄-DGGML_HIPON开 HIP 后端。这是 AMD 平台上性能最好的通用后端比 Vulkan 后端通常快 15%~30%尤其在提示处理阶段。-DAMDGPU_TARGETS必须精确匹配你的芯片架构编号。写错不会有友好提示只会编译出一个跑不动的二进制。如果暂时不确定可以先用 Vulkan 后端跑通验证再回来补编译 HIP 版。-DGGML_HIP_ROCWMMA_FATTNON开启基于矩阵指令的注意力加速。这个选项对长上下文收益明显但对架构有要求低级架构开了可能反而更慢需要实测对比。编译完成后先跑一下内置的版本检查确认后端被识别到了这一步能省掉后面 90% 的排查时间。3.3 模型准备转换、量化、校验如果你拿到的是原始权重格式需要先转成推理框架能吃的格式再量化。我习惯保留一份 FP16 母本# 原始权重 - FP16 通用格式母本 python convert_hf_to_gguf.py ./Qwen3.8-Flash-Next \ --outfile qwen38-flash-next-f16.gguf \ --outtype f16 # 母本 - Q4_K_M 量化 ./build/bin/llama-quantize \ qwen38-flash-next-f16.gguf \ qwen38-flash-next-Q4_K_M.gguf \ Q4_K_M量化完之后一定要做一次“一致性抽查”别直接上生产。我的抽查方法是固定一组 10 条左右的典型业务输入分别用 FP16 和量化版跑一遍人工对比输出。关注三件事格式是否还稳定量化最常见的退化是 JSON 少个括号、关键实体有没有被改错、拒绝回答的边界有没有变松。这一步花十分钟能避免上线后被业务方投诉“模型变笨了”。3.4 第一次跑通最小可用命令先用最短的命令验证链路别一上来就堆参数./build/bin/llama-cli \ -m qwen38-flash-next-Q4_K_M.gguf \ -ngl 99 \ -c 4096 \ -t 8 \ -p 用一句话解释什么是端侧推理 \ -n 128-ngl 99的意思是“尽可能多地把层放到 GPU 上”写 99 是个惯例写法框架会自动按可用显存截断。如果这一条命令能流畅吐字说明驱动、后端、模型三件事都是通的可以进入调优阶段了。如果卡住不出字或者报错先去看第 6 节的排查表别急着改参数。4. 参数调优实战把 tok/s 一点点抠出来4.1 显存切分与 GTT 设置最容易被忽略的一步这一步的收益往往比调线程数大得多但大多数人根本不知道要调。共享内存架构下核显可用的内存分成固定分配和动态借用两部分。固定分配在 BIOS 里设动态借用由系统参数控制。默认的动态借用上限经常只有物理内存的一半甚至更少结果就是模型权重加载到一半报“显存不足”而你明明有 32 GB 内存。我的做法是BIOS 里把核显固定显存设成 4 GB如果你的机器有这个选项。设太大反而浪费因为固定部分是锁死的CPU 用不了。内核启动参数里把动态借用上限调大比如设成物理内存的四分之三。具体写法各发行版不同改完记得更新引导配置并重启。重启后用系统管理工具确认新的上限确实生效了别看文档说生效就信。提示GTT 调大之后理论上模型可以“装得下”但性能会打折因为动态借用部分的内存访问效率通常不如固定显存。所以我的策略是“固定显存装权重GTT 兜底装 KV Cache”尽量让热数据待在固定区。4.2 线程数、批大小与上下文长度的组合寻优这三个参数不是独立的必须一起调。我一般用控制变量法一次只动一个线程数这里是 CPU 侧线程负责采样、调度和部分算子。经验值是物理核心数的 0.5~0.75而不是“拉满”。我试过在一台 8 核机器上从 4 线程拉到 8 线程速度反而掉了 8%原因是线程争抢和核显调度打架。建议测 4、6、8 三档取最好的那个。如果你的机器有大小核混合架构记得把线程绑到大核上。批大小分逻辑批-b和物理批-ub两个。逻辑批影响提示处理的并行度物理批影响单次计算的显存峰值。端侧显存紧张我一般把物理批压到 128 或 256逻辑批给 512。物理批一味调大会导致显存峰值飙高然后 OOM调太小则提示处理效率上不去。我实测在 8K 上下文下物理批从 512 降到 256显存峰值降了约 0.3 GB提示处理速度只掉了 6%这笔买卖很划算。上下文长度按业务真实需要设别迷信“越大越好”。上下文从 8K 提到 32KKV Cache 从 1 GB 涨到 4 GB而且框架要为最坏情况预留可能直接把你挤到量化降档。我的一般原则是“实际最长输入的 1.5 倍”留点缓冲但不浪费。# 调优后的服务启动参数示例 ./build/bin/llama-server \ -m qwen38-flash-next-Q4_K_M.gguf \ -ngl 99 \ -c 8192 \ -t 6 \ -b 512 \ -ub 256 \ --flash-attn \ --host 0.0.0.0 \ --port 80804.3 功耗、散热与稳定性被低估的第三个变量端侧设备大多是小机箱或者笔记本散热余量很小。大模型推理是持续满载跑五分钟和跑五十分钟完全是两个状态。我遇到过最坑的一次是短测 25 tok/s连续跑二十分钟后掉到 14 tok/s查了半天以为是内存泄漏最后发现是核显温度到了阈值开始降频。几个具体做法限制功耗上限与其让它冲到高频然后过热降频不如主动把功耗墙设低一点让频率稳定。稳定在 80% 性能比在 100% 和 50% 之间反复横跳的体感好得多尤其是交互式场景。监控温度与频率用系统管理工具持续采样观察频率曲线是不是“锯齿状”。锯齿就是降频说明散热不够。调整风扇曲线如果机器支持把风扇起转点提前用噪音换稳定。端侧设备放在机柜或者角落时噪音其实不是问题。长稳测试别只测 30 秒。我的标准是连续跑 30 分钟、累计生成 2 万 token 以上观察速度衰减是否超过 15%。超过就说明散热或功耗策略有问题。调优前后我拿到的对比数据同一台机器、同一模型、8K 上下文、单并发阶段解码速度首字延迟显存峰值备注初始跑通默认参数8 tok/s2.8 s5.9 GB后端未匹配架构换 HIP 后端 正确架构16 tok/s1.1 s5.6 GB提升最大的一步调 GTT 固定显存 4G21 tok/s0.9 s6.2 GB消除了换页线程 6 物理批 25624 tok/s0.8 s5.9 GB细节优化功耗墙限制 风扇曲线25 tok/s长稳不衰减0.8 s5.9 GB稳定性收益从这张表能看出来真正的性能大头在前两步——后端匹配和内存配置。线程、批大小这些都是“最后一公里”别本末倒置。5. 服务化集成把本地模型变成能调用的接口5.1 暴露 OpenAI 兼容接口跑通之后第一件事是把命令行换成服务模式。原因很简单命令行只能你自己用服务能接到业务里。主流框架基本都自带兼容接口起服务的方式前面已经给过重点在于验证和接入。curl http://127.0.0.1:8080/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen38-flash-next, messages: [ {role: system, content: 你是信息抽取助手只输出JSON。}, {role: user, content: 把这句话里的时间和地点抽出来周五下午三点在B座三楼开会。} ], temperature: 0.1, max_tokens: 128 }几个我在端侧场景固定会设的参数温度压到 0.1 以下端侧模型本来就容易跑偏别再给它自由发挥的空间、max_tokens明确限制防止它长篇大论把你的吞吐吃光、结构化任务一定要给 system prompt 加格式约束。另外端侧服务建议关掉流式或者至少对下游做缓冲——端侧网络没问题但一个 token 一个 token 往下游推会放大调度开销。5.2 并发策略端侧不要追求高并发这一点必须说透端侧单实例的算力是固定的并发不会让你“同时干更多事”只会让每个请求都变慢。两个并发请求总吞吐可能只涨 20%但每个用户的等待时间翻倍。所以在端侧正确的做法是排队而不是并发。我的实现方式是单实例 请求队列队列里按优先级排超时直接返回降级结果。队列长度控制在 4~8超过就拒绝并提示稍后重试。如果确实需要吞吐宁可起两个实例分两个端口让操作系统去调度也不要在一个实例里开大并发——前者的内存隔离更干净后者容易出现 KV 池争抢导致的诡异抖动。另外补一个细节端侧服务的健康检查不要用“端口是否通”来判断要用“能不能在 2 秒内生成一个 token”。我踩过一次坑模型进程还活着、端口也通但核显已经进入错误状态所有请求都超时。加一个轻量的推理探针能提前发现问题。5.3 需要盯住的几个指标端侧部署不需要复杂的可观测体系但有四个数字必须能随时看到指标采集方式健康区间异常含义解码速度tok/s服务日志里的耗时统计≥ 目标值的 85%下降说明降频、内存争抢或后端退化首字延迟请求开始到第一个 token≤ 1.5 s上升说明提示处理效率变差或队列积压显存占用系统管理工具轮询峰值 ≤ 可用量的 85%逼近上限会触发换页速度断崖核显温度/频率系统管理工具轮询无持续降频锯齿状频率就是散热瓶颈我的习惯是写一个几十行的小脚本每 30 秒采一次落到本地文件出问题时直接看曲线。比事后翻日志猜要快得多。6. 踩坑实录常见问题速查与排查路径6.1 启动阶段的三类典型故障第一类编译过了但跑起来“后端未启用”。表现是能出字但速度慢得离谱CPU 占用 100%。九成是架构编号没匹配上。排查顺序是先看框架启动日志里有没有列出 GPU 设备有设备但没启用检查编译时的目标架构参数确认无误再看驱动版本是否满足后端要求。这里有个隐蔽情况——有些发行版的驱动包是“分体式”的内核模块和用户态库版本不一致表现就是设备能查到但后端初始化失败。第二类加载到一半报显存不足但内存明明够。这就是前面说的 GTT 上限问题。先确认动态借用上限是不是被调大了再确认固定显存划了多少。还有一种情况是系统开了内存压缩或者交换框架算“可用内存”时算进了交换空间结果加载完一用就换页。我的做法是直接关掉交换让框架的判断更诚实。第三类加载成功但首个请求就崩。大概率是上下文长度设得超过实际可分配。框架有时会为最坏情况预留 KV 空间你设 32K 它就按 32K 预留显存不够直接挂。降到 8K 试试能跑就说明是这个原因然后按业务真实需求重新规划。6.2 运行期的性能衰减与输出异常跑一会儿变慢。按发生时间分三种几十秒内变慢看是不是队列积压几分钟内变慢看是不是降频几十分钟后变慢看是不是内存碎片或者 GTT 泄漏。我的排查顺序是固定的先看频率曲线再看显存曲线最后看队列深度从这三个曲线基本能定位到 90% 的问题。输出开始重复或者胡言乱语。端侧最常见的原因是采样参数不合适特别是repeat_penalty设得太低或者温度太低配合 top_p 太小模型会陷在一个循环里。我一般把重复惩罚设在 1.05~1.15 之间温度 0.1~0.3top_p 0.9。另一个原因是量化档位太低尤其是从 Q4 降到 Q3 之后长输出容易在后半段崩掉。如果你发现“前 50 个字正常后面开始重复”先怀疑量化。多轮对话越聊越慢。这是 KV Cache 随轮次增长导致的属于正常现象不是 bug。缓解办法有两个一是限制历史轮数超过 N 轮做摘要压缩二是给服务设一个总 token 预算超了就丢弃最早的对话。端侧做多轮一定要有这个意识不然第 20 轮的时候你会以为模型坏了。6.3 问题速查表现象最可能原因快速验证方法处理方式速度只有个位数后端未启用跑在 CPU 上看启动日志的设备和后端信息重新编译并精确指定架构编号加载时报显存不足GTT 上限偏小查设备报告的可用显存上限调大内核参数并重启提示处理很慢物理批太小对比不同-ub值的首字延迟适当提高注意显存峰值长稳后速度衰减 30%散热不足触发降频看频率是否呈锯齿状限功耗墙、调风扇曲线输出格式不稳定温度偏高或量化过低同输入对比 FP16 与量化版降温、提量化档位、加格式约束并发时全部变慢单实例并发争抢 KV 池对比单请求与双请求延迟改排队或起多实例分端口偶发请求超时但服务活着核显进入错误状态用推理探针而非端口探活加探针 自动重启守护7. 几条踩过坑之后才明白的经验第一先测带宽再谈优化。我现在拿到任何一台端侧设备第一件事就是算纸面带宽上限然后跑一次基准看实际达成率。这个数字决定了我该投入多少精力——达成率已经 70% 的机器再怎么调也就那点空间达成率只有 30% 的随便改改就能翻倍。别凭感觉调参先让数字告诉你天花板在哪。第二把版本号当代码管。驱动、运行时、框架提交号这三个东西的组合决定了你的环境能不能复现。我吃过一次亏换了个驱动小版本速度掉了 40%回滚半天才找到原因。现在我所有端侧项目都有一份环境基线.md写死所有版本部署脚本里加版本校验对不上直接报错退出比跑到一半出问题强。第三量化不是一次性的是分场景的。同一个模型做信息抽取用 Q4_K_M 完全够做长文摘要我可能就上 Q5_K_M做严格格式输出我会回到 Q6_K。别指望一个档位打天下多存几个档位、按业务路由这在端侧是很划算的做法反正一个档位也就 2~3 GB 磁盘。第四交互式场景的体感由首字延迟决定不是 tok/s。人眼对“等待开始”的敏感度远高于“出字速度”。25 tok/s 和 20 tok/s 的差别用户几乎感觉不到但 0.8 秒和 2 秒的首字延迟是断崖式的体验差异。所以如果你的资源有限优先优化提示处理阶段——减少 system prompt 长度、开注意力加速、提高物理批这些对首字延迟的收益比调解码参数大得多。第五留一条降级路径。端侧设备的状态是不稳定的温度、内存、后台进程都可能突然变化。我在服务层永远保留一个“极简模式”——上下文砍到 2K、量化降到 Q4、并发锁死为 1。当主配置跑不动时自动切过去虽然能力打折但至少服务不中断。这个降级开关救过我两次演示。这套方案我在几台不同配置的 AMD 小机器上都跑过从 4 GB 固定显存的老设备到能给核显划 8 GB 的新平台思路是一致的差别只在参数档位。如果你手上的机器跑出来和我差得远先别怀疑模型回去把带宽算一遍、把架构编号确认一遍、把 GTT 查一遍——这三个地方解决了剩下的都是细枝末节。