1. 先算一笔总账自己部署大模型到底贵在哪很多人第一次冒出“自己部署大模型”的念头都是被 API 账单吓出来的。按量付费用多少扣多少看着单价不高可一旦把大模型接进业务流日调用量从几百次涨到几万次月底账单能直接翻好几倍。于是很自然地会想我买张显卡自己跑是不是就一劳永逸、彻底省钱了这个想法不能说错但只对了一半。自己部署确实能把“按次计费”变成“按硬件折旧计费”可它同时把一堆原本由服务商承担的隐性成本转移到了你自己头上。这笔账要算清楚得把显性成本和隐性成本分开看再把它们折算到同一个维度上——也就是每百万 token 的实际成本否则根本没法比。我先给一个粗略的结论方便你带着预期往下看当你的日均调用量稳定超过某个阈值、且对延迟和数据不出本地有硬性要求时自己部署才可能更便宜低于这个阈值API 几乎总是更划算。这个阈值不是固定的它取决于你选的模型规模、量化方式、硬件采购价、电费、以及你对自己时间成本的估值。下面我把每一项都拆开算。1.1 显性成本硬件、电费、折旧自己部署最直观的支出就是硬件。以目前个人和小团队最现实的方案为例一张消费级显卡比如 16GB 显存档位加上配套的主机整机落地大概在八千到一万五之间。如果跑的是 7B 到 14B 级别的模型配合 4-bit 量化16GB 显存基本能塞下推理速度也能接受。但硬件不是一次性投入就完事。显卡有折旧通常按三年摊电源、主板、散热这些也有寿命。更要命的是电费——一张满载功耗 200W 左右的显卡加上 CPU 和整机其他部件满载整机功耗轻松上 350W。按每天跑 8 小时、电价 0.6 元一度算一天电费大约 1.7 元一年就是 600 多块。如果 24 小时不间断跑一年电费直接奔着 1800 元去。把这些摊到 token 上就需要知道你的实际吞吐。一张 16GB 显卡跑 7B 量化模型用合适的推理引擎输出速度大概在每秒 30 到 60 个 token 之间。假设平均每秒 40 token每天跑 8 小时一天能产出约 115 万个 token。三年硬件折旧按 12000 元算每天折旧约 11 元加上电费 1.7 元一天总成本约 12.7 元折算下来每百万 token 约 11 元。这个数字看起来很美但它是建立在“显卡每天都在满负荷跑”的前提上的。如果你一天只调用几千次、每次几百 token那显卡大部分时间在闲置折旧却一分不少实际每百万 token 成本会飙升到几百甚至上千元这时候 API 反而便宜得多。1.2 隐性成本时间、运维、机会成本真正让“自己部署更便宜”这个结论翻车的往往是隐性成本。第一块是时间成本。从选硬件、装驱动、配环境、下模型、调推理引擎到后面处理各种报错、显存溢出、版本冲突一个新手从头跑通花掉两三个完整工作日是常态。这些时间如果折算成工资可能已经够买好几个月的 API 额度了。第二块是运维成本。自己部署意味着你要对可用性负责。显卡驱动会崩、推理服务会挂、磁盘会满、模型文件会损坏。API 服务商挂了你可以提工单自己部署挂了只能自己半夜爬起来重启。这种持续的心力消耗很难用钱量化但它是真实存在的。第三块是机会成本。你把时间花在折腾部署上就没时间花在业务本身。对于个人开发者和小团队这往往是最贵的一块。所以我在算这笔账时习惯给自己的人工按小时计价哪怕只是象征性地算也能让决策更清醒。1.3 一个可复用的成本对比框架为了让你能直接套用我整理了一个对比表。你只需要填入自己的实际数字就能得出属于自己的结论。成本项自己部署调用 API硬件采购一次性 8000-15000 元0硬件折旧按三年摊约 11 元/天0电费约 1.7-5 元/天0时间投入首次 2-3 人天后续持续几乎为 0运维心力高需自己兜底低服务商兜底单价约 11 元/百万 token满负荷按官方定价通常几元到几十元/百万 token数据不出本地可以通常不行弹性扩容差受硬件限制好随用随扩看这张表你会发现自己部署的优势集中在数据不出本地和长期满负荷下的单价而 API 的优势集中在零启动成本和弹性。所以决策的关键就变成两个问题你的数据能不能出本地你的负载能不能长期跑满2. 什么情况下自己部署才真的省钱上一节把成本拆开了这一节我直接给判断标准。因为很多人算账算到一半就迷糊了其实只需要盯住几个关键变量。2.1 调用量阈值日均多少 token 才值得自己跑这是最核心的变量。我按前面算出的“自己部署约 11 元/百万 token”作为基准再假设 API 价格是 20 元/百万 token不同模型差异很大这里取一个中间值。那么自己部署要回本你的日均 token 消耗必须达到一个门槛让折旧和电费被摊薄。粗略估算如果一天只产出 10 万 token那 12.7 元的日成本摊下来就是 127 元/百万 token远贵于 API。如果一天产出 100 万 token成本降到 12.7 元/百万 token开始接近 API。如果一天产出 500 万 token成本降到约 2.5 元/百万 token这时候自己部署的优势就非常明显了。所以一个经验性的门槛是日均稳定消耗在 100 万 token 以上自己部署才开始有经济性达到 300 万到 500 万 token优势才比较稳固。低于这个量除非你有数据不出本地的硬需求否则 API 更划算。2.2 数据敏感度什么时候钱不是第一考量有些场景下钱根本不是主要矛盾。比如你处理的是内部合同、客户隐私、医疗记录、未公开的研发资料这些数据一旦出本地就是合规风险。这时候哪怕自己部署贵一点也得自己跑。我见过不少团队明明 API 更便宜还是咬牙买了显卡原因就是数据不能出门。还有一种情况是离线环境。比如工厂车间、野外作业、内网隔离环境根本没有稳定的外网API 调不通只能本地部署。这种场景下成本对比没有意义能跑起来就是胜利。2.3 延迟与稳定性API 给不了的东西API 的延迟受网络和服务商负载影响高峰期可能抖动。自己部署的延迟相对可控尤其是局域网内调用首 token 延迟可以压得很低。对于实时交互类应用比如语音助手、在线客服这种延迟优势会直接影响体验。另外API 服务商可能限流、可能涨价、可能下线某个模型版本。自己部署虽然运维累但版本和节奏完全自己掌控。这种“确定性”对某些业务来说价值超过省下的那点钱。3. 硬件与推理引擎怎么选才不踩坑决定自己部署之后第一个现实问题就是买什么卡用什么引擎。这两件事选错后面全是坑。3.1 显卡选型显存比算力更重要跑大模型显存是第一约束不是算力。模型权重、KV Cache、中间激活值都要占显存。一个 7B 模型用 FP16 存光权重就 14GB用 4-bit 量化权重降到约 4GB但 KV Cache 还会随上下文长度增长。所以 16GB 显存是跑 7B 到 14B 量化模型的舒适区8GB 只能勉强跑 7B 且上下文不能太长。消费级显卡里显存 16GB 的型号是个人部署的甜点。再往上24GB 显存能跑更大的模型或更长的上下文但价格也上一个台阶。如果你预算有限宁可选显存大、算力稍弱的卡也不要选算力强但显存小的卡——显存不够直接跑不起来算力弱只是慢一点。注意买卡前一定确认你的电源功率和机箱空间。高端卡往往又长又厚功耗也高老电源可能带不动。3.2 推理引擎别一上来就追新推理引擎这几年更新很快vLLM、SGLang、llama.cpp、Ollama 各有侧重。我的建议是先求跑通再求快。如果你是新手想最快看到效果Ollama 是最省心的选择。它把模型下载、量化、服务化都封装好了一条命令就能跑起来适合验证和小规模使用。缺点是并发能力一般高负载下不如专业引擎。如果你要上生产、追求吞吐vLLM 是当前比较主流的选择。它用 PagedAttention 管理 KV Cache显存利用率高并发吞吐好。但它对环境和显卡驱动有要求配置起来比 Ollama 麻烦。llama.cpp 则适合 CPU 或混合推理场景量化支持非常全在资源受限的环境下很能打。如果你用的是核显或者没有独显llama.cpp 往往是唯一现实的选择。引擎适合场景上手难度并发能力Ollama个人验证、小规模低一般vLLM生产、高并发中高强llama.cppCPU/混合、资源受限中中SGLang复杂推理、结构化输出高强3.3 量化省显存的关键手段量化是把模型权重从高精度如 FP16压到低精度如 4-bit、8-bit的过程。它直接决定你的模型能不能塞进显存。4-bit 量化通常能把显存占用降到 FP16 的四分之一左右代价是精度略有损失但对大多数对话和问答任务损失几乎感知不到。常见的量化格式有 GPTQ、AWQ、GGUF 等。GGUF 主要用于 llama.cpp 生态GPTQ 和 AWQ 更多用于 GPU 推理。选量化版本时优先选社区验证过的、和你推理引擎匹配的格式别自己乱转容易出问题。4. 从零跑通本地部署的完整实操这一节我按真实操作顺序走一遍你可以直接照着做。我以 Linux 环境加一张 16GB 显卡为例这是最典型的个人部署配置。4.1 环境准备驱动、CUDA、Python第一步是显卡驱动。装驱动最稳的方式是用系统包管理器别去官网下 runfile 手动装容易和内核版本打架。装完之后用nvidia-smi确认能看到显卡和驱动版本。第二步是 CUDA 工具链。注意你不需要单独装完整 CUDA很多推理引擎会自带运行时。但如果你要自己编译某些组件就需要装对应版本的 CUDA Toolkit。版本匹配很关键引擎要求 CUDA 12.x你就别装 11.x。第三步是 Python 环境。强烈建议用 conda 或 venv 隔离别在系统 Python 里乱装。创建一个独立环境Python 版本选 3.10 或 3.11这两个版本兼容性最好。conda create -n llm python3.11 conda activate llm4.2 用 Ollama 快速验证环境好了之后先用 Ollama 跑通建立信心。安装 Ollama 后直接拉一个量化模型ollama pull qwen2.5:7b ollama run qwen2.5:7b如果能看到模型正常对话说明驱动、显存、推理链路都通了。这一步的意义是排除硬件和驱动问题把变量降到最少。很多人一上来就折腾 vLLM结果报错一堆分不清是驱动问题还是引擎问题白白浪费时间。4.3 用 vLLM 上生产验证通过后如果要做服务化换 vLLM。先装pip install vllm然后启动服务python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --dtype auto \ --max-model-len 8192 \ --gpu-memory-utilization 0.9这里几个参数很关键。--dtype auto让引擎自动选精度--max-model-len控制最大上下文设太大显存会爆--gpu-memory-utilization 0.9表示用 90% 显存留一点给系统。启动后它会暴露一个兼容 OpenAI 接口的端点你原来的 API 调用代码几乎不用改把 base_url 换成本地地址就行。4.4 压测与调优找到你的真实吞吐服务跑起来不代表能用。你得压测知道在并发多少的情况下延迟还能接受。可以用简单的脚本发并发请求观察首 token 延迟和每秒输出 token 数。调优的方向主要是两个一是调--max-num-seqs控制并发批大小二是调--gpu-memory-utilization在显存和吞吐之间找平衡。显存利用率调高能缓存更多 KV吞吐上去但留给系统的余量变小容易 OOM。这个平衡点只能实测没有万能参数。提示压测时盯着nvidia-smi的显存占用一旦接近 100% 就要警惕生产环境建议留 10% 余量。5. 常见问题与排查速查自己部署最耗人的就是排错。我把高频问题整理成表遇到时直接对照。现象可能原因排查方向启动报 CUDA out of memory显存不足降 max-model-len、提高量化等级、减并发驱动能识别但引擎报错CUDA 版本不匹配核对引擎要求的 CUDA 版本首 token 延迟极高模型未加载完或显存交换确认模型完全载入检查是否用到共享内存并发一高就崩批大小或显存余量不足降 max-num-seqs留显存余量输出乱码或重复量化精度损失或采样参数问题换量化版本调 temperature 和 top_p服务跑一段时间变慢显存碎片或缓存膨胀重启服务限制上下文长度除了表里的还有几个我踩过的坑值得单独说。第一别用系统自带的 Python依赖冲突能让你怀疑人生。第二模型文件下载要校验下到一半损坏的模型会报各种莫名其妙的错。第三日志一定要留出问题时日志是唯一线索别把输出重定向到 /dev/null。还有一个容易被忽略的点散热。消费级显卡长时间满载机箱风道不好会降频吞吐直接掉。我见过有人跑分正常一上持续负载就慢最后发现是机箱闷罐。花几十块加个机箱风扇比调半天参数都管用。6. 我的实际选择与一点经验折腾了这么多轮我现在的做法是混合日常轻量调用走 API省心高频、敏感、需要定制的任务走本地。这样既不用为了偶尔的峰值去买昂贵硬件又能在关键场景保住数据和成本优势。如果你还在犹豫我的建议是先别急着买卡。拿 API 跑一个月统计真实调用量和 token 消耗再套前面的框架算一遍。很多时候你会发现自己部署省下的钱还不够覆盖你折腾的时间。但如果你确实有数据不出本地的需求或者调用量已经稳定在高位那本地部署就是值得的而且越早跑通越早受益。最后分享一个小技巧本地部署的模型不一定要用最大的。7B 量化模型在大多数问答和摘要任务上已经够用跑得快、显存省、成本低。盲目追大模型只会让你的显卡和电费一起遭殃。先用小模型跑通业务等真的不够用了再升级这条路稳得多。 
长河君 · 2026/11/4 8:41:58 · 阅读 1.2k 自己部署大模型 vs API：成本对比与选型指南
1. 先算一笔总账自己部署大模型到底贵在哪很多人第一次冒出“自己部署大模型”的念头都是被 API 账单吓出来的。按量付费用多少扣多少看着单价不高可一旦把大模型接进业务流日调用量从几百次涨到几万次月底账单能直接翻好几倍。于是很自然地会想我买张显卡自己跑是不是就一劳永逸、彻底省钱了这个想法不能说错但只对了一半。自己部署确实能把“按次计费”变成“按硬件折旧计费”可它同时把一堆原本由服务商承担的隐性成本转移到了你自己头上。这笔账要算清楚得把显性成本和隐性成本分开看再把它们折算到同一个维度上——也就是每百万 token 的实际成本否则根本没法比。我先给一个粗略的结论方便你带着预期往下看当你的日均调用量稳定超过某个阈值、且对延迟和数据不出本地有硬性要求时自己部署才可能更便宜低于这个阈值API 几乎总是更划算。这个阈值不是固定的它取决于你选的模型规模、量化方式、硬件采购价、电费、以及你对自己时间成本的估值。下面我把每一项都拆开算。1.1 显性成本硬件、电费、折旧自己部署最直观的支出就是硬件。以目前个人和小团队最现实的方案为例一张消费级显卡比如 16GB 显存档位加上配套的主机整机落地大概在八千到一万五之间。如果跑的是 7B 到 14B 级别的模型配合 4-bit 量化16GB 显存基本能塞下推理速度也能接受。但硬件不是一次性投入就完事。显卡有折旧通常按三年摊电源、主板、散热这些也有寿命。更要命的是电费——一张满载功耗 200W 左右的显卡加上 CPU 和整机其他部件满载整机功耗轻松上 350W。按每天跑 8 小时、电价 0.6 元一度算一天电费大约 1.7 元一年就是 600 多块。如果 24 小时不间断跑一年电费直接奔着 1800 元去。把这些摊到 token 上就需要知道你的实际吞吐。一张 16GB 显卡跑 7B 量化模型用合适的推理引擎输出速度大概在每秒 30 到 60 个 token 之间。假设平均每秒 40 token每天跑 8 小时一天能产出约 115 万个 token。三年硬件折旧按 12000 元算每天折旧约 11 元加上电费 1.7 元一天总成本约 12.7 元折算下来每百万 token 约 11 元。这个数字看起来很美但它是建立在“显卡每天都在满负荷跑”的前提上的。如果你一天只调用几千次、每次几百 token那显卡大部分时间在闲置折旧却一分不少实际每百万 token 成本会飙升到几百甚至上千元这时候 API 反而便宜得多。1.2 隐性成本时间、运维、机会成本真正让“自己部署更便宜”这个结论翻车的往往是隐性成本。第一块是时间成本。从选硬件、装驱动、配环境、下模型、调推理引擎到后面处理各种报错、显存溢出、版本冲突一个新手从头跑通花掉两三个完整工作日是常态。这些时间如果折算成工资可能已经够买好几个月的 API 额度了。第二块是运维成本。自己部署意味着你要对可用性负责。显卡驱动会崩、推理服务会挂、磁盘会满、模型文件会损坏。API 服务商挂了你可以提工单自己部署挂了只能自己半夜爬起来重启。这种持续的心力消耗很难用钱量化但它是真实存在的。第三块是机会成本。你把时间花在折腾部署上就没时间花在业务本身。对于个人开发者和小团队这往往是最贵的一块。所以我在算这笔账时习惯给自己的人工按小时计价哪怕只是象征性地算也能让决策更清醒。1.3 一个可复用的成本对比框架为了让你能直接套用我整理了一个对比表。你只需要填入自己的实际数字就能得出属于自己的结论。成本项自己部署调用 API硬件采购一次性 8000-15000 元0硬件折旧按三年摊约 11 元/天0电费约 1.7-5 元/天0时间投入首次 2-3 人天后续持续几乎为 0运维心力高需自己兜底低服务商兜底单价约 11 元/百万 token满负荷按官方定价通常几元到几十元/百万 token数据不出本地可以通常不行弹性扩容差受硬件限制好随用随扩看这张表你会发现自己部署的优势集中在数据不出本地和长期满负荷下的单价而 API 的优势集中在零启动成本和弹性。所以决策的关键就变成两个问题你的数据能不能出本地你的负载能不能长期跑满2. 什么情况下自己部署才真的省钱上一节把成本拆开了这一节我直接给判断标准。因为很多人算账算到一半就迷糊了其实只需要盯住几个关键变量。2.1 调用量阈值日均多少 token 才值得自己跑这是最核心的变量。我按前面算出的“自己部署约 11 元/百万 token”作为基准再假设 API 价格是 20 元/百万 token不同模型差异很大这里取一个中间值。那么自己部署要回本你的日均 token 消耗必须达到一个门槛让折旧和电费被摊薄。粗略估算如果一天只产出 10 万 token那 12.7 元的日成本摊下来就是 127 元/百万 token远贵于 API。如果一天产出 100 万 token成本降到 12.7 元/百万 token开始接近 API。如果一天产出 500 万 token成本降到约 2.5 元/百万 token这时候自己部署的优势就非常明显了。所以一个经验性的门槛是日均稳定消耗在 100 万 token 以上自己部署才开始有经济性达到 300 万到 500 万 token优势才比较稳固。低于这个量除非你有数据不出本地的硬需求否则 API 更划算。2.2 数据敏感度什么时候钱不是第一考量有些场景下钱根本不是主要矛盾。比如你处理的是内部合同、客户隐私、医疗记录、未公开的研发资料这些数据一旦出本地就是合规风险。这时候哪怕自己部署贵一点也得自己跑。我见过不少团队明明 API 更便宜还是咬牙买了显卡原因就是数据不能出门。还有一种情况是离线环境。比如工厂车间、野外作业、内网隔离环境根本没有稳定的外网API 调不通只能本地部署。这种场景下成本对比没有意义能跑起来就是胜利。2.3 延迟与稳定性API 给不了的东西API 的延迟受网络和服务商负载影响高峰期可能抖动。自己部署的延迟相对可控尤其是局域网内调用首 token 延迟可以压得很低。对于实时交互类应用比如语音助手、在线客服这种延迟优势会直接影响体验。另外API 服务商可能限流、可能涨价、可能下线某个模型版本。自己部署虽然运维累但版本和节奏完全自己掌控。这种“确定性”对某些业务来说价值超过省下的那点钱。3. 硬件与推理引擎怎么选才不踩坑决定自己部署之后第一个现实问题就是买什么卡用什么引擎。这两件事选错后面全是坑。3.1 显卡选型显存比算力更重要跑大模型显存是第一约束不是算力。模型权重、KV Cache、中间激活值都要占显存。一个 7B 模型用 FP16 存光权重就 14GB用 4-bit 量化权重降到约 4GB但 KV Cache 还会随上下文长度增长。所以 16GB 显存是跑 7B 到 14B 量化模型的舒适区8GB 只能勉强跑 7B 且上下文不能太长。消费级显卡里显存 16GB 的型号是个人部署的甜点。再往上24GB 显存能跑更大的模型或更长的上下文但价格也上一个台阶。如果你预算有限宁可选显存大、算力稍弱的卡也不要选算力强但显存小的卡——显存不够直接跑不起来算力弱只是慢一点。注意买卡前一定确认你的电源功率和机箱空间。高端卡往往又长又厚功耗也高老电源可能带不动。3.2 推理引擎别一上来就追新推理引擎这几年更新很快vLLM、SGLang、llama.cpp、Ollama 各有侧重。我的建议是先求跑通再求快。如果你是新手想最快看到效果Ollama 是最省心的选择。它把模型下载、量化、服务化都封装好了一条命令就能跑起来适合验证和小规模使用。缺点是并发能力一般高负载下不如专业引擎。如果你要上生产、追求吞吐vLLM 是当前比较主流的选择。它用 PagedAttention 管理 KV Cache显存利用率高并发吞吐好。但它对环境和显卡驱动有要求配置起来比 Ollama 麻烦。llama.cpp 则适合 CPU 或混合推理场景量化支持非常全在资源受限的环境下很能打。如果你用的是核显或者没有独显llama.cpp 往往是唯一现实的选择。引擎适合场景上手难度并发能力Ollama个人验证、小规模低一般vLLM生产、高并发中高强llama.cppCPU/混合、资源受限中中SGLang复杂推理、结构化输出高强3.3 量化省显存的关键手段量化是把模型权重从高精度如 FP16压到低精度如 4-bit、8-bit的过程。它直接决定你的模型能不能塞进显存。4-bit 量化通常能把显存占用降到 FP16 的四分之一左右代价是精度略有损失但对大多数对话和问答任务损失几乎感知不到。常见的量化格式有 GPTQ、AWQ、GGUF 等。GGUF 主要用于 llama.cpp 生态GPTQ 和 AWQ 更多用于 GPU 推理。选量化版本时优先选社区验证过的、和你推理引擎匹配的格式别自己乱转容易出问题。4. 从零跑通本地部署的完整实操这一节我按真实操作顺序走一遍你可以直接照着做。我以 Linux 环境加一张 16GB 显卡为例这是最典型的个人部署配置。4.1 环境准备驱动、CUDA、Python第一步是显卡驱动。装驱动最稳的方式是用系统包管理器别去官网下 runfile 手动装容易和内核版本打架。装完之后用nvidia-smi确认能看到显卡和驱动版本。第二步是 CUDA 工具链。注意你不需要单独装完整 CUDA很多推理引擎会自带运行时。但如果你要自己编译某些组件就需要装对应版本的 CUDA Toolkit。版本匹配很关键引擎要求 CUDA 12.x你就别装 11.x。第三步是 Python 环境。强烈建议用 conda 或 venv 隔离别在系统 Python 里乱装。创建一个独立环境Python 版本选 3.10 或 3.11这两个版本兼容性最好。conda create -n llm python3.11 conda activate llm4.2 用 Ollama 快速验证环境好了之后先用 Ollama 跑通建立信心。安装 Ollama 后直接拉一个量化模型ollama pull qwen2.5:7b ollama run qwen2.5:7b如果能看到模型正常对话说明驱动、显存、推理链路都通了。这一步的意义是排除硬件和驱动问题把变量降到最少。很多人一上来就折腾 vLLM结果报错一堆分不清是驱动问题还是引擎问题白白浪费时间。4.3 用 vLLM 上生产验证通过后如果要做服务化换 vLLM。先装pip install vllm然后启动服务python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --dtype auto \ --max-model-len 8192 \ --gpu-memory-utilization 0.9这里几个参数很关键。--dtype auto让引擎自动选精度--max-model-len控制最大上下文设太大显存会爆--gpu-memory-utilization 0.9表示用 90% 显存留一点给系统。启动后它会暴露一个兼容 OpenAI 接口的端点你原来的 API 调用代码几乎不用改把 base_url 换成本地地址就行。4.4 压测与调优找到你的真实吞吐服务跑起来不代表能用。你得压测知道在并发多少的情况下延迟还能接受。可以用简单的脚本发并发请求观察首 token 延迟和每秒输出 token 数。调优的方向主要是两个一是调--max-num-seqs控制并发批大小二是调--gpu-memory-utilization在显存和吞吐之间找平衡。显存利用率调高能缓存更多 KV吞吐上去但留给系统的余量变小容易 OOM。这个平衡点只能实测没有万能参数。提示压测时盯着nvidia-smi的显存占用一旦接近 100% 就要警惕生产环境建议留 10% 余量。5. 常见问题与排查速查自己部署最耗人的就是排错。我把高频问题整理成表遇到时直接对照。现象可能原因排查方向启动报 CUDA out of memory显存不足降 max-model-len、提高量化等级、减并发驱动能识别但引擎报错CUDA 版本不匹配核对引擎要求的 CUDA 版本首 token 延迟极高模型未加载完或显存交换确认模型完全载入检查是否用到共享内存并发一高就崩批大小或显存余量不足降 max-num-seqs留显存余量输出乱码或重复量化精度损失或采样参数问题换量化版本调 temperature 和 top_p服务跑一段时间变慢显存碎片或缓存膨胀重启服务限制上下文长度除了表里的还有几个我踩过的坑值得单独说。第一别用系统自带的 Python依赖冲突能让你怀疑人生。第二模型文件下载要校验下到一半损坏的模型会报各种莫名其妙的错。第三日志一定要留出问题时日志是唯一线索别把输出重定向到 /dev/null。还有一个容易被忽略的点散热。消费级显卡长时间满载机箱风道不好会降频吞吐直接掉。我见过有人跑分正常一上持续负载就慢最后发现是机箱闷罐。花几十块加个机箱风扇比调半天参数都管用。6. 我的实际选择与一点经验折腾了这么多轮我现在的做法是混合日常轻量调用走 API省心高频、敏感、需要定制的任务走本地。这样既不用为了偶尔的峰值去买昂贵硬件又能在关键场景保住数据和成本优势。如果你还在犹豫我的建议是先别急着买卡。拿 API 跑一个月统计真实调用量和 token 消耗再套前面的框架算一遍。很多时候你会发现自己部署省下的钱还不够覆盖你折腾的时间。但如果你确实有数据不出本地的需求或者调用量已经稳定在高位那本地部署就是值得的而且越早跑通越早受益。最后分享一个小技巧本地部署的模型不一定要用最大的。7B 量化模型在大多数问答和摘要任务上已经够用跑得快、显存省、成本低。盲目追大模型只会让你的显卡和电费一起遭殃。先用小模型跑通业务等真的不够用了再升级这条路稳得多。