显存不够，第一反应往往是找量化版。但下到手里才发现一堆后缀：有的只能 CPU 跑，有的要特定推理框架，还有的量化之后长文本直接崩。这篇不教你量化原理，只给一张按场景挑格式的对照表，加上确认和回退动作，让你在下载前就知道这份权重能不能跑在你手上这张卡上。
显存不够，第一反应往往是去找量化版。但真下到手里才发现后缀一堆：有的只能 CPU 跑，有的必须配特定推理框架，还有的量化之后长文本直接崩。这篇不聊量化原理，只给你一张按场景挑格式的对照表，外加下载前后的确认和回退动作，让你在下之前就大致判断这份权重能不能跑在你手上这张卡上。
先提醒一句：同一份模型经常同时挂好几个量化版本，位数、格式、是否只量化权重都不一样，看着像同一个东西，实际跑起来差别不小。显存估算、并发能跑到什么程度、速度多少，这些具体数字别信别人截图，到站内页面按你机器的实际配置核对一遍更靠谱。
先认清常见格式，别被后缀名唬住
量化格式其实可以先按「谁在跑」分成两大类：一类是给本地推理工具吃的一体化权重文件，一个文件包含权重加配置，拷来就能跑；另一类是给服务端框架吃的高吞吐权重，通常配合专门的服务框架和批处理策略。认清这两类，再看后缀名就不会懵。很多模型两种都发，下错就要重来。
- 一体化本地格式
- 权重和配置打包在一起，本地推理工具直接加载，偏 CPU 与低配显卡，跑不动能往内存和硬盘卸载。
- GPU 高并发格式
- 面向服务端的权重量化，配合专用框架做批处理，追求吞吐而不是单条响应速度。
- 激活量化格式
- 不只量化权重，连中间激活也一起压，显存更省，但对框架和硬件的支持面更窄。
- 低比特专用方案
- 只在特定硬件架构上才有对应内核，换卡就跑不了，下之前先确认显卡是否在支持列表里。
光看后缀还不够，要留意两个参数：量化位数，以及是不是只量化权重。位数越低显存越省，但长文本和数学类任务更容易掉质量，这一点在选格式时比格式名字本身更重要。
- 同一模型的不同量化版本，位数和格式都可能不同，别按文件名猜，去看发布页的说明
- 位数低不等于一定不能用，关键看你的任务对精度敏不敏感
- 只量化权重的版本通常兼容性更好，激活也量化的版本省显存但挑框架
- 遇到没见过的名词，先到 /ai-dict/category/tech 对照一遍，再决定要不要下那几百 GB
按你的场景选：单机自用、多人服务、边缘设备分开看
格式没有绝对好坏，只有配不配你的场景。同一份权重换格式往往要重下重测，所以挑之前先想清楚你是单机偶尔用、多人并发服务，还是一台小机器或纯 CPU 顶着跑。
| 场景 | 优先考虑的格式类型 | 主要代价 |
|---|---|---|
| 单卡自用、偶尔问几句 | 一体化本地格式 | 速度，显存不够会往内存和硬盘卸载 |
| 多人并发、要稳定吞吐 | 服务端框架支持的 GPU 量化权重 | 量化档位和并发要一起算，调参更麻烦 |
| 显存极小的机器或纯 CPU | 低位数版本，同时调短上下文 | 长上下文最先出问题，可能答非所问 |
| 精度敏感任务 | 直接跑原始权重 | 显存占用高，但省去质量风险 |
- 先估显存到 /models/deploy 把参数规模、量化档位、上下文长度代进去估一遍，看你的卡够不够，估不准就按偏保守的配置算。
- 再定并发如果是多人服务，先想清楚大概几个人同时用，再决定量化档位，别只盯单条响应快不快。
- 最后缩上下文显存实在紧，优先把上下文长度调短，而不是一味往更低位数压，长文本是低比特量化最容易崩的地方。
还有一条容易忽略：同一份权重换格式之后，效果不一定一样，别拿 A 格式的体验去推 B 格式。跨机器迁移、换版本之前，先把迁移步骤和回退路径理清楚，动作可以参考 /model-upgrade-migration-checklist。
下载前后各做一次确认，不行就退回去
下载前至少确认三件事：推理框架是否明确声明支持这个格式、你的显卡架构是否支持那个低比特内核、许可证是否允许你的用法。许可证边界不熟的话，到 /open-weight-license-basics 看一遍，别等用起来了才发现不能用。
- 框架支持：去框架的文档里搜这个格式名，搜不到就默认不支持
- 硬件支持：低比特内核经常只覆盖部分显卡架构，换卡可能直接跑不了
- 许可证：商用、再分发、改模型这些用法各有边界，先看清楚再下
- 磁盘与带宽：量化版通常还是几十 GB 起步，留足空间再动手
跑起来之后别急着信感觉。用同一组固定问题做对比：长文摘要、代码补全、数字计算各来一条，和未量化版本对照着看，判断是变慢了还是变差了。这个对比成本很低，比事后排查省事。
| 现象 | 先怀疑什么 | 先做什么 |
|---|---|---|
| 答非所问、长文本后半段丢失 | 量化位数太低，上下文太长 | 换高一档位数，或把上下文调短 |
| 数字计算开始乱编 | 精度敏感任务遇上低比特量化 | 换格式或直接跑原始权重 |
| 能加载但一跑就报错 | 框架或显卡架构不支持该内核 | 回来看格式支持列表，换兼容版本 |
| 速度慢得离谱 | 权重被卸载到内存或硬盘 | 调小上下文或换更小的模型 |
什么时候不适用：如果任务对数值精度极敏感，或者你的显存本来就够用，那量化省下的那点资源不值得你承担质量风险，直接跑原始权重更省心。反过来，只是偶尔问几句、机器又小，低位数量化版往往就是最实际的选择。
量化是拿质量换空间，划不划算要看你跑什么任务，不是位数越低越聪明。下一步把你要下的模型和手头机器的参数一起代进站内部署估算页，先估显存再决定格式，比下完再试快得多。→
常见问题
量化模型和不量化差别到底有多大？
差别不在「能不能用」，而在具体任务上：短问答、日常写作通常感觉不明显，长文本、数学和代码里更容易露馅。别信通用结论，自己拿几条固定问题对比一遍最靠谱。判断标准是「你的任务里有没有对精度敏感的部分」，有就别压太低。
同一个模型有好几种量化版本，我该按什么顺序排除？
先按你的推理框架筛，不支持的直接排除；再按显存上限筛，达不到的排除；剩下两三个就下载跑同一组测试题做对比。顺序别反了，先挑质量最好但跑不起来的等于白费功夫。
量化之后输出变成乱码或者中途断掉，是什么问题？
多半是格式与框架不匹配，或者上下文长度超出了低比特版本能稳住的范围。先把上下文调短再试一次，还不行就换高一档量化位数或换格式。排查顺序是：框架支持声明、显卡架构支持、上下文长度，最后才怀疑权重文件本身损坏。
