企业官网建设流程全解析

先交代一下背景：我过去两年基本把业余时间全砸在了大模型这条路上，从最早拿聊天机器人当玩具，到后来调 API 做自动化工具，再到现在帮朋友的小公司做私有化部署和行业微调，算是亲眼看着这个圈子从“玩具阶段”一路卷成了“基础设施”。最近后台收到不少私信，问得最多的就是两类问题：一类是“现在到底哪些大模型值得关注”，另一类是“我想把大模型接到自己项目里，该从哪下手”。这两类问题其实都指向同一个需求：在大模型遍地开花的今天，普通开发者和中小团队到底怎么从一堆名字里选出真正能用、能落地的那一个。

这篇笔记就从这个角度出发，沿着“模型维度”和“应用维度”两条线，把国内外主流的大模型和应用做一次系统性梳理。模型维度我会讲清楚每个阵营的代表选手、它们擅长什么、适合谁用；应用维度我会拆解普通用户、开发者、行业客户三个层面的真实玩法；最后再手把手带你走一遍本地部署、量化选型、微调的完整流程，把我在实操中踩过的坑和排查心得也一并倒出来。内容会比较长，建议先收藏，按需跳读。

1. 先看清地型：国内外大模型的“名门”与“新锐”

1.1 海外阵营：闭源领跑与开源追击

海外市场这些年基本是两条路线并行。闭源路线里的第一梯队，自然是 OpenAI 的 GPT 系列，从 GPT-4 到后来的 GPT-5 系列，依然是综合能力最稳的选择，尤其在复杂推理、代码生成、多轮对话这些通用任务上，长期霸榜并不意外。它的优势不只是模型本身，还有围绕 API 建立起来的一整套生态，插件、函数调用、Assistant API，开发者想接什么场景都有现成工具。

另一家不能忽视的是 Anthropic 的 Claude 系列。Claude 在长上下文理解、代码工程和 Agent 类任务上表现非常突出，我实际用下来，它在处理“超长文档 + 结构化输出”这类需求时，回复质量往往比同级别的其他模型更细腻，而且更愿意遵循复杂的系统提示词。很多做 Agent 工作流的团队，最后都会在 GPT 和 Claude 之间二选一，不是没有理由的。

谷歌的 Gemini 系列则是多模态路线的代表，原生就能处理文本、图片、音频和视频，不像有些模型是“先文字后外挂视觉模块”。如果你要做视频理解、图文混合分析这类场景，Gemini 的性价比优势非常明显。开源阵营这边，Meta 的 Llama 系列和欧洲 Mistral 系列是绕不过去的名字，Llama 胜在社区生态庞大，任何新工具出现，第一个支持的准是它；Mistral 则是在参数效率和法语/多语言能力上有一手，中小模型在很多单任务上表现惊艳。

1.2 国内阵营：性价比与开源生态的突围

国内大模型这几年的进展，说实话比我预想的快得多。如果要选一个“最出圈”的代表，DeepSeek 系列肯定跑不掉。DeepSeek 的 V3 和 R1 系列在数学、代码、逻辑推理上的表现，已经能和海外第一梯队正面掰手腕，而且它的 API 定价低到一个离谱的程度，很多小团队和个人开发者都是拿它当日常主力模型用的。R1 这种推理模型，特别适合那种需要“慢慢想”的任务，比如复杂的数学题、结构化分析，你给它时间让它输出思维链，结果往往比直接问一个普通模型好很多。

阿里系的开源模型 Qwen 系列则是另一个重要支柱。Qwen 的开源生态做得非常完善，从 0.5B 到 72B 的模型都有，训练代码、微调工具、量化版本一应俱全。我做本地部署和行业微调时，首选底座基本都是 Qwen 系列，原因很简单：中文能力强、社区教程多、踩坑经验容易搜到，而且它对消费级显卡的适配非常友好。字节的豆包在 C 端产品上发力很猛，App 体验流畅，语音交互、AI 搜索、创作工具都做得接地气。月之暗面的 Kimi 则靠“超长上下文”这个标签打出了名气，读几百页 PDF 对它来说是小菜一碟，很多学术党把长文档分析都交给它。智谱的 GLM 系列在工具调用和本地化部署支持上也有自己的积累，MiniMax 则在语音和多模态方向走出了差异化路线。

1.3 一句话选型对照表

看了一堆名字，很多人更想知道的是：我到底该选哪个？我这里整理了一张截至 2026 年 9 月的选型对照表，基于我自己的使用体验和公开评测数据，未必绝对准确，但足够当个起点：

这张表的核心逻辑很简单：闭源模型负责“最强效果”，开源模型负责“自由掌控”，国内模型负责“中文场景和性价比”。没有哪个模型是万能的，选型的第一步永远是明确你自己的场景边界。

2. 应用维度：模型是发动机，产品才是整车

2.1 普通用户每天在用的 AI 应用

对大多数不写代码的用户来说，模型本身不重要，重要的是“哪个 App 让我觉得好用”。这就像买车，没人天天研究发动机参数，大家在乎的是坐进去舒不舒服、方向盘跟不跟手。C 端 AI 应用这两年最大的变化，就是从“对话框”走向了“工作台”。

之前你打开 ChatGPT、通义、豆包，就是一个聊天框，现在再看，几乎每个主流应用都长出了一个“工具集合”：写作助手、PPT 生成、会议纪要、图片理解、语音实时翻译、数据分析都塞进了同一个入口。我身边很多朋友现在写周报、做 PPT 大纲、给娃辅导作业，都是直接打开手机里的 AI 应用说一句话就能搞定，根本不在乎底层跑的是 GPT 还是 Qwen。

这背后其实是应用层的一个共识：模型能力差距正在缩小，产品体验和场景覆盖才是留住用户的护城河。比如谷歌的 NotebookLM 能把一堆资料变成播客式音频概述，这种“把学习变成听故事”的体验就是典型的产品创新。再比如各种 AI 编程工具，从 GitHub Copilot 到 Cursor，它们共同的特点不是模型多强，而是把“懂代码上下文”和“实时补全”做到了极致，让你感觉 AI 真的融进了编辑器里，而不是每次还得切到网页去复制粘贴。

2.2 开发者视角：API、RAG、Agent 与 MCP

开发者接大模型，路径其实比大家想象中标准：先是学会调 API，然后开始做检索增强生成，再往上就是搭 Agent 工作流。API 层面，各家大厂基本都提供兼容 OpenAI 格式的接口，你只需要把 base_url 换成对应服务商的地址，代码改动量很小，所以现在做 AI 应用开发，最低门槛其实就是“会写 Python + 会读文档”。

RAG 是这两年落地最广的技术路线。核心思路简单到有点“笨”：先把你的私有文档切块，做向量化存进数据库，用户提问时先检索出最相关的片段，再把这些片段拼进提示词里送给大模型生成回答。这么做的好处显而易见，不需要微调就能让模型“知道”你的业务知识，更新知识也只需要重新索引文档，成本极低。我给别人做客服机器人和内部知识库，八成都是这个架构。

Agent 则比 RAG 更进一步。它让模型不只回答问题，而是能调用工具、执行动作。比如用户说“帮我调研一下某行业的竞品”，Agent 会自己拆解任务、调搜索引擎、写摘要、生成报告。2025 年以来 MCP 协议兴起，等于给 AI 定了一个“万能插头标准”，各种外部工具只要实现了 MCP，Agent 就能直接调用，这解决了早期每个工具的连接都需要定制开发的问题。我现在的项目里，文件处理、数据库查询、网页请求基本都是走 MCP 插件，省掉的对接工作量非常可观。

2.3 行业落地：科研、编程、客服这些场景怎么吃大模型

单纯讨论“模型多强”意义不大，真正值钱的是“在具体行业里怎么用”。先拿科研场景举例，后台经常有人问“写科研论文最好用哪个 AI 大模型”，我的回答是：先用你上手的开源或便宜闭源模型做初稿和润色，最后定稿阶段再让顶级闭源模型帮你审逻辑。论文写作的真正痛点不是“措辞不够华丽”，而是“思路不够连贯、文献梳理太碎”，所以长上下文模型在这里优势极大，把整篇论文的 abstract、method、result 全部塞进去让它审视，比一句一句问有效得多。

编程场景是另一个被大模型彻底改造的领域。像 Cursor 这类 AI IDE 已经改变了我的日常开发节奏：以前是“我写代码，机器执行”，现在是“我描述意图，AI 写骨架，我改关键逻辑”。对于原型验证和脚本类任务，AI 编程的效率提升可能有三到五倍。但要注意，代码审查和关键模块设计仍然需要人来把关，模型生成的代码在边界条件和安全校验上往往很敷衍，生产环境可不能直接照搬。

客服和内部问答则是企业落地最集中的地方。方案一般是这样：拿开源模型做底座，用公司文档搭 RAG 知识库，再通过 API 暴露给内部系统或外呼机器人。这么做的好处是数据不出内网，合规压力小；坏处是初期检索准确率很难一步到位，需要反复调 chunk_size、embedding 模型和重排序策略。这一块没有捷径，就是拿真实问题去打测试集，一版一版迭代。

3. 从“看过”到“跑起来”：部署、微调与本地化实战

3.1 部署前先算一笔账：显存、精度与参数量

很多人本地部署失败，不是模型不行，而是买卡前没算清楚账。部署大模型的显存需求有个粗略公式：显存占用约等于参数量乘以精度字节数，再乘一个 1.2 的额外开销系数。以 7B 模型为例，FP16 精度下差不多是 7GB 参数乘以 2 字节，再乘 1.2，约等于 16.8GB 显存；如果量化到 INT4，每个参数只占约 0.5 字节，总占用就降到 4.2GB 左右，普通游戏显卡都能轻松跑起来。

所以选显卡和选模型是联动决策。如果只打算跑 7B 到 8B 量级的量化模型，RTX 4060 Ti 16G 就能获得不错体验；想跑 14B 级别的模型，需要 24G 显存，RTX 4090 或者 3090 是主流选择；至于 70B 级别的大家伙，哪怕量化后也要 35GB 以上显存，一张消费级卡根本塞不下，得考虑多卡并联或者直接用云服务器。NVIDIA 显卡在生态上最省心，绝大多数框架开箱即用；AMD 卡如 RX 6750 GRE 性价比高，但得折腾 ROCm 适配，新手我一般不建议上来就挑战。

还有个常见误区：“是不是模型越大越好？”真不是。我做过一个法律文书抽取项目，一开始上了 70B 模型，效果确实好，但推理速度慢、部署成本高，后来换成熟练使用提示词的 7B 模型，配合精心设计的结构化输出格式，准确率只降了不到两个点，成本和速度却提升了几个量级。先小后大，永远是对的。

3.2 本地推理上手指南：Ollama、GGUF 与 vLLM

本地部署最友好的入门工具是 Ollama，它对新手极其宽容，不需要配置 CUDA、不需要手写推理脚本，装完就能用。以 Qwen2.5 7B 为例，命令行操作非常简单：

ollama pull qwen2.5:7b ollama run qwen2.5:7b

两条命令下去，一个可交互的本地大模型就跑起来了。Ollama 底层会自动下载对应格式的模型文件，如果你需要在 Android 应用里集成，其实思路也类似，把 GGUF 格式文件放到移动端推理引擎里加载，模型越小越可行，我这边的经验是 1.5B 到 3B 的量化模型在手机上跑得还算流畅，再往上就得考虑客户端 + 服务端的混合模式了。

等你需要把模型以 API 形式对外提供服务时，可以上 vLLM，它专为高并发推理设计，吞吐量比原生推理脚本高出不少。启动服务同样很简单：

vllm serve Qwen/Qwen2.5-7B-Instruct --tensor-parallel-size 1 --gpu-memory-utilization 0.9

启动后它会默认开一个 OpenAI 兼容的接口，你业务代码几乎不用改，只需要把 baseURL 指向本地地址就行。对于个人项目，Ollama 足够；对于生产环境，vLLM 或者同类框架是更稳的选择。还有一个冷门但好用的工具是 AirLLM，它可以靠 CPU 和内存联动跑超大模型，虽然速度慢，但至少让你在没显卡的机器上也能体验 70B 级别模型，适合做一次性实验。

3.3 微调实操：用 Qwen2.5-7B 做行业领域模型

聊完部署再聊微调。很多人以为微调是个神秘的黑魔法，其实核心就三步：准备数据、跑 LoRA 训练、合并权重。以 Qwen2.5-7B 为底座微调一个行业问答模型为例，第一步是把业务数据整理成统一的 JSON 格式，常规 SFT 格式是这样的：

[ { "instruction": "请根据合同条款，判断甲方是否存在逾期付款责任。", "input": "合同第 3.2 条规定甲方应在验收后 30 日内付清全款……", "output": "存在逾期付款风险。第 3.2 条明确约定了付款期限……" } ]

数据准备阶段的核心是质量而非数量，我见过有人拿几万条粗制滥造的数据训练，效果反而不如一千条高质量问答，因为模型会学到你标注里的噪声。数据准备好之后，推荐直接用 LLaMA-Factory 这类工具，它对新手相当友好，支持 LoRA、QLoRA 多种训练方式。命令行方式大概长这样：

llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --stage sft \ --finetuning_type lora \ --dataset industry_data \ --dataset_dir ./data \ --output_dir ./output \ --num_train_epochs 3

训练 7B 规模的 LoRA，在单张 24GB 显存显卡上是跑得动的，如果显存只有 16GB，用 QLoRA 做 4bit 量化训练也能勉强应付，就是慢一些。训练时重点盯 loss 变化，正常情况下应该稳步下降然后趋于平缓，如果你发现 loss 一直在高位震荡，九成是数据格式有问题或学习率设置过高。训练完成后，LoRA 权重只是一个小文件，还需要合并回底座模型才能正常部署，LLaMA-Factory 也提供了合并导出功能，导出后再用 Ollama 或者 vLLM 上面讲过的方式部署就行，整个链路就闭环了。

3.4 从环境配置到效果展示：完整链路走一遍

很多教程只教单点操作，这里我把一次完整的“环境 + 微调 + 部署 + 展示”链路串一遍，方便你照着做。第一步是准备环境，用 conda 建一个干净的虚拟环境，避免污染系统 Python；然后安装 PyTorch、CUDA 工具包、Transformers，以及你选定的微调框架。需要注意 CUDA 版本和显卡驱动匹配，Linux 服务器上建议先跑nvidia-smi确认驱动支持的最高 CUDA 版本，再去装对应工具链。

第二步是模型与数据准备。模型可以从 Hugging Face 或国内镜像站下载，如果是国内网络环境，配置好镜像后下载很快；数据按照上一节说的 JSON 格式准备，建议划分训练集和验证集，比例九比一左右，验证集用来判断模型是否过拟合。第三步是微调训练，训练完成后先做几次生成测试，确认回答风格符合预期，再合并导出。第四步是部署，用 Ollama 注册模型，然后通过接口测试验证效果，可以用一个简单的 Python 脚本请求本地 API，跑通后再接入业务系统。

最后一步是效果展示和回归测试。建议准备一批行业真实问题，微调前问一遍、微调后再问一遍，对比输出差异，这一步最直观，也是评估微调是否成功的核心依据。整个链路第一次走完可能需要两三天，但跑顺之后你会发现每个环节都很标准化，这也是我现在强推这套流程的原因：它把大模型从“科研玩具”变成了可以重复交付的工程流水线。

4. 学习路线与排坑实录：新手怎么系统性上车

4.1 一条不容易跑偏的学习路线

总有人问大模型学习路线，其实最忌讳的就是一上来啃 transformer 论文和反向传播公式，九成的人会在数学这一步直接劝退。我自己更推荐“应用倒逼学习”的路线：第一阶段，先把市面上主流的对话应用玩熟，体会不同模型的回答风格，顺便学习提示词编写，这个阶段的目标是“会跟模型聊天，知道怎么把需求描述清楚”。第二阶段，学 Python 基础，然后调 API，写一个能调用大模型完成自动摘要或批处理的小脚本，这个阶段能让你理解系统提示词、温度参数这些概念的实际意义。

第三阶段，本地部署一个开源模型，用 Ollama 跑起来，再尝试接上自己的业务数据做个简单的 RAG 问答，这一步会逼着你接触向量数据库、Embedding 这些概念。第四阶段才谈得上微调，用现成框架做一次 LoRA 训练，理解什么是过拟合、什么是数据质量。第五阶段做 Agent，试着让模型调用工具完成任务。这条路线的好处是每步都有看得见的成果，正反馈强，而且每个阶段需要的数学和工程知识都是被实际问题驱动的，学起来不痛苦。

4.2 高频问题排查速查表

实操中我遇到过大量重复问题，整理一个速查表给大家，遇到问题直接对号入座：

这张表不解决所有问题，但可以帮你筛掉八成常见故障。剩下两成比较隐蔽的问题，基本要靠加日志、逐步缩小排查范围来解决，这也是工程人的基本功。

4.3 我踩过的几个坑和心里话

最后分享几个让我印象深刻的教训。第一个是“数据洁癖”极其重要。我早期做微调时不重视数据清洗，训练集里混了大量重复问答和格式错误样本，结果模型学会了“答非所问”和“重复啰嗦”，后面花了两倍时间重做数据才救回来。第二次做数据清洗时，我写了脚本做去重、去空、统一格式，效果立竿见影。第二个是“盲目追求大模型”的心态要不得。我一直提醒自己：你是在解决业务问题，不是在参加模型排行榜竞赛。一个 13B 的模型经过好的提示词和 RAG 调优，很多时候就能满足业务需求，硬上 70B 不但烧钱，还可能因为推理太慢反而影响用户体验。

第三个是环境管理不能偷懒。我以前直接在服务器全局环境里装依赖，装一次坏一次，后来统一用 conda 建独立环境，每个项目一套，再也不互相污染了。还有一次因为乱卸载包，把系统 Python 搞崩了，重装系统浪费了一整天，这顿教训换来现在的严谨习惯，也算值了。

写到这里，这篇长文总算是把模型维度、应用维度和实操链路都过了一遍。如果你看完还是不知道该选哪个模型，我的建议很简单：先拿 DeepSeek 的 API 做业务验证，同时本地部署一个小 Qwen 模型练手，两条腿走路，随着对场景理解的加深，答案会自己浮现出来。后续等我折腾完手头的 RAG 和 Agent 项目，再回来分享更多新体会。希望这篇笔记能帮你少走一点弯路，也期待你的项目跑出好效果。