简介：在本地或自建环境中部署大语言模型时，显存大小、推理框架、模型结构与量化方式会显著影响可用性与生成质量。本文从部署视角定义“可用模型”的评估方法，对比两类不同架构的开源模型在不同显存区间、推理引擎和量化策略下的表现差异，帮助开发者理解在语音、长上下文、智能体任务与对话写作等场景中应如何选择。文章不绑定具体云厂商，仅基于通用部署条件给出判断依据。
大语言模型的选型，并不只是在“哪个模型参数更多”或“哪个模型榜单分数更高”之间做选择。对于需要在本地显卡、单机多卡或自建推理服务中运行的团队来说，更关键的问题在于：在给定的显存、内存、推理框架和量化方式下，哪个模型能够稳定加载、保持可用吞吐，并尽量贴近业务对质量、延迟和上下文长度的要求。
因此，所谓“部署条件下的模型选型”，可以定义为：
在受限的计算资源与推理框架约束下，综合模型结构、参数规模、量化格式、上下文长度、多模态能力和解码速度，确定一个在当前环境中可运行且性价比合理的模型方案。
这个概念包含几个重要维度：
理解这个定义后，选型就不再是单纯比较模型能力，而是把“模型能否在当前条件下被有效使用”放到与“模型能力强弱”同等重要的位置。
过去讨论大模型能力时，很多人习惯以公开基准测试或人工评测作为核心依据。但在实际开发中，一个模型即便通用能力更强，如果无法在现有显卡上加载，或者加载后生成速度过低、上下文长度受限，也很难进入生产环境。
例如，在同一张中端显卡上，有些模型需要把部分层卸载到系统内存，虽然可以运行，但预填充速度会显著下降；有些模型由于键值缓存设计较轻量，即使参数更多，也能在有限显存中保持较好的上下文能力。这类差异很难从模型榜单中看出来，却会直接影响业务体验。
因此，从部署视角出发理解模型选型，主要有三个价值：
参数规模决定模型的基础显存需求。以常规16比特推理为例，参数规模越大，需要的显存越多。为了在有限显存中运行，通常会对权重进行量化，例如4比特、8比特或FP8。量化会降低部分精度，但能显著减少显存占用。
一个可供参考的估算思路是：在相同的量化级别下，参数规模越大，显存占用越高，但不一定与参数数量严格线性相关，因为不同模型结构还存在额外缓存和激活开销。
稠密模型在每次推理时会激活全部参数，显存占用相对固定。专家混合模型则将部分前馈层拆分为多个专家，每次只激活其中一部分。这种结构可以降低单次推理的计算量，但完整模型权重仍然需要被加载或部分卸载。
在实际部署中，专家混合模型如果无法完整放入显存，可能会把部分专家层卸载到内存。虽然推理仍可进行，但预填充阶段可能因为访问内存而变慢。因此，专家混合模型是否适合当前环境，取决于显存能否容纳关键权重以及推理框架的卸载策略。
键值缓存是推理过程中存储注意力状态的部分，随着上下文长度增长而增长。不同模型的注意力头数量、层数和缓存设计不同，导致相同上下文长度下的缓存占用差异很大。
有些模型虽然参数较多，但键值缓存相对轻量，因此可以在相同显存下支持更长上下文。对于合同分析、报告总结、长文档问答等任务，这一点比单纯比较参数规模更重要。
如果业务涉及语音识别、图像理解或语音交互，模型需要加载额外的编码器或投影模块。这些模块会额外占用显存。因此，在多模态需求明确的前提下，需要单独评估加载这些模块后的剩余空间。
推理框架对部署影响很大。面向本地推理的工具通常更关注易用性和单卡兼容性，而面向高吞吐服务的框架则支持更多并行、量化和投机解码能力。例如，某些框架支持多令牌预测，可以在低并发解码时提高速度；某些框架对FP8或AWQ支持更好，可以进一步降低显存占用。
在实际选型中，可以按照以下流程判断：
先明确当前环境中的显存容量、系统内存容量以及是否允许使用内存卸载。一般情况下，优先让模型尽可能多地驻留显存，因为频繁访问内存会降低预填充速度。
如果需要语音输入或多模态理解，应优先选择带有对应模块且模块体积可控的模型。多模态模块通常不应挤占过多键值缓存和权重空间。
如果业务涉及长文档、多轮工具调用或复杂智能体流程，需要确认模型是否支持较长上下文，以及上下文增长后仍能维持稳定速度。长上下文能力不仅取决于模型的设计，也取决于推理框架的优化。
显存紧张时，可以采用4比特或更高压缩比的格式。若对质量要求较高，可考虑8比特或FP8。不同模型对量化的敏感度不同，因此在确定最终配置前，应对比同量化级别下的实际生成质量。
在本地推理框架中，倾向于选择权重可完全或大部分放入显存的模型。对于专家混合模型，如果只能部分卸载，需要接受较低的预填充效率。在高吞吐推理框架中，则可以更充分利用量化、并行和投机解码优化。
这一区间适合参数规模在9B左右的稠密模型。如果业务以文本为主，可以选择通用对话和推理能力较强的模型。若语音交互是刚需，则需要查看对应多模态小模型是否能够在加载语音模块后仍保持可用显存。
这一区间可以支持参数规模约26B至31B的模型，尤其是键值缓存较轻的模型。在16GB显存下，可以不加载多模态模块，直接使用紧凑的4比特权重，从而获得较好的文本生成质量和响应速度。
如果与参数更大的专家混合模型相比，虽然专家混合模型可能通过卸载部分层运行，但预填充性能会受到影响。因此，在需要较高首字响应速度和更大有效上下文的场景下，优先选择可完全放入显存的模型更合适。
这个区间可以在约27B模型与约31B模型之间选择。若业务偏重智能体任务、长文档处理或需要模型频繁调用工具，应优先选择支持更长上下文且长文本速度衰减较小的模型。若业务更偏重写作、角色对话或风格化内容生成，则可以选择对话表现更自然、语言组织更灵活的模型。
在32GB显存下，可以运行更高精度的量化版本，例如使用8比特权重，或者采用FP8格式。此时，高吞吐推理框架可以进一步利用多令牌预测、并行解码等能力，使低并发解码速度明显提升，并支持更大的键值缓存。
对于需要持续处理并发请求的企业服务，更建议把模型部署在支持高性能推理的框架中，而不是仅依赖本地推理工具。这样可以更好地利用显存带宽和计算资源。
参数规模大并不等同于实际体验好。在显存受限时，一个大参数模型若只能通过低比特量化和内存卸载运行，其实际质量可能低于一个参数较小但加载精度更高、上下文更稳定的模型。
稠密模型每次推理激活全部参数，计算量大，但部署行为更可预测。专家混合模型激活参数较少，理论计算效率更高，但完整权重仍需加载或卸载，对显存和框架优化要求更高。
有些模型在对话和写作中表现自然，但在复杂工具调用和长指令跟随中不够稳定；有些模型结构更适合长上下文和智能体任务，但生成风格可能更偏简洁。选型时应结实际业务而不是只看综合榜单。
在有限资源下选择开源大语言模型，本质上是在模型能力、显存占用、上下文能力、推理速度和任务匹配度之间寻找平衡。仅关注参数规模或榜单分数，往往会忽视实际部署中的瓶颈。
更合理的做法是：先明确可用资源与任务优先级，再判断是否需要多模态和长上下文能力，然后选择能够以适当量化级别稳定加载的模型结构，最后结合推理框架进行测试。通过这种方式，才能在自建环境或企业服务中找到真正可用的模型方案。