本地部署ai大模型需要怎么配置

想在自己机器或公司服务器上跑大模型，最常见的卡点是不知道从哪一步开始算：先挑模型还是先看显卡？4-bit 和 fp16 差多少？显存够了为什么还是慢？这篇给一套按「参数量 × 量化档位 → 显存 → 卡型」的推算顺序，再补上容易被忽略的内存、带宽和并发余量，让你在买卡或租卡之前先把数算清。

第一步不是挑卡，是先把显存账算出来

很多人第一步就问「买哪张卡」，其实顺序反了。先把要跑的东西换算成显存数字，再回头挑卡，才不会被参数表带偏。粗算公式很简单：权重占用 ≈ 参数量 × 每参数字节数。fp16 按 2 字节、int8 按 1 字节、4-bit 量化按 0.5 字节，乘出来的只是权重下限，不是你实际需要的显存总量。

权重之上还要叠两块：上下文缓存（KV cache）和运行时开销。上下文开得越长、并发越多，KV cache 涨得越快，长上下文场景只按权重买卡一定翻车。所以正确做法是先定「最长上下文 + 同时几个人用」，再决定卡。拿不准具体数字时，去 /compute/sizing 按模型算一遍，再到 /compute/gpus 核对卡的实际显存。

• 先把参数量和量化精度定下来，算出权重下限
• 叠加 KV cache：按目标上下文长度和并发数估，别只算单条请求
• 预留运行时开销：框架、临时缓冲、显存碎片都要占地方
• 对照 /compute/gpus 里的实际显存，而不是包装盒上的宣传值
• 显存之外再检查系统内存，加载和量化转换都在吃它

1. 定模型和精度先明确要跑多大参数、用哪种量化，这是后面所有计算的输入。
2. 算权重下限参数量乘每参数字节数，得到一个不能再低的数字，记下来。
3. 加 KV cache 和开销按最长上下文和并发数往上加，长上下文场景这一步才是大头。
4. 核对系统内存确认内存能撑住加载和量化转换，不够就先加内存再谈卡。
5. 用站内工具复核到 /models/deploy 做部署测算，再对 /compute/gpus 查实卡显存。

量化档位怎么定：先问能接受多少质量损失

选量化档位别抄别人结论，先算清两件事：你能给多少显存，以及你的任务能吞下多大质量损失。fp16 基本无损，但显存占用直接翻倍，只适合卡多卡大、或者对数值精度极敏感的场景，比如科研复现、金融风控打分这类错一点就要命的活。普通业务硬上 fp16，多半是白占资源。

int8 是折中档，多数对话、检索、分类任务够用，显存比 fp16 省一半左右，质量掉得通常察觉不到。4-bit 是小团队和个人自建的主流选择，显存能压到 fp16 的四分之一上下，代价是复杂推理、代码生成、长文摘要有概率出现细微退化，单条看不出，成批跑就冒头。任务偏简单，低比特完全够；任务偏精细，别硬省那点显存。

1. 挑样本从你自己的真实任务里抽一小批，覆盖正常问法和边界问法，最好带上期望答案或验收标准。
2. 跑两档用同一批样本分别跑目标档位和高一档，固定提示词和参数，避免其他变量干扰。
3. 对齐看结果比错答率、格式稳定性、关键字段有没有丢，别只凭单条观感下结论。
4. 再决定低档能过验收就用低档，过不了再往上加，别一开始就按最贵档位做预算。

还有一层常被忽略：量化格式和推理框架要对得上。GGUF、AWQ 这类格式并非所有工具都能直接加载，有些还得额外转换或装插件。动手买卡之前，先去 /ai-dict/category/tech/ai-dict/category/tech 和相关工具词条把框架支持范围核对一遍，别等机器上架才发现跑不起来。

• 显存够不够，先按目标档位估一遍再买卡
• 任务对错答的容忍度，用样本实测而不是听说
• 推理框架能不能加载你选的量化格式
• 换算和部署成本，别只算显存不算时间

卡怎么选：显存、带宽、能不能多卡要一起看

选卡别只盯一个数字。顺序是：先看单卡显存能不能装下你要跑的那个量化档位，装得下再谈速度和卡数；装不下，就得走多卡拆分或者 CPU offload。offload 能用，但出字速度会掉一个量级，那种体验更像「能跑起来」而不是「能天天用」。

• 单卡显存：先把量化档位和上下文长度定死，再倒推需要多少显存，别先买卡后凑模型。
• 显存带宽：同样显存容量下，带宽直接决定出字速度，消费卡和专业卡在这块的差距比参数表上看更明显。
• 多卡支持：确认推理框架能不能张量并行或流水线并行，主板有没有足够槽位，电源和机箱塞不塞得下。
• 可用显存：两张卡拼出来的不是简单相加，中间有通信和切分开销，实际能用的更少。
• 并发预估：只做单人试用和做多路服务是两套配置，先估并发再定卡数。
• 具体型号规格差异，到 /compute/gpus 对照着看，别凭印象选。

1. 定量化档位和上下文先写清楚要跑哪个量化档、上下文开多长，这是估显存的输入，后面所有结论都建立在这上面。
2. 单卡显存过一遍拿这个输入去算单卡够不够，够就往下看带宽，不够就立刻分叉到多卡或 offload 两条路。
3. 估并发到 /compute/sizing 按实际会同时用的人数估一遍，单人试用和多路服务的结论会完全不同，先确认自己在哪一档。
4. 查型号规格把候选卡拿到 /compute/gpus 对照显存和带宽，同时确认框架、主板、电源、机箱这几项硬约束。
5. 算够再下单多卡方案要单独验证框架支持和实际可用显存，别把两张卡的标称显存直接加起来当预算。

配置定了之后，先确认该买还是该租

配置清单列完，先别急着下单。这一步只问三个问题：这台机器一周会用几次、要跑的数据能不能出内网、模型是不是就固定那一个。三个答案都偏「高频、不能出、不变」，自建才站得住；只要有一个偏「偶尔、无所谓、想多试几个」，租卡或者直接调 API 往往更省心。

• 自建的总成本不止显卡：电费、散热、机箱、电源、主板、内存、硬盘和运维时间都要摊进去，按三年周期算才接近真实；
• 到 /compute/tco 把三年账填一遍，把租卡或调 API 的估算放同一张表里对照，差距不明显就别自建；
• 只是验证某个模型值不值得上，先用最低的量化档位在现有机器的消费卡上跑通流程，能跑通再谈加硬件；
• 配置清单写完后，用 /models/deploy 复核模型版本和显存口径，避免按旧参数买了卡却跑不动新模型。

1. 先算真实用量把过去一个月的调用次数和高峰时段记下来，估算每周实际使用时长，别按「理论上可以跑满」来算。
2. 再算三年总账到 /compute/tco 把硬件、电费、散热、配套和折旧填进去，旁边放一列租卡或 API 的估算，看哪边更接近你的使用强度。
3. 复核模型口径拿最终配置去 /models/deploy 对一遍模型版本和显存要求，确认量化档位、上下文长度和并发数都在余量内。
4. 留一条退路自建也建议保留 API 或租卡作为兜底，遇到峰值或模型更新时不必立刻再买一张卡。