企业官网建设流程全解析

今年上半年我刷海外开发者社区时，明显感觉到一件事变了：DeepSeek、Qwen、GLM 这些中文团队开源的模型，已经不是“中文圈子的自嗨”了。Hacker News 上每隔几天就有人讨论 R1 的推理过程，GitHub 上大量 Agent 和 AI 编程工具默认支持 Qwen2.5 的 function calling，甚至不少海外团队直接用 vLLM 把 Qwen2.5-72B 跑进了生产环境。

这篇我不打算聊宏观叙事，只想把注意力放在技术本身：这些开源大模型为什么能在全球范围内走红，它们各自适合什么场景，本地部署和工作流集成到底怎么落地，以及我实测中踩过的坑。适合正在做模型选型、准备私有化部署，或者想把开源模型接入 AI 编程、Agent 工作流的开发者参考。

1. 现象拆解：低算力门槛和开放权重如何撬动全球开发者

很多人在讨论“国产模型出圈”时，总喜欢把原因归结为某个榜单分数。但以我的观察，真正让海外开发者愿意停下来认真看的，是另一套东西：权重能不能下载、许可允不允许商用、跑起来要多少卡、接入现有框架是否顺手。

1.1 开源权重与宽松许可：全球开发者的第一道信任门槛

全球开发者社区对模型的态度，和“看新闻”完全不一样。他们要的是能拿在手里的东西：权重文件、推理代码、微调脚本，以及一个可以放心商用的许可证。

DeepSeek 系列和 Qwen 系列在这个环节做得很干脆。权重直接挂在 HuggingFace 和 ModelScope 上，下载不需要审核，跑通只需要几行命令。许可证普遍采用 MIT 或 Apache 2.0 这类宽松协议，意味着个人可以拿来学习，公司可以拿来做成产品，甚至可以基于它做二次微调后闭源商用。

这一点重不重要？非常重要。过去很多模型虽然开源，但协议里写着一堆限制：只能研究、不能商业化、微调后的模型还得继续开源。对于做产品的团队来说，这种限制等于劝退。我见过不少海外开发者，最先问的问题不是“这模型跑分多少”，而是“license 允许我把它接进我的 SaaS 吗”。国产模型在这点上确实抓住了痛点。

1.2 MoE 架构：总参数很大，推理开销却能压下来

第二个让大家眼前一亮的点，是 MoE（Mixture of Experts，混合专家）架构被大规模用到了生产级模型上。

很多人一听“671B 参数”就觉得不可能本地部署，这其实是对 MoE 最常见的一个误解。以 DeepSeek-V3 为例，虽然总参数量确实很大，但它并不是每个 token 都激活全部参数，而是通过一个门控路由网络，从一组专家里只挑选 Top-K 个专家参与计算。你可以把它想象成一家公司：总员工可能有几百人，但每个项目只抽调几个相关的人组成临时小组，而不是让全公司人同时开会。

这种架构的直接好处，是指标上很唬人的参数量，落实到真实推理成本上却低了不少。DeepSeek-V3 总参数 671B，激活参数只有 37B 左右。这意味着老一批买来的 A100 或 H800 集群，不需要疯狂堆卡也能跑得动。对于预算有限的团队，这比“再买几十张卡”的解决方案友好得多。

1.3 长上下文与多语言能力：它不再只是“中文模型”了

过去一提到中文模型，很多海外开发者会默认“中文好，但英文、代码、数学一般”。最近这一轮出圈的模型，训练数据已经大量混合了多语言、代码、数学和逻辑语料。

DeepSeek-R1 在数学和代码类任务上的表现，大家已经看得很清楚。更难得的是它的推理过程是“可见的”，模型会先把思路写出来再给答案。这种可解释性在欧美开发者社区非常受欢迎，因为它让“AI 是不是真的在推理”这件事看得见摸不着，而不仅仅是黑盒给个结果。

Qwen2.5 系列在英文和代码上的表现也很稳，加上原生支持 128K 甚至更长的上下文，做文档分析、代码库阅读、长对话记忆都很实用。我自己的体验是，它已经完全可以当作通用模型用，而不是只能处理中文内容的“偏科生”。

2. 实测视角下的选型地图：每个模型都有它最合适的战场

很多读者会问：这么多模型，到底该用哪个？我的建议从来都是：不要背榜单，而是把任务类型、部署成本、数据隐私三条线拉出来对齐。下面按我的实际使用体验，逐个拆一下最热门的三条线。

2.1 DeepSeek：V3 适合实时任务，R1 适合硬核推理

DeepSeek-V3 是我的默认选择。它的响应速度快，对话流畅度好，在代码生成、文本改写、日常问答这类“越快越好”的场景里非常顺手。我通常把它当作主力 API 或本地推理模型。

DeepSeek-R1 则是另一个物种。它把大量训练资源投入到强化学习上，目标不是“回答得快”，而是“回答得对”。在数学证明、复杂代码调试、多步逻辑推理、需要严格格式要求的任务上，R1 的表现明显更强。但它也会把“思考”这件事做过头：哪怕你问它“1+1等于几”，它也可能给你列出一长串推理过程。

所以我的选择策略很简单：实时对话、批量处理走 V3；离线分析、难题攻坚、Agent 规划走 R1。一个模型打天下不是不行，只是成本和体验上都亏。

2.2 Qwen 系：工具调用、代码生成和多模态，怎么选

Qwen2.5 系列有点像一个“大家族”，它把场景拆得很细：通用对话有 7B/14B/32B/72B 多个尺寸，代码场景有 Qwen2.5-Coder，多模态场景有 Qwen2.5-VL。加上 Apache 2.0 许可，集成到商业项目里的阻力非常小。

我在 Agent 项目里最常用的是 Qwen2.5-72B。它的 function calling 稳定性很出色，模型能比较可靠地生成结构化的 tool_calls 参数，不会频繁漏参数或把 JSON 写坏。在伯克利函数调用榜单 BFCL 上，它也是一直排在前面的模型。另外，如果业务里需要读截图、识别表格、分析图表，Qwen2.5-VL 也可以直接顶上去，不需要再单独接一个视觉模型。

Qwen2.5-Coder 系列则更适合做代码补全和代码解释。特别是 32B 这个尺寸，量化后在单张 40GB 显卡上就能跑，配合 Continue 或 Cline 这类 AI 编程插件，体感不亚于云端大模型。

2.3 GLM 系：中文表达与轻量私有化的补充选择

GLM 系列在国内的开发者社区口碑一直不错，尤其是中文创作、文案润色、知识问答这类对中文语义理解要求高的场景。GLM-4-9B 这种相对轻量的模型，很适合放在个人工作站或者小型服务器上跑，不需要很多卡就能获得还不错的生成效果。

如果你的业务以中文内容为主，又需要在离线环境做私有化，GLM 是一个值得考虑的补充选择。但要注意，轻量模型在复杂推理和代码能力上，和 72B 甚至更大的模型还是有差距，不要因为“轻量”就过度期待。

2.4 快速选型对照表

为了方便决策，我把自己的选型逻辑整理成了表格：

注意：许可协议和上下文长度会随版本迭代变化，接入前一定要以官方仓库为准。

3. 本地部署与工程化落地的完整链路：从一把梭到稳如老狗

“下载一个 Ollama 然后运行”谁都会，但真要上生产环境，问题会一个接一个冒出来。我在这部分走的弯路比较多，总结下来有三条主线：选框架、做量化、调参数。

3.1 推理框架：Ollama、llama.cpp、vLLM 分别适合什么

Ollama 适合个人电脑和原型验证。它把模型下载、运行、暴露 API 这几件事封装得很简单，几乎不需要写代码。但对高并发和精细调度支持较弱，把几十个用户同时怼进来，很容易排队超时。

llama.cpp 则是“极端环境的好朋友”。它用纯 C/C++ 实现，对 CPU 和 GPU 混合作业支持很好，GGUF 量化格式就是从它这里流行起来的。如果你的机器只有少量显存，或者干脆只有 CPU，它可以帮你把模型跑起来。缺点是想做生产级服务，还是有点力不从心。

vLLM 是我在生产环境里最常用的选择。它核心做了两件事：PagedAttention 把 KV Cache 分页管理，continuous batching 让不同请求在同一个批次里交错执行。这两个机制直接提升了吞吐量，也支持多卡张量并行。部署起来相对复杂一些，但换来的稳定性值得。

我的建议是：先用 Ollama 跑通业务逻辑，再用 vLLM 上线生产；不要一上来就在生产环境折腾 llama.cpp，除非你的硬件条件真的受限。

3.2 量化等级与显存估算：别只看模型文件大小

量化是本地部署绕不开的话题。模型权重默认是 FP16 或 BF16 精度，显存占用很大。通过量化把权重压到 INT8、INT4，可以减少显存占用，但也会引入精度损失。

通常我用 GGUF 里的 Q4_K_M 或 Q5_K_M 作为“甜点档位”，在显存和效果之间比较均衡。AWQ 和 GPTQ 量化方案则更适合配合 vLLM 这类框架，在推理吞吐上更有优势。

显存估算有个简单的参考公式：模型需要的大致显存，等于权重文件大小加上 KV Cache 和激活内存。像 Qwen2.5-72B，FP16 权重约 144GB，Q4 量化后大约 40GB 出头，一张 80GB 的卡可以勉强跑，但上下文一长就会爆显存。7B 模型 FP16 约 14GB，Q4 之后 5GB 左右，消费级显卡也能跑。

很多人只看“模型能启动”就以为部署成功了，其实跑几步就 OOM。所以我的习惯是：先按最差情况估算（最长上下文、最大并发），再往上留 20% 余量。

3.3 部署中三个容易翻车的细节

第一，上下文长度没设置。模型声称支持 128K，但如果 vLLM 里max-model-len没调，默认可能只有 4096，长文档一进来就截断。这不是模型的问题，是服务端参数没对齐。

第二，并发设置不当。vLLM 的 continuous batching 不是无限吃请求的，max-num-seqs、KV Cache 池和显存之间有很强的联动关系。并发设太高，显存会瞬间被打满，甚至直接 OOM 崩溃。

第三，精度混用导致输出异常。有些老显卡不支持 BF16 的加速计算，如果你强行用 BF16 加载模型，可能得到一堆乱码或者报错。最稳妥的办法是部署完先做一个冒烟测试：跑一道简单的数学题、一段中文翻译和一个 JSON 输出任务，确认三项都正常再接入业务。

3.4 用 OpenAI 兼容 API 抹平迁移成本

现在大多数国产开源模型的推理服务，都提供了 OpenAI 兼容的/v1/chat/completions接口。这意味着你不需要为每一个模型写一套专用 SDK，只要改base_url和api_key就能切模型。

我本地部署时会先用 vLLM 或 Ollama 起一个兼容服务，然后在 Python 代码里这样调用：

from openai import OpenAI client = OpenAI( base_url="http://127.0.0.1:8000/v1", api_key="EMPTY", ) resp = client.chat.completions.create( model="qwen2.5-72b-instruct", messages=[ {"role": "system", "content": "你是一个严谨的测试助手。"}, {"role": "user", "content": "写一段 Python 代码，统计一个目录下所有 CSV 文件的总行数。"}, ], temperature=0.2, max_tokens=2048, ) print(resp.choices[0].message.content)

如果之前接的是 OpenAI 或 Claude 的接口，迁移过来的成本很低。唯一的坑是base_url后面一定要带/v1，否则路由对不上。

4. 接入工作流：AI 编程、Agent 与多模型协作

部署完模型只是第一步，真正有价值的是把它嵌进日常工作流。我今年在 AI 编程助手、Agent 工具调用、多模型协作这三块投入最多，下面把实操经验整理出来。

4.1 接入 AI 编程助手：补全、解释和重构要分开选模型

AI 编程工具里，我最常用的是 Continue 和 Cline。它们都支持自定义模型配置，可以填本地 API 或者云端 API。

跑下来最大的体感是：补全任务要的是“低延迟”，解释任务要的是“理解力”，重构任务要的是“推理深度”。这三个需求用一个模型不可能同时做好。

我的配置方案是：代码补全用 Qwen2.5-Coder-7B 或 14B 这类小模型，它响应快，不打断思路；代码解释用 Qwen2.5-Coder-32B，既能读懂上下文，又能给出相对准确的说明；涉及架构调整、大段重构、跨文件改动时，切到 DeepSeek-R1，让它先把问题拆解清楚再动手。

很多人忽略了一点：模型越大会让补全速度变慢。你写一行代码，模型思考两秒，这个体验是很痛苦的。所以别一味追求大模型，先看场景。

4.2 Function Calling 的正确姿势：模型不执行函数，只产出参数

Agent 的核心能力是工具调用，但很多新手会误解：以为模型本身会去执行函数。其实不是。模型的职责只是根据对话内容，生成一个结构化的函数调用请求，真正的执行动作由你的调度代码负责。

以查询天气为例，定义工具时要给出清晰的 JSON Schema：

tools = [ { "type": "function", "function": { "name": "get_weather", "description": "查询指定城市的实时天气", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名"} }, "required": ["city"] } } } ]

请求发送后，如果模型决定调用工具，返回的message.tool_calls里会包含arguments字段。你解析出城市名，去真实的天气 API 拿到结果，再以 tool 消息回传给模型，模型才能据此生成最终回复。

这里最容易踩的坑是：模型生成 function calling 时偶尔会漏参数，或者把参数类型写错。Qwen 系列稳定一些，用了很久基本很少出错；但用小模型时一定要做兜底：解析失败就默认把原始文本交给模型重新处理，不要直接抛异常。

4.3 多模型协作：让每个模型做它最擅长的事

“多 AI 协作”是我最近特别认可的一种架构。它不是说把多个模型同时跑起来然后互相吵架，而是做一个路由层，让请求根据意图自动分发给最合适的模型。

我的实践方案是：入口先用一个 7B/14B 的小模型做意图识别，判断任务属于“闲聊”“代码”“数学推理”“信息抽取”还是“多模态识别”；然后把请求路由给对应的大模型或专用模型。比如数学题给 R1，代码题给 Qwen2.5-Coder，截图理解给 Qwen2.5-VL。

这个方案带来的收益很直接：全局能扛住更高的并发，因为大部分轻量请求被小模型消化了；重任务又有大模型兜底，质量不会塌。成本和延迟也得到控制，不会出现“张三问了句你好，也要跑一圈 671B 大模型”的浪费。

4.4 一套更贴合国产模型的提示词写法

如果你从 GPT 或 Claude 迁移过来，可能会觉得国产模型“反应不太一样”。很多时候不是模型差，而是提示词风格没切换过来。

我经过多次测试，比较稳的写法是这样：

• System prompt 里直接用中文写约束，不要中英混杂。比如“你是一个代码助手，输出代码时不要解释，直接给完整代码块”。
• 如果有格式要求，一定要给一个期望输出的样例。纯文字描述“请返回 JSON”不如直接贴一段 JSON 模板。
• DeepSeek-R1 这类推理模型，适合让它“先列出分析步骤，再给出最终结论”；但 DeepSeek-V3 这种通用模型，建议写“直接回答，不要输出多余分析”，不然它会学着 R1 开始废话。
• 小模型的提示词要短而明确，别给太多背景故事；大模型反而适合给足上下文，发挥它的长文本理解优势。

5. 技术内核：为什么训练方法相似，体验差异却很大

在模型选型过程中，很多人会有个困惑：都是基于 Transformer，都在做预测下一个 token，为什么有的模型复杂推理很强，有的模型只会一本正经地编？这里面藏着几个关键差异。

5.1 MoE 的核心是路由，不是“堆专家”

MoE 并不是近两年的新概念。2017 年就有团队提出稀疏专家模型，后来 Switch Transformer 也验证了这条路。真正的难点在于：怎么让几百个专家网络被充分利用。

如果路由不稳定，训练到最后往往会发现只有少数几个专家被反复选择，其他专家变成摆设。DeepSeek-V3 的一大贡献，是把负载均衡做到了更细的粒度，让不同领域的数据能被分配到更合适的专家。这就是为什么同样是大模型，它在代码、数学、中文这几个领域的能力会更均衡。

对普通使用者来说，不需要自己写路由代码，但你至少应该明白：你现在用的模型不是“一个大脑”，更像“一批专家小组”。它们的组合方式，直接决定了最终生成质量。

5.2 强化学习带来的“会思考”和“过度思考”

R1 系列带来的最大冲击，不是某一个分数，而是让大家意识到：“让模型学会思考”这件事，可以通过强化学习来实现。

传统的语言模型训练目标很简单：最大化下一个 token 的预测概率。但这种训练方式很难让模型做到多步推理。DeepSeek-R1 引入了大规模强化学习，用可验证奖励来引导模型自主生成思维链。模型在训练中逐渐学会“尝试—错误—回溯”的推理过程，而不是只凭语感作答。

但这个技术的副作用也很明显。模型会把很多简单问题也当成挑战题，输出一长串思路。所以在实际产品里，我通常会给 R1 设置更短的max_tokens，或者干脆只在离线批量分析里使用，避免交互场景下响应延迟太高。

5.3 多模态与 CLIP 式对齐思路

如果你研究过开源的视觉语言模型，应该会反复看到一个名字：CLIP。它的核心思路，是把图片和文字映射到同一个向量空间，然后通过对比学习让模型知道“这张图对应的文字描述”和“这张图不对应的文字描述”之间的区别。

很多国产多模态模型，比如 Qwen2.5-VL，在做视觉编码和文本对齐时，底层思路和 CLIP 是一脉相承的。它们不是简单地把图像塞进语言模型，而是让模型先学会“看图说话”的表征，再做指令微调，让模型能根据对话要求去理解截图、表格、公式。

想深入理解现代多模态模型，我最推荐的还是去读一遍 CLIP 原论文。虽然那篇文章已经发表了好几年，但理解它之后，再看 Qwen2.5-VL 这类模型的技术报告就不会那么吃力了。

5.4 晒分不如自测：建立自己的业务评测集

我见过不少团队，选模型时只看公开榜单，结果上线后问题频出。公开榜单的数据分布和你业务的真实数据分布大概率不一样，靠别人晒分数做决策，风险很高。

我的做法是：从真实业务里抽 20 到 30 条有代表性的 prompt，组成一个最小评测集。里面覆盖几类：格式遵循（必须输出 JSON）、中文歧义理解、数学计算、代码生成、敏感输入处理、拒绝回答边界。然后用同一个测试集去跑候选模型，人工判断通过率。

这个评测集不需要做得多复杂，关键是能真实反映业务需求。哪怕只有 20 条，也比随便看一张跑分表可靠得多。

这一年多下来，我自己最大的感受是：“哪个模型最强”是个伪命题，“哪个模型在你的任务里最稳、最便宜、最容易部署”才是真问题。如果你也打算从云端 API 迁到私有化部署，或者正在给团队搭一套多模型路由，我的建议是先别急着上最大模型，用一个 14B 或 32B 模型把业务闭环跑通，再逐步替换和加入 R1 这类深度推理模型。国产开源模型的更新速度很快，我还在持续关注它们在长上下文和工具调用上的新进展。等我把下一轮 Agent 落地和微调的实操经验跑完，应该会再来写一篇记录。