很多人搜这个型号，是想知道手上那台机器到底能不能跑、跑起来会不会卡。但参数小不等于随便一台机器都合适：量化档位、显存类型、内存带宽、推理框架选哪个，每一项都会改变结论。这篇不讲虚的，给一套按自己机器逐项对表的判断顺序，再讲清什么情况下本地跑反而没意义。
搜这个型号的人，多半是想知道手上那台机器到底能不能跑、跑起来会不会卡。但参数小不等于随便一台机器都合适：量化档位、显存类型、内存带宽、推理框架选哪个，每一项都会改变结论。同一个型号，网上有人说 4G 显存就够，有人说 8G 才稳，两边都没撒谎，只是他们说的压根不是同一件事。
这篇不讲虚的，只给一套按自己机器逐项对表的顺序：先定量化档位，再定上下文上限，再数并发，最后看显存余量。顺序反了就容易先买卡后返工。另外会讲清什么情况下本地跑反而没意义，省得你把时间花在折腾环境上。
为什么同一个型号，配置要求能差好几倍
配置要求不是模型固有的属性，是你给它的运行条件算出来的结果。四个变量一叠加，结论就能差出好几倍。所以看到别人给的单一数字，先问一句：他是在什么量化档位、多长上下文、几路并发下跑出来的。对不上口径，数字就没法直接用。
- 量化档位：权重占多少显存，主要看这一项，压得越狠占用越低
- 上下文长度：KV 缓存随长度线性涨，开得越长显存吃得越多
- 并发数：每路请求都要单独占一份缓存，单路能跑不代表十路能跑
- 推理后端：有的框架常驻显存，有的按需加载，显存占用曲线完全不同
- 先定量化档位确认你打算用哪一档权重，这一档决定了显存的基本盘，后面的账都从它出发
- 再定上下文上限按任务真正需要的长度定，不要默认拉满，这一项对显存的影响比多数人想象的大
- 再数并发想清楚同时会有几个请求，单路和多人共用的配置结论完全不同
- 最后看显存余量把前三项加总后留出框架自身开销，余量不够就回头压上下文或换档位
显存这一关：按档位对齐，而不是按参数量对齐
显存是小参数模型最直接的门槛，但判断方式不是「参数量小所以要求低」，而是「你要放哪一档权重，就要留出对应的那一块」。很多人算显存时把权重算得刚刚好，结果一加载就爆，问题就出在没给 KV 缓存和框架开销留位置。
| 判断项 | 先看什么 | 不够时的动作 |
|---|---|---|
| 权重显存 | 你选的量化档位能放进总显存吗 | 降量化档位或换更小的权重 |
| KV 缓存 | 按上下文长度和并发数估算占用 | 压上下文、减并发，别硬撑 |
| 框架开销 | 推理后端自身常驻的那部分 | 换按需加载的后端或加余量 |
| 统一内存机型 | 权重和上下文共享同一池内存 | 单独按内存池口径算，别套显卡的账 |
核数字的时候，到 /models/deploy 看一下当时给的测算口径，再到 /compute/gpus 对自己那张卡的规格，比记住某个流传的数字靠谱得多。规格页里的显存类型和带宽也要看，它们不决定能不能装下，但决定装下之后跑得快不快。
显存之外的三道坎：内存、带宽、散热
显存够只是入场券。实际体验里，首字延迟和逐字输出速度往往被带宽决定，而不是被参数决定。两台机器都能把权重装进去，一台流畅一台卡顿，差的就是这里。所以看配置别只盯显存一个数。
- 系统内存
- 要装得下模型文件本体，加上加载过程中的临时占用，硬盘紧张的场景尤其要留意
- 内存带宽
- 决定输出速度和首字延迟，同样能装下的机器，体验差距主要来自这一项
- 散热与降频
- 笔记本、迷你主机长时间推理会降频，连续任务下速度掉了要能发现
- CPU 与内存瓶颈
- 多路并发时即使显存没满，这两项也可能先撑不住
建议先量一段稳定输出速度做基线，改天再量一次对照。散热问题最隐蔽，短测看不出来，跑上十几分钟才现原形。如果你打算 7×24 挂着，这一项的权重比峰值速度更高。
该不该本地跑：三条该放弃的信号
配置够不够是技术问题，该不该本地跑是账的问题。小参数模型能解决的任务是有限的，硬把它塞进所有场景，最后既花了硬件钱又没得到想要的效果。下面三条信号出现任意一条，就值得停下来重新想想。
- 任务低频：偶尔问答、单次几轮，调接口的时间成本比本地折腾低得多
- 卡在临界档位：显存勉强够、上下文要压缩、速度明显低于你自己的等待阈值，体验落差通常盖过省下的钱
- 选错了型号：真正需要长文档理解或强推理，小参数模型撑不住，再堆配置也解决不了
反过来，当任务固定、输出短、要离线、调用量足够大时，本地跑才划算。这个账怎么算，到 /compute/sizing 有对应的测算思路。注意它只给方法，具体结果取决于你的调用量和机器成本，数字要按你当时的行情代入。
跑起来之后的调参清单
跑通只是第一步，跑得顺不顺看调参。调参的顺序有讲究：先改影响最大的参数，改完量一次，别一次动好几项，不然出了变化也不知道是谁的功劳。下面这份清单按收益从高到低排。
- 压上下文窗口压到任务真正需要的长度，这是收益最快的一步，改完立刻能看出显存和速度的变化
- 调批次与并发观察显存占用和响应延迟的拐点，找到自己机器的最优区间再固定下来
- 定加载策略模型常驻还是按需加载，按使用频率决定，常驻省加载时间但一直占着显存
- 量延迟基线用站内接口测速页先量一条自己的基线，之后每次改参数都对比这一条，别凭感觉说变快了
常见问题
显存不大，能不能靠量化硬跑起来？
能装下不等于跑得好。量化档位压得很低时，权重占用会明显下降，但输出稳定性和长文本表现通常一起打折。建议先确定量化档位能不能满足你的任务质量线，再倒推显存够不够；如果只有压到最低档才跑得动，多半该换机器或换调用方式，而不是继续压。
核显笔记本和独立显卡，判断方式一样吗？
不一样。独显有独立显存，权重和缓存各占各的；核显或统一内存机型共享同一池内存，模型越大留给系统的余量越少，系统本身也会抢占。核显机型更适合参数更小、上下文更短的场景，判断时把内存总量和带宽一起看，别只看显存那一栏。
跑起来很慢，先怀疑什么？
先看是不是显存不够导致部分层落到内存上跑，这是最常见的原因；其次看上下文窗口开得过大、并发数偏高。排查顺序建议：降上下文 → 降并发 → 换量化档位 → 换推理后端。换后端前先用测速页面量一条基线，否则改完你也说不清是哪一步起的作用。
