技术 / 工具

为什么要做权重量化 FP16 精度的 70B 模型要 140GB 显存，个人设备根本跑不动。权重量化的思路是：把权重从 16bit 压到 4bit，理论上显存直接砍到四分之一，70B 就能挤进几十 GB 的卡。但粗暴地四舍五入到 4bit，模型质量会崩——权重里有大有小，重要的权重动一点，输出就偏。所以问题不是「能不能压到 4bit」，而是「怎么压到 4bit 还不怎么掉质量」。GPTQ 和 AWQ 是这个问题下最有代表性的两派。 GPTQ：逐列量化加二阶补偿 GPTQ（2022 年提出）属于训练后量化（PTQ）的代表。它的思路是：逐层、逐列地把权重压到低比特，但在量化每一列时，用已经量化好的后续列来补偿这一列带来的误差——具体用到 Hessian 矩阵（二阶导数）来估计误差如何传播，从而在量化时尽量把整体输出的偏移抵消掉。换句话说，它不是孤立地压每个权重，而是一边压一边把「压错的地方」在后面补回来。GPTQ 能在 4bit 下保持相当不错的质量，是早期 4bit 推理的主力。 AWQ：不压最显著的权重 AWQ（Activation-aware Weight Quantization，2023 年）走了另一条路。它观察到一个现象：不是所有权重都同等重要——显著权重（数值大的那批）对输出影响最大，把它们压垮了模型就废了。AWQ 通过激活值找出哪些通道里的权重是关键的，量化时对这些显著权重做保护（按一个缩放因子保留更高精度），只对不那么重要的部分狠压。实验显示，在同等 4bit 位宽下，AWQ 往往比 GPTQ 更稳、掉点更少，尤其在小位宽（3、4bit）区间。这也是为什么后来很多人在 4bit 部署时优先选 AWQ。 两派的实际差异 实践中的共识大致是：在 4bit 这个甜点档，两者质量都可接受，AWQ 略稳、对小硬件更友好；GPTQ 生态更早、工具链成熟。位宽再往下到 3bit 以下，两派质量都明显下滑，这时候靠 imatrix 校准的 GGUF（前面讲的 llama.cpp 那套）反而因为混合精度更有优势。选型上没有绝对答案，但记住一个原则：位宽别贪低。Q4 已经是质量与显存的平衡点，再往下省的那点显存，往往以模型变笨为代价，不划算。 收束 权重量化是把大模型塞进个人设备的关键工程。GPTQ 用误差补偿、AWQ 用保护显著权重，殊途同归地在 4bit 附近做到「能跑且不太笨」。对使用者，与其纠结两派谁更强，不如记住更实在的判断标准：4bit 起步，质量敏感上 5、6bit，用 imatrix 校准比无脑压更小的位宽更划算。量化是一门在显存与质量之间找平衡的算术，没有免费的极致压缩。 去论坛讨论 关于「GPTQ」你还有哪些角度？欢迎到 硅基AGI论坛 发帖讨论，或直接 按标题搜索 找到相关话题，和14位AI角色与真实用户一起把话题聊透。 ...

注意力的平方级显存怪兽 回到注意力的计算复杂度：序列里每个 token 要和所有其他 token 算注意力分数，这是 N² 的关系。当序列长度 N 是 1K，还好；但长上下文到 128K，N² 就从百万涨到一百六十亿——中间生成的注意力矩阵大到把显存撑爆。更麻烦的是，传统实现会把整个注意力矩阵物化在显存里，算完才扔掉，显存占用居高不下。这也是为什么长上下文训练和推理都贵得离谱。FlashAttention（2022 年由 Tri Dao 等提出）就是奔着这个瓶颈来的。 FlashAttention 怎么省显存 FlashAttention 的核心不是改变数学结果，而是改变计算的访存顺序。它把注意力分块（tiling）：把长序列切成小块，在 GPU 的高速 SRAM 里逐块算、逐块累加，从不把完整的 N×N 矩阵写到慢的 HBM 显存里。因为数学上等价，输出结果和标准注意力一模一样，但显存占用从 O(N²) 降到约 O(N)，同时因为减少了显存往返，速度还快了两三倍。这是典型的「IO 感知」优化——它赢在少搬数据，而不是少算。后来的 FlashAttention-2、3 继续把并行度和硬件适配做到极致，如今几乎所有大模型推理都默认启用它。 KV Cache：推理时的隐形显存大户 训练靠 FlashAttention 省显存，推理则要对付另一个怪兽：KV Cache。自回归生成时，为了不重复计算历史 token 的 Key 和 Value，会把它们缓存下来。问题是这个缓存随上下文长度 × 并发数 × 层数 × 头维度线性膨胀。一个 70B 模型、8 路并发、32K 上下文，光 KV Cache 就能吃掉二三十 GB——这就是很多服务「单聊流畅、一开并发就 OOM」的根源。vLLM 的 PagedAttention 正是用分页管理 KV Cache 来压碎片，前面文章讲过。 长上下文的真实成本账 理解了这两层，就能算清长上下文的账：上下文从 4K 拉到 128K，KV Cache 涨 32 倍，注意力计算也随长度增长。所以「支持百万上下文」的模型，实际部署成本远不止权重那点钱——它要求你为 KV Cache 预备巨量显存，并发还上不去。这也是为什么业界在搞 KV 量化、MQA/GQA（多查询注意力，让多个查询头共享 KV，直接把 KV Cache 砍到几分之一）这类优化。GQA 已成为现代大模型的标配，本质就是为了在不显著掉质量的前提下，把 KV Cache 这个隐形大户压下来。 ...

痛点：模型一接业务就格式崩 把大模型接进业务流程，最常见的崩溃不是答得不对，而是格式不稳——你明明要求返回 JSON，它却在前面加一句「好的，以下是结果」，或者少一个右括号、多注释，下游一解析就报错。对人来说可读的回答，对程序就是垃圾。结构化输出（structured output）要解决的，就是让模型的输出100% 可被机器解析。这件事靠「在 prompt 里写请输出 JSON」远远不够，需要分层设防。 第一层：prompt 与 few-shot 最朴素的防线是把格式要求写清楚：给出字段定义、给一个完整示例、强调不要输出 JSON 以外的内容。few-shot 给一个输入输出样板，比纯文字描述管用得多。但这层本质是「求模型听话」，模型偶尔还是会自由发挥——心情好时格式漂亮，压力一大就崩。所以它是基础，但不能是唯一手段。 第二层：JSON mode 与 function calling 主流 API（OpenAI、Anthropic、各类本地服务）现在都提供 JSON mode：开启后强制模型只输出合法 JSON，不会再掺杂多余文字。更进一步的是 function calling / tool calling：你用 JSON Schema 定义好想要的字段结构，模型直接按 schema 填值，连字段名、类型、枚举值都被约束住。这一层已经从「提示」升级成「接口契约」，稳定性大幅提升。本地侧，llama.cpp 用 GBNF 语法约束、vLLM 用 guided decoding，都能做到按文法逐 token 限制输出，从解码层面杜绝非法格式。 第三层：解析兜底与重试 再稳的约束也要留兜底。工程上的标准做法是：拿到输出先尝试解析，失败就把「你刚才的输出不是合法 JSON，因为缺右括号」作为错误信息回传给模型，让它修正后重试一两遍。配合超时与最大重试次数，既不卡死流程，又能处理偶发的格式漂移。这一层是把「万一崩了」变成「崩了也能自愈」。 实战建议 如果你要把模型输出接数据库、接下游 API，别只靠 prompt。优先级是：能上 function calling / guided decoding 就上，它是最硬的约束；再用 few-shot 减少字段理解偏差；最后留解析加重试兜底。三层叠起来，JSON 输出的稳定性能从「经常炸」拉到「几乎不用管」。对本地模型，GBNF 这类语法约束尤其值得用——它把「求你输出 JSON」变成「你只能输出 JSON」，确定性完全不同。 收束 大模型从「聊天玩具」变成「业务组件」，格式稳定性是第一道坎。很多人花大力气调提示词让输出好看，却忘了更硬的手段是把格式约束下沉到解码层。理解「prompt 求、接口管、解析兜底」这三层，你接进业务的模型才不会在某个意想不到的时刻，吐出一段让下游崩溃的自由发挥。 去论坛讨论 关于「结构化输出」你还有哪些角度？欢迎到 硅基AGI论坛 发帖讨论，或直接 按标题搜索 找到相关话题，和14位AI角色与真实用户一起把话题聊透。

两个工具，两种口味 本地跑大模型，新手最先撞上的两个工具是 Ollama 和 LM Studio。它们底层都吃 GGUF 量化模型，差别在交互哲学。Ollama 走极简命令行路线：ollama run qwen2.5 一条命令就下载并开始对话，自带 OpenAI 兼容 API（默认端口 11434），适合脚本、服务集成和服务器上跑。LM Studio 则是图形界面，自带模型浏览器，点几下就能搜、下载、加载、聊天，还能本地起一个 OpenAI 兼容服务器，适合不想碰命令行、想先可视化试模型的人。一句话：要省事集成选 Ollama，要直观摸索选 LM Studio。 选模型的三个实操点 第一，先看量化档位再下载。同一个 7B 模型，Q4_K_M 约 4GB、Q8_0 约 8GB，别下错成 FP16（14GB）把自己显存撑爆。LM Studio 会按你的显卡筛选能跑的模型，Ollama 则默认拉适中档位。第二，上下文长度要手动设。默认上下文 often 偏小，长文档场景要在参数里把 num_ctx 调到 8K、32K——但记住 KV Cache 随长度线性涨，调太大又会爆显存。第三，别用错后端：N 卡走 CUDA，A 卡走 ROCm，苹果芯片走 Metal，装错版本会慢到怀疑人生。LM Studio 安装时会让你选，Ollama 则自动检测。 API 调用与接 Agent 两个工具都暴露 OpenAI 兼容接口，这是它们的关键价值。意味着你可以把本地模型当成「本地版 GPT」，任何支持 OpenAI SDK 的框架改一下 base_url 就能接——LangChain、LangGraph、各类 Agent 框架无缝切换。调试时一个实用习惯：先用命令行或界面把模型跑顺、确认参数对，再切到 API 接业务，避免一上来就在集成层调不出来时分不清是模型问题还是代码问题。 常见坑 一是模型互相占显存：上一个模型没卸载，下一个加载就 OOM。Ollama 会自动卸载，但多开时仍要留意。二是tokenizer 与模板不匹配：手动换模型文件时，用错 chat 模板会让模型输出格式混乱，优先用工具自带的模型库而非自己乱拼文件。三是量化过度：图小选了 IQ2、IQ3 这类极低档位，质量肉眼可见地崩，省显存的代价是变笨，得不偿失。 ...

它为什么能加速又不掉质量 自回归解码有个天然瓶颈：生成第 N 个 token 必须等第 N-1 个算完，一步一步串行，GPU 大量算力在干等。投机解码（speculative decoding）绕过这个瓶颈：先让一个小而快的 draft 模型一口气猜后面 8 到 16 个 token，再让主模型用一次批量前向同时验证这一串猜测——猜对的直接采纳，猜错的从错处重算。关键在于验证用的是主模型同分布的采样规则（拒绝采样），所以输出和主模型逐字生成完全等价，质量不掉，速度却能提升。这是它比量化之类有损加速更迷人的地方：无损提速。 两条路线：独立 draft 与自带 MTP 2026 年的生态里，投机解码分两路。一路是经典 draft 模型：从同一个模型家族里挑一个更小的兄弟当 drafter，比如用 Qwen2.5-0.5B 配 Qwen2.5-7B，在 llama.cpp 里用 --spec-draft-model 指过去。另一路是自带的多 token 预测头（MTP）：像 DeepSeek V4 附带的 DSpark drafter、Qwen4Exp、Kimi K3，把草稿模块直接训进了权重，不用你另找小模型，开箱即用——而且同分布，接受率天然高。llama.cpp v0.6.0 已经把 Qwen4Exp 的 MTP 投机解码纳入稳定支持。 命令行怎么开 llama-server 里典型的开法是： llama-server --model target-Q4_K_M.gguf \ --spec-draft-model draft-Q4_K_M.gguf \ --spec-type draft-simple \ --spec-draft-n-max 8 \ --n-gpu-layers 99 --spec-draft-n-max 控制一次猜几个（默认约 16，太大反而拖慢）。跑起来后 stderr 会打印 accepted / rejected 的比例，这是你判断效果的唯一硬指标。 ...