企业官网建设流程全解析

国产大模型的成本优势在这两年被反复讨论，最常听到的一个说法是“便宜 90%”。我不建议把这个数字直接当成结论，更准确的理解是：从商业 API 切换到可私有化部署的开源大模型后，推理成本确实存在大幅下降的可能，但前提是业务量、硬件配置、模型选型和部署方式都匹配。适合看这篇文章的人，是正在做技术选型、本地部署、私有化项目或者成本敏感型 AI 应用的开发者。下面按实际落地顺序拆：先算成本，再搭环境，再跑通单条请求，最后处理批量和排查问题。

标题里为什么用“偷偷”这个词，其实很好理解。很多团队不会一上来就把核心业务切到新模型，而是先在小流量场景里做验证，效果稳定了再扩大范围。整个切换过程不声张，是在等数据说话。如果你的项目也有类似打算，这篇内容能帮你少走弯路。

1. 便宜 90% 不是玄学，而是三段式降本链路

1.1 先搞清楚大模型成本到底花在哪

大模型相关成本可以拆成三块：训练成本、推理成本、数据准备成本。对多数企业来说，训练成本不是持续开销，真正每个月都在消耗的是推理成本。推理成本包括每次请求占用的 GPU 资源、模型返回 token 的数量、服务运行占用的机器时间，以及并发高峰期的排队等待。

如果使用外部大模型 API，账单通常按 token 计费。看起来单次不贵，但每天几十万次调用，每百万 token 的差价就会变成明显差距。另一个隐性成本是数据流动：业务数据经过外部接口时，可能要做脱敏、审核、日志合规，这些都会增加开发量。很多项目在早期不重视这部分，等规模上来之后，一次性补的成本比省下来的接口费用还高。

所以第一步不是急着下载模型，而是先把自己当前的账单拆开，看看钱到底花在哪个环节。是单次请求太贵，还是调用量太大，还是数据合规成本过高。只有把成本结构摸清楚，后面的降本动作才有针对性。

1.2 开源权重配合私有化部署：把计费方式从按 token 变成按机器

国产开源大模型和商业闭源模型的最大差异，是权重开放。也就是说，你可以把模型文件下载到自己的服务器或者私有云环境里。只要机器能承载推理负载，后续使用就不再按 token 向平台付费。账单结构从“每次请求消耗”变成“机器每月固定成本加电费”。

但这个转变不是无条件划算。如果你的业务每天只有几十次调用，买一台带 GPU 的服务器，成本远远高于按量调用 API。这时候本地部署更多是为了数据安全、定制化或离线环境，而不是为了省钱。反之，如果业务每天有数万到数十万次请求，或者模型需要持续跑批量任务，那本地部署的成本优势会逐步显现。

“便宜 90%”往往出现在后一种场景：原来需要为每一千万 token 付费，现在模型权重一次购买或免费下载，硬件摊销到足够多的调用量上，单次成本就会被拉得很低。要注意，这份红利不等于零成本。模型要更新、机器要维护、故障要处理，这些都会产生人力开销。

1.3 量化、蒸馏和推理框架：把模型塞进更低配置的机器

真正让推理成本大幅下降的，是模型本身被“压缩”了。量化是把参数从 fp16 精度转换成 int8 或 int4，显存占用可能直接下降一半甚至更多。蒸馏则是用更大的模型生成数据，训练一个小模型去模仿，最终保留大部分能力，但推理时便宜很多。

部署侧也有优化空间。vLLM、Ollama 这类推理框架会做批处理、连续缓存、并发调度等优化，让同样一张显卡支撑更多并发请求。这也是为什么同样一个模型，在不同部署方式下，成本和延迟差距很大。工具没选对，模型再强也白搭。

但要注意，量化不是无损的。代码生成、数学推理、逻辑判断这类对精确度敏感的任务，int4 量化后有可能掉点。int8 通常更稳，但节省的显存有限。落地前一定要拿真实业务样例测一遍，不能只看模型压缩后的显存大小就上线。

2. 部署前先算清三笔账：硬件、数据、人力

2.1 硬件账：先看显存，再看内存，最后看磁盘

部署大模型前，最容易犯的错误是只盯着模型参数量，忽略了显存、内存和磁盘的联动。模型权重只占一部分显存，推理过程中的 KV cache、中间激活值也会占空间。上下文越长、并发数越高，额外显存消耗越大。

以常见的 7B/8B 开源模型为例，int4 量化后，模型文件可能只需要 4 到 6 GB 显存；int8 大概要 8 到 10 GB；fp16 则可能超过 14 GB。这些只是参考范围，实际还要看上下文长度和并发请求数。如果你的机器只有 32 GB 内存、没有独立显卡，也能运行小尺寸模型，但速度会比较慢。CPU 推理时，内存带宽决定生成速度，每秒可能只有几个 token，适合学习验证，不适合高频生产任务。

磁盘也要留足空间。模型文件从几个 GB 到几十 GB 不等，如果还要下载多个模型，或者准备微调数据集，磁盘建议预留模型体积两倍以上的空间。部署前用df -h查看剩余空间，能避免很多“启动到一半就报错”的情况。

2.2 数据账：输入输出格式、上下文长度、并发量

先想清楚业务数据长什么样。短文本分类、长文档问答、代码补全、批量数据清洗，这四类任务对模型和资源的要求差异极大。长文档问答需要长上下文支持，而长上下文的 KV cache 会明显增加显存占用。批量清洗则需要关注吞吐量，而不是单次响应速度。

输出格式同样关键。如果你需要模型返回 JSON，就必须在提示词里明确约束，并且对模型回复做解析校验。有些模型在 JSON 格式稳定性上表现不错，但换一个量化版本，输出可能就有变化。上线前先把输入输出的样例固定下来，做成回归集。

并发量决定了机器的规格。如果业务峰值是同时 50 个请求，你就不能只按单条推理来选配置。部署时建议做一次压测，从 1 路并发逐步往上加，记录延迟、吞吐和显存变化。数据账算清楚之后，部署参数才不会拍脑袋。

2.3 人力账：模型归模型，系统归系统

本地大模型部署不是“装一个包，跑一个命令”就结束。后续还需要服务保活、日志采集、监控告警、模型更新、量化评测、权限管理。如果团队只有一个后端程序员，建议优先选择社区资料多、运维简单的模型和部署工具，避免选一个能力强但资料稀缺的方案。

人力成本还要算进模型维护。模型版本升级后，行为可能发生变化，原来的提示词可能不再稳定。需要有人负责回归测试，确保模型更新不破坏线上业务。这个岗位可以不是专职算法工程师，但至少要有一个人能看懂日志、会跑评测、知道怎么回滚版本。

如果项目对数据安全要求很高，私有化部署还需要有人懂容器、网络隔离和权限控制。大模型服务一旦暴露在公网，可能被恶意调用，造成资源和数据泄露。运维账不能省，否则后面一定会补交。

3. 从零跑通一个本地大模型的最小流程

3.1 选择一个适合起步的模型

选模型的第一原则是：先小后大，先验证流程，再追求效果。想快速跑通，优先考虑 7B/8B 级别的开源模型，资源和社区资料都比较充足。想测试更强的能力，再尝试 14B 或更大尺寸的模型。如果只有 CPU，建议选择 1.5B 到 3B 的小模型。

选模型时不要只看榜单分数。榜单任务和你的业务场景不一定匹配，要看模型卡上的显存要求、许可证是否允许商用或私有化，以及社区有没有对应的部署案例。有些模型在通用对话上表现很好，但做特定格式抽取时反而不如一个小模型稳定。对业务场景相近的样例做一次人工打分，比看十个榜单排名更有用。

3.2 用 Ollama 或 vLLM 把模型跑起来

两类部署方式可以按需求选。学习验证、单机简单调用，用 Ollama 最方便。安装完成后，拉取模型，然后运行一个交互命令就能对话。生产服务、需要支撑较多并发请求，用 vLLM 更合适，因为它在吞吐优化和批处理上做得更充分，也兼容常见的 API 接口格式，方便业务侧做切换。

启动命令不需要记死。不同版本、不同模型的参数有差异，部署前先执行帮助命令，看当前版本支持哪些参数。常见参数无非是模型路径、服务端口、并发数、上下文长度、量化精度。先把服务跑起来，再逐步调整。

3.3 发起一次推理请求验证输出

模型服务启动后，用命令行发起单条请求验证。这里给一个 Ollama 的示例，实际模型名以你拉取到的为准：

curl http://localhost:11434/api/generate -d '{ "model": "qwen2.5:7b", "prompt": "用一句话解释什么是数据库索引", "stream": false }'

如果你用的是 vLLM，接口路径通常是常见在线接口风格。示例请求大概是这样：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "/path/to/model", "messages": [ {"role": "user", "content": "讲一个数据库索引失效的例子"} ] }'

建议先跑单条任务。能跑通之后，再测多条请求。检查的关键点包括：接口是否返回 200、内容是否可读、有没有乱码、响应时间是否在预期内、显存占用是否稳定。如果单条都不过，就不要继续往下加大并发，先解决基础问题。

4. 模型效果判断：不能只看跑通，还要看三类指标

4.1 响应速度、吞吐量和并发上限

很多人在本地部署后，只会在对话框里问一句“你好”，看到回复正常就认为部署成功了。这在学习场景没问题，但进入生产前，要看三个更实际的指标。

第一是首 token 延迟。从请求发出到模型返回第一个 token 的时间，影响用户等待体验。第二是生成吞吐。每秒生成多少个 token，直接决定一个请求要等多久。第三是并发上限。同时有 20 个请求时，延迟会不会恶化到不可接受。判断标准不能拍脑袋，要看业务对延迟的要求。

测试时不要只跑一条样例。用脚本连续发 100 条请求，记录平均耗时、最大耗时、错误率。如果并发一高就超时，优先检查显存、内存、上下文长度和 max_tokens 设置。很多性能问题不是模型变慢了，而是资源占用到了上限。

4.2 输出质量：完整性、格式稳定性和语义正确性

模型能启动，不代表模型好用。输出质量建议用三套指标评估：完整性、格式稳定性、语义正确性。完整性是指模型是否漏掉关键条件；格式稳定性是指 JSON 或表格能否每次都被正确解析；语义正确性则要看业务结果是否真正可用。

准备 10 到 20 条真实业务样例，把标准答案写出来，再让模型逐一回答。对比时要注意，模型输出可能每次都不一样。这不是模型坏了，而是采样参数导致的随机性。如果温度设置得太高，输出可能每次变化很大；对格式要求高的任务，可以把温度调低一些。

4.3 稳定性：超时、重试、日志、失败率

单条测试通过后，还要做持续运行测试。建议连续运行一小时以上，观察错误率、响应时间抖动、显存占用曲线。这里最容易暴露的是内存泄漏、请求队列堆积和偶发超时。

如果单条请求正常，并发后开始报错，先看服务端日志，不要直接改模型。日志里通常能看到是超时，还是显存不足，还是请求格式错误。排查顺序应该是：先看现象，再看日志，再看资源占用，最后才动参数。

5. 批量任务和生产化部署的取舍

5.1 并发参数不要一上来拉满

批量任务最常见的问题，是一开始就把并发数拉满，结果机器 OOM 或者请求大面积超时。正确做法是先用小批量跑通，比如 5 到 10 条，确认输入、输出和日志都正常；再逐步增加到 50、100 条。每次增加并发后，观察 GPU 利用率和显存余量。

不要只看吞吐量上升，还要看单条请求延迟是否被拖垮。如果业务需要每次请求都在 3 秒内返回，但并发一高就变成 10 秒，那这个并发值就不能接受。吞吐量和延迟之间是权衡关系，不是越大越好。

5.2 失败重试、输出命名和断点续跑

批量任务如果不做失败处理，跑一半出错，很可能全部重来。这里有三个建议。

第一个建议是给每条输入加上唯一业务 ID，输出文件用业务 ID 命名，不要用时间戳代替。否则出错了，你根本不知道哪条成功了、哪条失败了。第二个建议是做状态记录。每处理完一条，就把结果写入状态文件或数据库。即使中途崩溃，重启后也能跳过已经成功的任务。第三个建议是设置失败重试策略。网络抖动、服务重启、临时显存不足都会导致请求失败，不能一失败就放弃。

这些设计听上去很基础，但我在实际项目中见过太多因为没做输出命名，最后只能靠人工比对来恢复进度的案例。批量任务能跑通只是第一步，能可靠地跑完才是生产环境的要求。

5.3 先考虑提示词工程，再考虑微调

很多团队一上来就提微调，但微调不是免费的“更好”。它需要数据清洗、标注、训练、评测，还要面对模型版本变化带来的复现问题。大部分业务需求，先用提示词约束和检索增强就能解决。

什么时候才适合微调？当任务有固定的输入输出结构、提示词已经试过但效果不稳定、模型需要学习特定领域格式或专业术语时，微调才有必要。微调之前，先积累一批典型样本，把效果不好和效果好的样例都保存下来，作为评测集。没有评测集就微调，相当于闭着眼睛改模型。

6. 常见报错和排查顺序

6.1 启动失败：先看依赖、路径和权限

启动失败的原因通常很具体，但错误提示不一定直接。如果你看到模型加载失败，先看三件事：模型路径是否存在、磁盘空间是否够、当前用户是否有读取权限。很多时候不是模型文件损坏，而是下载不完整或者路径写错了。

依赖冲突也很常见。新装的 Python 库版本可能和推理框架冲突，导致启动阶段直接报错。排查顺序是：先看启动日志的第一条异常，再确认模型路径，再查看端口是否被占用，最后检查依赖版本。不要一上来改动模型参数，很多启动问题跟参数没关系。

6.2 输出异常：先看输入格式、提示词和采样参数

模型能正常运行，但回答质量差，这时候不要急着换模型。先检查输入文本是否有多余字符、编码是否正确、提示词表达是否清晰。格式任务还要看清楚，模型返回的是不是你要求的结构。

如果输入没问题，再检查采样参数。temperature 太高会让输出随机且不稳定，top_p 设置不当也可能让结果变得保守或发散。对稳定输出要求高的任务，可以在系统提示词里明确“必须输出 JSON，不要解释”，并在代码里加上解析失败的兜底逻辑。

6.3 服务卡住或变慢：先看资源占用，再调参数

服务变慢时，第一件事是打开系统监控，看显存、内存、CPU 和磁盘读写。显存快满，说明并发数或上下文长度需要降低；GPU 利用率很低但请求很慢，说明请求在排队，或者当前批处理大小设置得不够。

调整参数时，顺序也有讲究。先减少并发，再降低 max_tokens，然后检查上下文长度，最后才考虑换量化版本或加硬件。不要同时改多个参数，否则出了问题很难判断是哪一步导致的。

我还整理了一个排查表，方便对照：

最后回到“便宜 90%”这件事。它的前提不是某个模型默认就便宜，而是业务量、部署方式、模型规模和任务要求四条线恰好匹配。我个人更建议先把单条请求跑稳，再测并发和批量，最后再决定要不要上微调。很多项目踩坑，不是模型能力不够，而是环境没准备好就急着开大规模任务。把这套顺序理顺，国产开源大模型的成本优势才会真正落到自己的账单上。