自建LLM推理全解析：成本、风险与部署方案对比
随着开源大模型能力越来越强，技术团队几乎都会遇到一个选择题：项目需要大模型能力，到底是直接调用云厂商的 API，还是自己准备一台 GPU 服务器，部署一个开源模型做自建推理服务？这个问题没有标准答案。选 API，调用简单、效果稳定，但账单会随业务量持续膨胀，数据也要经过外部接口；选自建，硬件和运维成本提前压过来，但模型和数据完全可控。
这篇文章围绕“要不要自建 LLM 推理”这个决策点展开，完整拆解成本构成、风险点、主流部署方案，并给出一个可以直接照着做的本地推理服务搭建示例。内容适合后端开发、AI 应用开发者，以及正在做技术选型的技术负责人。读完你会清楚自建方案的真实成本在哪里、风险在哪里，以及自己的业务更适合走哪条路。
1. 背景：什么是自建 LLM 推理
1.1 一句话理解“自建推理”
LLM 推理（Inference）指的是把训练好的大模型加载到内存或显存中，接收用户输入，再逐 token 生成输出的过程。所谓“自建 LLM 推理”，就是不依赖外部 API，把开源模型权重部署到自己的服务器或本地电脑上，通过 HTTP 接口、命令行或 SDK 对外提供生成能力。
打个比方：调用外部 API 类似于用在线文档，打开就能写、功能已经有人维护；自建推理类似于把文档软件部署到自己公司内网，开箱没有直接用，但数据、权限、扩展方式全都由自己控制。两者并不是谁绝对优于谁，而是不同约束条件下的选择。
需要说明的是，自建推理并不等于自己训练模型。绝大多数团队都是直接下载已经训练好的开源模型权重，比如 Qwen、Llama、DeepSeek 系列，只负责把模型“跑起来”并提供服务。真正的训练和微调是另一套完全不同的话题。
1.2 哪些场景会认真考虑自建
从实际业务看，推动自建的原因通常集中在以下几类。
- 数据敏感或合规要求高：业务数据不能发送到外部接口，尤其是金融、医疗、政务领域。自建可以把数据和模型都留在内网。
- 调用量大且稳定：当 API 月度账单持续走高，自建的一次性硬件投入会被摊薄，边际成本越来越低。
- 网络隔离或离线环境：生产环境在私有网络、无外网或弱网环境时，外部 API 根本用不了，自建几乎是唯一选项。
- 需要定制模型：微调后的模型权重只能自己部署，外部 API 无法加载你的个性化模型。
- 学习和研究目的：想理解量化、显存、吞吐、批处理这些概念，本地自建是最直观的动手方式。
1.3 自建与 API 的维度差异
两者差异可以放在一张表里看：
| 维度 | 调用 API | 自建推理 |
|---|---|---|
| 成本结构 | 按 token 付费，用量增长成本线性上涨 | 前期硬件投入大，后续边际成本低 |
| 延迟与并发 | 通常稳定，但存在限流和排队风险 | 取决于硬件与框架，波动可能较大 |
| 数据安全 | 数据离开业务方环境 | 数据留在自己环境，但需要自行加固 |
| 模型能力 | 商用闭源模型通常效果更强 | 以开源模型为主，能力受模型选型限制 |
| 维护成本 | 基本为零 | 需要持续投入运维、监控、升级 |
| 灵活性 | 只能调用现成接口 | 可量化、可调参、可微调、可私有化 |
从这个表能看出来，自建的核心优势是可控和边际成本，核心劣势则是前期投入与运维负担。后面所有章节，都是在帮你在“值不值”这件事上做量化判断。
2. 成本拆解：自建 LLM 推理的钱花在哪里
2.1 硬件成本与显存换算
自建最贵的通常是硬件，其中 GPU 又是绝对大头。模型能不能在一台机器上跑起来，核心看显存。有一个很通用的估算公式：
权重显存 ≈ 模型参数量 × 每参数字节数
FP16 精度下每个参数占 2 字节，INT8 占 1 字节，INT4 量化后大约占 0.5 字节。按这个公式看常见模型规模：
| 模型规模 | FP16 | INT8 | INT4 |
|---|---|---|---|
| 7B | 约 14GB | 约 7GB | 约 4GB |
| 13B | 约 26GB | 约 13GB | 约 7GB |
| 70B | 约 140GB | 约 70GB | 约 40GB |
注意，这只是权重部分的大致大小，实际运行还要叠加输入输出占用的 KV Cache 和框架本身的运行开销。因此建议显存至少留 20% 到 30% 的余量。经验上，7B 模型建议 16GB 以上显存，13B 模型建议 24GB 以上显存，70B 级别在单卡环境通常只能靠激进量化或多卡并行。
GPU 具体选什么、价格多少，会随市场和渠道快速变化，本文不写死具体报价。建议按“模型规模 + 上下文长度 + 预期并发”三个条件反推显存需求，再对照当时的硬件价格做预算。
2.2 量化：降低硬件门槛的关键手段
量化是把模型权重从高精度压缩到低精度，最常见的是 FP16 转 INT8 或 INT4，文件格式常见为 GGUF、AWQ、GPTQ。以 13B 模型为例，FP16 需要 26GB 显存，INT4 只需要 7GB 左右，这意味着原本需要 24GB 以上显存的部署，可以降到一块普通消费级显卡上完成。
量化不是没有代价。量化等级越低，模型回答质量、数学推理和复杂指令跟随能力通常会下降。团队在自建初期最容易犯的错误，是一味追求“跑得起来”，选了质量损失过大的量化版本，最后用户反馈变差，又回头换模型。
建议的策略是：先用 INT8 或高质量 INT4 跑通流程，评估效果是否达标；如果显存紧张，再逐步降低精度；如果质量不达标，优先换更大模型或更高精度，而不是盲目调 prompt。
2.3 电力、存储、带宽与运维成本
硬件是一次性支出，运行阶段还有几项容易被低估的持续成本。
电力是最直接的硬成本。以一块功耗 450W 的 GPU 为例，满载运行一天大约是 10 度电，一个月就是 300 度起步。如果机器长期 7×24 小时跑服务，电费会是一笔稳定且不可忽略的支出，自建方案做成本对比时一定要把这部分算进去。
存储方面，模型权重本身不小：7B 模型在量化后大约 4GB 到 8GB，70B 量化模型可能超过 40GB。如果还要配置 Python 环境、模型缓存、日志，磁盘建议至少预留 100GB 到 200GB。
带宽和网络也需要考虑。下载大模型权重需要时间和流量，如果模型服务还要对公网提供接口，就需要考虑反向代理、防火墙、HTTPS 证书和流量成本。这些通常不会写进“GPU 多少钱”的预算里，但实际运维时都会冒出来。
2.4 最容易被忽略的人力成本
硬件成本是一次性的，人力成本是持续的。环境搭建、驱动安装、CUDA 版本匹配、依赖冲突、显存 OOM、模型升级，每一件事都要有人处理。如果团队里没有人接触过 GPU 部署，第一周很可能都花在装驱动和调版本上，这个时间成本摊到项目里，未必比 API 账单便宜。
所以做成本评估时，不要只算“显卡多少钱”，要把人力和时间折算进去。更合理的做法是先安排一个人用两周时间做技术验证，把部署、压测、监控跑通，再决定是否正式自建。
3. 风险清单：自建之前必须知道的四类坑
3.1 吞吐与并发风险
代码能跑通、模型能生成，是一回事；能扛住业务并发，是另一回事。用单张消费级显卡推理 7B 量化模型，常见吞吐大概在 20 到 60 token/s 的区间，具体取决于量化等级、上下文长度和推理框架。如果业务需要同时处理几十个用户请求，又没有做并发管理，服务很快会被打满，用户会看到明显的排队和超时。
外部 API 的限流是别人的风险，自建服务的限流就是自己的风险。上线前一定要做压测，至少要搞清楚三个数字：同时在线用户数、每分钟请求量、单请求平均 token 数。然后反推需要多少并发、多少吞吐，再看当前硬件撑不撑得住。
3.2 显存与上下文长度风险
很多团队部署成功后，习惯性地把 max_tokens 和上下文窗口设到最大，结果服务跑着跑着突然报 CUDA Out of Memory。根本原因是并发请求的 KV Cache 把显存吃满了，而不只是模型权重太大。
KV Cache 的大小会随上下文长度线性增长。同一个模型，上下文从 2K 扩大到 32K，显存占用可能多出好几 GB。因此生产环境一定要在服务端限制最大上下文长度和最大并发数，同时把显存监控和 OOM 告警加上，避免服务在无人值守时挂掉。
3.3 模型许可与合规风险
开源不等于免费商用。不同模型使用不同的许可证，有些允许商业使用但要求保留版权声明，有些对商用场景有额外限制。上线商用前，一定要去模型主页查看 License 说明，而不是只看“开源”两个字。
另外，开源模型输出内容的安全性也需要自己把握。外部 API 服务通常有内容安全机制，自建后这些过滤就需要自己补上。建议在输入输出链路上增加合规过滤层，尤其是面向公众用户的产品。
3.4 依赖与版本升级风险
NVIDIA 驱动、CUDA、PyTorch、推理框架之间存在一套复杂的兼容矩阵。vLLM 升级后可能要求更高版本的 CUDA，llama.cpp 的 GGUF 格式迭代可能导致旧模型文件需要重新转换，某个 Python 包版本冲突也可能让服务直接启动失败。
降低这个风险的办法是固定环境：把部署环境做成 Docker 镜像，锁定依赖版本，任何改动先在测试环境验证再上线。不要在生产环境随手执行 pip install 和 apt upgrade。
4. 主流自建推理方案横评
4.1 Ollama：快速验证首选
Ollama 是最容易上手的自建方案之一，安装后一条命令就能下载并启动模型，内置模型管理功能，同时提供 OpenAI 兼容接口。它把模型拉取、量化、加载、服务暴露这些步骤都封装好了，适合个人开发、原型验证和小流量内部工具。
Ollama 的缺点是并发和调度能力相对简单，不适合超大规模在线业务。如果只是想快速在本地跑一个 7B 或 13B 模型验证效果，它是试错成本最低的选择。
4.2 vLLM：生产环境高并发首选
vLLM 是目前生产环境使用最广泛的推理框架之一，核心特性是 PagedAttention 和 Continuous Batching。PagedAttention 按页管理 KV Cache，能更高效地利用显存；Continuous Batching 允许把多个请求动态合并成一个 batch，整体吞吐比逐个处理高很多。
vLLM 的代价是配置相对复杂，需要理解显存利用率、最大上下文长度、并发调度等参数。适合有一定工程能力、需要稳定对外提供高并发推理服务的团队。
4.3 llama.cpp / GGUF：CPU 与边缘设备首选
llama.cpp 的特点是依赖少，支持 CPU 推理和 Apple 芯片，模型文件采用 GGUF 量化格式。它非常适合没有独立 GPU 的服务器、边缘设备，或者需要在低显存上跑大模型的场景。虽然吞吐通常比专用 GPU 框架低，但对轻量调用场景完全够用。
官方仓库已经从旧的 GitHub 地址迁移到了新组织，clone 时留意仓库迁移提示即可。GGUF 格式本身也在迭代，旧模型文件可能需要用新版本工具重新转换。
4.4 三种方案怎么选
| 方案 | 上手难度 | 并发能力 | 推荐场景 |
|---|---|---|---|
| Ollama | 低 | 中低 | 本地验证、小团队、内部工具 |
| vLLM | 中高 | 高 | 在线高并发推理服务 |
| llama.cpp | 中 | 低 | CPU 环境、边缘设备、低显存机器 |
选择逻辑很简单：先确定硬件条件和业务并发，再选框架。没有 GPU 就用 llama.cpp 或直接乘公共云；有 GPU 且并发不高用 Ollama；并发高、要长期稳定运行就上 vLLM。
5. 完整实操：搭建一个本地推理服务
5.1 环境准备
下面以 Ubuntu 22.04 为例演示，你在自己的服务器或电脑上操作时，重点是确认三件事：是否有 NVIDIA 显卡、显存是否足够、驱动是否装好。
先检查 GPU 是否被系统识别：
如果命令报错，说明驱动没有安装好，需要先装 NVIDIA 驱动。nvidia-smi 右上角会显示当前 CUDA 版本，后续安装 PyTorch 时选择对应版本即可。示例中假设机器有 16GB 以上显存，使用 Python 3.10 或更高版本。
本文示例使用的模型名、框架命令以当前官方文档为准，不同版本参数可能略有差异，重点看配置思路而不是死记命令。
5.2 通过 Ollama 快速部署
安装 Ollama 后，拉取并运行一个 7B 模型：
ollama run 会自动进入一个交互式对话窗口。退出后，服务默认监听 11434 端口。可以用 curl 验证生成接口：
正常情况会返回一段 JSON，其中包含模型生成的文本和本轮消耗的 token 数量。需要注意，模型名和具体版本号以 Ollama 官方仓库为准，执行之前可以先 ollama list 查看本地已有的模型。
5.3 通过 vLLM 部署 OpenAI 兼容服务
如果目标是高并发的生产环境，可以用 vLLM 启动服务：
启动命令：
参数含义：
--model：Hugging Face 上的模型名或本地模型目录路径。--host和--port：服务监听地址和端口。--gpu-memory-utilization：最多使用多少比例的显存，这里设置为 0.9。--max-model-len：限制最大上下文长度，防止 KV Cache 爆显存。
启动后用 curl 走 OpenAI 风格的 chat 接口：
这里有个常见问题：vLLM 启动时需要联网下载模型权重，速度可能很慢。建议先通过 ModelScope 或 Hugging Face 等渠道把权重下载到本地，再把 --model 参数指向本地目录，这样后续启动速度快很多，也能避免网络抖动导致启动失败。
5.4 性能观测与验证
启动服务后，另开一个终端实时观察显存：
Ollama 环境下可以用 ollama ps 查看当前加载了哪些模型。vLLM 通常内置 Prometheus 指标暴露，具体路径和参数以当前版本文档为准。
更简单的验证方式是写一个小脚本，循环发送请求，记录每次响应的总耗时、输出 token 数和首 token 延迟。通过对比不同并发下的表现，就能判断当前环境是否满足业务预期。这里不建议把压测结果当成绝对性能标准，因为不同硬件、模型、量化等级差异很大，重点是建立自己的基线数据。
6. 常见问题与排查思路
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
| 启动时报 CUDA out of memory | 模型权重加 KV Cache 超过显存 | 换更小量化模型，调低 max-model-len，降低并发 |
| 服务能启动但生成极慢 | 实际用的是 CPU 推理或 GPU 太老 | 检查 nvidia-smi 是否识别 GPU，换 GPU 或换轻量模型 |
| 并发一多就排队或超时 | 缺少并发控制和批处理能力 | 接入 vLLM，设置排队上限，扩容 GPU |
| 运行一段时间后突然 OOM | KV Cache 随请求不断累积 | 重启服务，限制上下文长度，增加显存监控 |
| 回答问题质量明显下降 | 量化等级太低或模型选型不当 | 换回更高精度，或选更大的模型 |
| pip 安装 vllm 失败 | CUDA 版本与预编译包不匹配 | 升级驱动，按官方文档选择匹配版本 |
| 下载模型总是超时 | 网络不稳定或被限速 | 配置镜像源，或手动下载后导入本地模型目录 |
遇到问题不要一上来就改代码，按顺序确认：硬件是否被系统识别，驱动与 CUDA 是否匹配，模型格式是否被推理框架支持，显存是否足够，上下文长度是否被限制。大多数自建失败都出在这几步里。
7. 工程建议与最佳实践
7.1 用三个指标决定 API 还是自建
第一个指标是峰值 QPS 和 token 消耗。如果每天只有几百次调用，自建很难省下钱；如果每天消耗上百万 token 且仍然在增长，自建的优势会越来越明显。
第二个指标是延迟要求。交互式聊天对首 token 延迟敏感，批量离线任务对整体吞吐敏感，这两种场景对硬件和框架的要求完全不同，要分开评估。
第三个指标是数据敏感度。数据不能出域、不能进外部 API 的场景，即使自建成本更高也必须做，这是合规和安全性问题，不是成本问题。
7.2 自建服务上线前要做的事
自建服务如果只做成 Demo，风险并不高；一旦面向业务开放，至少要做这几件事：放在反向代理后面，增加 API Key 或内部鉴权，不要裸奔在公网；限制最大并发数和最大上下文长度；加显存、GPU 利用率、请求错误率监控；配置进程退出和模型加载失败时的自动重启；保留一条切回外部 API 的逃生通道。
很多团队自建翻车，不是因为模型不行，而是服务没有熔断、没有限流、没有监控，出了问题只能人肉上山重启。生产环境宁可多做一层限制，也不要先上线再补救。
7.3 混合架构：API 与自建互补
最稳妥的方案往往不是二选一，而是混用。日常稳定流量走自建服务，突发流量或大促期间自动切换部分请求到外部 API；敏感请求走自建，普通公开问答走 API。这样既控制了成本，又保留了兜底能力。
混用架构的关键是抽象出一层统一的模型网关，让上游业务只感知一个接口，后端路由到自建还是 API 由网关决定。这样后续切换模型、调整流量比例都不会影响业务代码。
7.4 ComfyUI 和 LLM 必须装在同一台电脑上吗
这个问题在 AI 生成类工具用户里很常见。答案是不需要。ComfyUI 是本地运行的图像生成工作流工具，LLM 推理服务可以部署在任何一台网络可达的机器上，两者通过 HTTP API 通信。就算在同一台电脑上，也不是“必须”，只是配置起来更省事。
反过来也一样，ComfyUI 想调用一台局域网内 GPU 服务器的 LLM 服务，只要网络连通、接口地址填对，本质上就是一次普通 HTTP 调用。需要考虑的只是跨机器调用时的网络策略、接口鉴权和超时配置，而不存在“必须同机”的限制。
7.5 决策清单
| 判断项 | 更倾向 API | 更倾向自建 |
|---|---|---|
| 调用量 | 低、不稳定 | 高、稳定增长 |
| 数据隐私要求 | 一般 | 高 |
| 团队 GPU 运维经验 | 没有 | 有 |
| 延迟与并发要求 | 不敏感 | 在线交互要求高 |
| 模型定制与微调需求 | 不需要 | 需要 |
| 合规约束 | 无 | 数据不能出域 |
如果这张表里自建那一列占了多数，再考虑自建；否则建议先用 API 把业务跑起来，把省下来的时间花在产品和模型效果验证上。
8. 决策建议与下一步学习方向
自建 LLM 推理不能单纯理解成“省钱方案
45 6 3 7 331 395 1944 453 1729 976 1662 399 373 984 409 447 527 871 659 1686 1555 905 544