企业官网建设流程全解析

本地跑大模型这件事，我从最早拿一张 8G 显存的卡硬啃量化模型开始，到后来帮团队做私有化部署、再到日常大量调用各家 API 做业务，前后折腾了两年多。中间踩过的坑足够写一本小册子：显存爆了、量化后效果崩了、API 账单月底一看吓一跳、并发一上来接口就开始超时。所以每次有人问我"到底该本地部署还是调 API"，我都不太愿意给一个非黑即白的答案，因为这个问题本身就问错了方向——它不是一道二选一的判断题，而是一道取决于你场景、预算、数据敏感度和团队能力的匹配题。

这篇内容我想把这件事彻底讲透。不管你是刚入门想在自己电脑上跑个模型玩玩的个人开发者，还是正在给公司做技术选型的负责人，我都会从成本、数据、效果、运维、扩展性这几个维度，把本地部署和 API 调用的真实差异摊开来讲，并且给出可以直接抄作业的判断标准和实操路径。核心关键词就三个：大模型、本地部署、API。读完你应该能清楚地知道，自己手上这个需求到底该走哪条路。

1. 先把"本地部署"和"调 API"的本质差异说清楚

很多人一上来就纠结选哪个，其实是因为没搞明白这两条路在底层到底差在哪。我见过太多人把"本地部署"简单理解成"省钱"，把"调 API"简单理解成"方便"，这种认知会让你在选型时做出完全错误的决定。

1.1 本地部署：你买断的是"运行权"和"数据控制权"

本地部署的本质，是你把模型的权重文件下载到自己的机器上，用你自己的算力去跑推理。这个模型从此就"住"在你的硬盘和显存里，断网也能用，数据不出你的机器。你付出的成本是硬件（显卡、内存、电费）和运维精力，换来的是完全的数据掌控和不受调用次数限制的使用权。

这里有个关键点很多人忽略：本地部署买断的是"运行权"，不是"所有权"。你下载的模型权重依然受它的开源协议约束，商用要看 license，有些模型明确禁止某些用途。我见过有团队直接拿某个模型做商业产品，结果发现协议里写了非商用，最后被迫换模型重做适配，白白浪费两周。

从技术栈上看，本地部署现在主流是走Ollama、llama.cpp、vLLM这几条路线。Ollama 适合个人和小团队快速起步，一条命令就能拉模型跑起来；llama.cpp 对硬件要求最低，CPU 也能跑，量化支持最全；vLLM 则是生产级高并发场景的首选，吞吐量能甩开前两者一大截。选哪个取决于你的并发量和硬件条件，后面我会详细展开。

1.2 调 API：你租用的是"推理能力"，按量付费

调 API 的本质，是别人把模型部署好了，你通过网络请求把 prompt 发过去，对方返回结果，你按 token 数量付费。你不需要关心显卡、显存、并发、模型更新，这些全是服务方的事。你付出的成本是调用费用和网络依赖，换来的是零运维、随时可用最新最强的模型。

API 这条路最大的隐性优势是"模型永远是最新的"。今天出了个更强的模型，你改个模型名参数就能用上，不用重新下载几十 G 的权重、不用重新调优。但代价也很明显：数据要出你的内网，调用量大了账单会失控，而且你的服务稳定性直接绑在对方的可用性上——对方一抖动，你的产品就跟着抖。

1.3 一张表看清两条路的真实差异

我把这两条路的核心差异整理成了一张对照表，这张表是我在实际选型时反复用的判断依据：

看懂这张表，其实选型已经完成了一半。剩下的就是把你自己的具体场景往这张表里套。

2. 成本这笔账，到底该怎么算才不亏

成本是大多数人做决策时第一个想到的因素，但也是最容易算错的因素。我见过太多人只算了显卡钱，没算电费和人力；也见过有人觉得 API 贵，结果一算发现自己那点调用量用 API 一年才几百块，买张卡却要上万。

2.1 本地部署的隐性成本清单

本地部署的成本绝不只是那张显卡。我把它拆成几块：

• 硬件成本：这是最显性的。一张能舒服跑 7B 量化模型的卡，二手 3090（24G）大概几千块；要跑 32B 甚至 70B，就得考虑 A6000、4090 甚至多卡，成本直接上万到几万。
• 电费成本：一张 350W 的卡满载跑，加上整机功耗，一小时大概 0.5 度电。如果 7x24 常驻，一个月电费就是一两百块。别小看这个数，长期跑下来不是小钱。
• 人力运维成本：这是最容易被低估的。部署、调优、监控、故障处理、模型更新，这些都要人。一个能熟练维护推理服务的工程师，人力成本远高于硬件本身。
• 机会成本：你花在折腾部署上的时间，本可以用来做业务。这个账最难算，但往往最贵。

我个人的经验是：如果你的调用量不大，本地部署几乎永远算不过 API。只有当你的调用量足够大、或者数据绝对不能出内网时，本地部署的经济性才成立。

2.2 API 成本的真实计算方式

API 的计费单位是 token，分输入和输出两部分，输出通常比输入贵。以目前主流的价格区间来看，便宜的模型每百万 token 几毛到几块钱，贵的闭源模型每百万 token 几十甚至上百块。

这里有个实操技巧：算 API 成本时，一定要按"输入+输出"的总 token 算，并且要预估你的平均对话长度。很多人只看了单价觉得便宜，结果自己的场景是长文档处理，一次请求输入就几万 token，成本瞬间翻几十倍。

举个我实际遇到的例子：有个团队做合同审查，每份合同平均 2 万字，一次请求输入约 3 万 token，输出约 2 千 token。按某中端模型的价格算，单次成本大概几毛钱。如果一天处理 500 份，一个月就是几千块。这个量级下，本地部署一张卡反而更划算——这就是典型的"高频长文本"场景，本地部署的经济性开始显现。

2.3 盈亏平衡点怎么估算

我一般用一个简单的公式来估算盈亏平衡点：

本地部署总成本（硬件+年运维+年电费）÷ API 单次调用成本 = 需要多少次调用才能回本

假设本地部署一次性投入 1.5 万，年运维折算 2 万，年电费 2 千，一年总成本约 3.7 万。如果 API 单次调用平均 0.1 元，那么一年需要调用 37 万次才能打平，平均每天约 1000 次。低于这个量，API 更划算；高于这个量，本地部署开始有优势。

这个公式不精确，但能帮你快速建立量级感。关键不是算得多准，而是别拍脑袋。

3. 数据敏感度：很多场景根本没得选

成本可以算，但数据敏感度这件事，很多时候是"一票否决"的。我把它单独拎出来讲，是因为它经常被技术团队忽略，直到出事才后悔。

3.1 什么数据绝对不能出内网

以下几类数据，我的建议是无条件本地部署，不要有任何侥幸心理：

• 个人身份信息：身份证号、手机号、住址、生物特征等。
• 企业核心商业数据：财务数据、客户名单、未公开的产品设计、源代码。
• 医疗健康数据：病历、诊断记录、基因数据。
• 法律合规要求的数据：某些行业有明确的数据本地化要求。

这些数据一旦通过 API 传出去，你就失去了对它的控制。哪怕服务方承诺不存储、不训练，传输过程本身就是一个风险面。我见过有团队为了省事，把用户聊天记录直接发给 API 做分析，后来被合规部门叫停，整个功能推倒重来。

3.2 数据脱敏能不能解决问题

有人会说，那我先把敏感信息脱敏再发给 API 不就行了？这个思路对，但实操中很难做到万无一失。脱敏本身需要一套规则和工具，规则漏了、工具错了，敏感信息照样泄露。而且很多场景下，脱敏后的数据会丢失关键上下文，模型效果直接崩掉。

我的经验是：脱敏适合"敏感信息占比低、且能明确识别"的场景，比如把手机号替换成占位符。但如果整个文档都是敏感的，脱敏就等于把内容删光了，没有意义。这种情况下，本地部署是唯一选择。

3.3 混合架构：敏感走本地，通用走 API

实际生产中，最务实的方案往往是混合架构。我帮几个团队落地过这种模式：

• 敏感数据、核心业务：走本地部署的模型，数据不出内网。
• 通用问答、非敏感任务：走 API，享受最强模型的效果。
• 路由层做判断：在请求入口加一个分类器，判断这个请求该走本地还是走 API。

这种架构的好处是兼顾了成本和效果，坏处是复杂度上去了，需要维护两套推理链路。但对于中大型团队来说，这是性价比最高的方案。我后面会讲怎么落地这个路由层。

4. 效果与模型能力：本地能跑的和 API 能用的差多远

这是很多人最关心的问题：我自己本地跑的模型，和 API 上那些最强模型，效果到底差多少？答案取决于你本地能跑多大的模型。

4.1 本地能跑的模型规模受什么限制

本地能跑多大的模型，核心瓶颈是显存。模型推理时，权重、KV Cache、激活值都要占显存。粗略估算，FP16 精度下，模型每 10 亿参数约需 2G 显存。也就是说：

• 7B 模型 FP16 约需 14G 显存
• 13B 模型约需 26G
• 70B 模型约需 140G（单卡基本不可能，需要多卡）

但通过量化，这个门槛能大幅降低。4-bit 量化后，7B 模型只需约 4-5G 显存，13B 约 8G，70B 约 40G。这就是为什么 16G 显存的卡能跑 13B 量化模型，24G 的卡能跑 32B 量化模型。

注意：量化会损失精度，4-bit 量化在大多数任务上效果下降不明显，但在需要精确推理、代码生成、数学计算的任务上，损失会比较明显。我一般建议关键任务用 8-bit 或 FP16，通用任务才用 4-bit。

4.2 量化对效果的真实影响

我做过一组对比测试，同一个 13B 模型，分别用 FP16、8-bit、4-bit 跑同一批任务：

结论很清晰：通用对话任务，4-bit 量化完全够用；但代码和数学这类需要精确性的任务，量化损失不能忽视。如果你的场景是代码助手，我建议至少用 8-bit，或者干脆上更大的模型。

4.3 本地模型和顶级 API 模型的差距

说实话，本地能跑的模型（哪怕 70B）和 API 上那些顶级闭源模型之间，在复杂推理、长上下文理解、指令遵循上还是有明显差距的。这个差距在简单任务上几乎看不出来，但在复杂任务上会被放大。

我的判断标准是：如果你的任务"错了也无所谓"或者"人工会复核"，本地模型够用；如果任务要求高准确率且无人复核，优先考虑 API 的强模型。比如做内部知识库问答，本地模型答错了员工自己会判断；但如果是自动生成对外报告，那就得用最强的模型兜底。

5. 运维与扩展性：被严重低估的选型因素

技术选型时大家爱聊效果和成本，但真正让项目翻车的，往往是运维和扩展性。这块我有过血泪教训。

5.1 本地部署的运维坑

本地部署不是"部署完就完事"，它是一套需要持续维护的服务。我踩过的坑包括：

• 显存泄漏：长时间运行后显存不释放，服务越来越慢，最后 OOM。解决办法是加健康检查，定期重启，或者用 vLLM 这类内存管理更好的框架。
• 并发上不去：单卡跑 Ollama，并发一高就排队。要提升并发，要么上 vLLM 做连续批处理，要么加卡做负载均衡。
• 模型更新麻烦：每次换模型都要重新下载、重新测试、重新调参，不像 API 改个名字就行。
• 监控缺失：没有监控就不知道服务什么时候挂了、延迟什么时候变高了。至少要监控 QPS、延迟、显存占用、错误率这几个指标。

5.2 API 的稳定性风险

API 也不是没有运维问题，只是问题从"你的机器"转移到了"对方的服务"。你需要处理：

• 限流：免费或低价套餐通常有 QPS 限制，超了就报错。生产环境一定要买够配额，或者做多供应商备份。
• 超时和重试：网络抖动、对方负载高都会导致超时。必须做重试机制，但要注意幂等性，别把一次请求重试成多次扣费。
• 供应商锁定：深度绑定一家 API，对方涨价或调整策略你就被动。建议抽象一层调用接口，方便切换供应商。
• 上下文长度限制：不同模型的上下文窗口不一样，超了会直接报错。我见过有人没注意上下文限制，长文档一提交就 400 错误。

5.3 扩展性对比：谁更容易扛住增长

从扩展性看，API 天然更容易横向扩展——你的量涨了，多买配额就行，不用管底层。本地部署的扩展则是"阶梯式"的：加一张卡能提升一档，但加卡涉及硬件采购、机箱空间、电源、散热，周期长、成本高。

所以我的建议是：如果你的业务量预期会快速增长且不确定，优先 API，把扩展性交给服务方；如果业务量稳定且可预测，本地部署的扩展成本更可控。

6. 实操：两条路分别怎么落地

讲完选型逻辑，该上实操了。这部分我给两条路都准备了可以直接抄的步骤。

6.1 本地部署：用 Ollama 快速起步

Ollama 是目前个人和小团队本地部署最省心的选择。安装和跑通只要几步：

# 安装（以 Linux 为例） curl -fsSL https://ollama.com/install.sh | sh # 拉取并运行一个模型 ollama run qwen2.5:7b # 查看已下载的模型 ollama list # 以服务方式启动，供其他程序调用 ollama serve

跑起来后，默认在11434端口提供兼容 OpenAI 格式的接口，可以直接用 HTTP 调用：

curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": "你好"}] }'

Ollama 的优点是简单，缺点是并发能力弱。如果你的场景是多人同时用，建议换 vLLM：

# vLLM 启动示例 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --max-model-len 8192

vLLM 的连续批处理能把吞吐量提升好几倍，代价是配置更复杂、对显存要求更高。

6.2 调 API：抽象一层调用接口

调 API 的关键不是"怎么调"，而是"怎么调得稳、调得省、调得可切换"。我的做法是抽象一层统一的调用接口，把供应商差异屏蔽掉：

import time import requests class LLMClient: def __init__(self, providers): # providers 是一个列表，每个元素包含 base_url、api_key、model self.providers = providers def chat(self, messages, retries=3): last_err = None for provider in self.providers: for attempt in range(retries): try: resp = requests.post( f"{provider['base_url']}/chat/completions", headers={"Authorization": f"Bearer {provider['api_key']}"}, json={"model": provider["model"], "messages": messages}, timeout=60, ) resp.raise_for_status() return resp.json() except Exception as e: last_err = e time.sleep(2 ** attempt) # 指数退避 raise last_err

这段代码做了三件事：多供应商备份、失败重试、指数退避。生产环境里这三样缺一不可。多供应商备份能防止单点故障，重试能扛住偶发网络抖动，指数退避能避免在对方过载时雪上加霜。

6.3 混合路由：让请求自己找对路

如果你决定走混合架构，路由层是核心。最简单的实现是基于规则的分类：

SENSITIVE_KEYWORDS = ["身份证", "合同", "财务", "病历"] def route(messages): text = " ".join(m.get("content", "") for m in messages) if any(kw in text for kw in SENSITIVE_KEYWORDS): return "local" # 敏感内容走本地 return "api" # 其余走 API

规则路由简单但不够智能，容易漏判。进阶做法是训练一个小分类器，或者用一个小模型来判断请求的敏感度。我一般建议先用规则跑起来，收集一段时间的误判案例，再迭代成分类器。

7. 我的选型决策树与几个真实案例

讲了这么多维度，最后落到"到底怎么选"。我把自己常用的决策逻辑整理成一棵决策树，你可以直接照着走。

7.1 三步决策法

第一步：数据能不能出内网？

• 不能 → 本地部署，没得商量。
• 能 → 进入第二步。

第二步：调用量有多大？

• 低频（每天几百次以内）→ API，省心省钱。
• 高频（每天上千次以上）→ 进入第三步。

第三步：任务对效果要求高不高？

• 要求高且无人复核 → API 强模型，或本地大模型+人工复核。
• 要求一般或有人复核 → 本地部署，成本更优。

这三步走下来，90% 的场景都能定下来。剩下的 10% 是边界情况，需要具体分析。

7.2 三个真实场景的选型

场景一：个人开发者做 AI 写作助手调用量低，数据不敏感，追求效果。选 API，用中端模型，一个月成本几十块，比买卡划算得多。

场景二：企业内部知识库问答数据敏感（内部文档），调用量中等，效果要求一般。选本地部署，用 13B 量化模型，数据不出内网，员工自己判断答案对错。

场景三：电商客服自动回复调用量高（每天几万次），数据部分敏感（含用户信息），效果要求中等。选混合架构，用户隐私相关走本地，通用问答走 API，路由层做分流。

7.3 几个容易踩的坑

最后分享几个我在选型时踩过的坑，帮你避雷：

• 别为了省钱硬上本地：如果调用量不大，本地部署的隐性成本（时间、运维）远超 API 费用。
• 别忽视上下文长度：本地模型和 API 模型的上下文窗口差异很大，选型时一定要确认你的场景需要多长的上下文。
• 别只测一个模型：同一个任务，不同模型效果差异巨大。选型阶段至少测 3-5 个候选模型。
• 别忘了留退路：无论选哪条路，都要设计好切换方案。API 要能换供应商，本地要能换模型。

我个人在实际操作中的体会是，选型这件事没有标准答案，只有"当前阶段最合适"的答案。业务在变，模型在变，成本结构也在变，所以选型不是一次性的决定，而是需要定期复盘的持续过程。我一般每季度会重新评估一次，看看当前的方案是不是还最优。有时候一个模型降价、或者一个新开源模型发布，整个选型结论就变了。保持这种动态视角，比一次性选对更重要。