企业官网建设流程全解析

最近周围好几个团队都在折腾大模型落地，聊来聊去绕不开的永远是两个名字：Qwen 和 DeepSeek。前者背靠着成熟的电商与云计算生态，版本迭代快得像下饺子；后者以极致的性价比和数学代码能力惊艳全场。可很多人选型时是懵的——都叫开源大模型，到底哪个适合当自己业务的“智能大脑”？选基座、做微调、搞部署、接Agent，整套大模型技术栈跑下来，坑位一个不比前端少。

这篇文章不吹参数、不列榜单，就结合我做过的几个模拟项目X，把Qwen与DeepSeek从选型、微调、部署到应用接入的完整链路拆开讲。我会把两者放在同一套技术栈里对比，告诉你什么时候该用Qwen，什么时候该换DeepSeek，以及最重要的一件事：模型本身只是胚胎，怎么喂数据、怎么调对齐、怎么接工具，才决定它是专家大脑还是人工智障。

1. 为什么开源基座是“智能大脑”的最优起点

1.1 大模型技术栈的两条路：闭源API与开源基座的取舍

先别急着扎进Qwen和DeepSeek的细节，得先想清楚一个问题：你需要的到底是一个能调用的API，还是一个能握在手里的模型？

很多团队第一反应是接闭源API，理由很直接：不用管显卡、不用懂微调，代码写两行就能用。但真做了几个项目就会碰到三堵墙。第一堵是数据墙，业务数据往外传这件事，光合规评审就要走好几轮，有些敏感业务根本过不了。第二堵是成本墙，API按token计费，一旦业务量上来，对话密集型的应用一个月账单能吓死人。第三堵是定制墙，闭源模型不支持真正改行为，你想要它严格输出JSON格式、永久记住某套内部规则，靠Prompt拧巴半天还是不稳定。

开源基座解决的就是这三堵墙。模型权重在你手里，数据链路完整闭环，推理成本能摊到硬件折旧上，更关键的是可以随时微调，把模型的脾气拧成你想要的样子。我做过的某个客服场景，基座模型不微调前，回答总是带一股“AI味”，打断用户说话、长篇大论讲道理。微调三百条高质量对话后，风格立刻收敛，这个能力是闭源API给不了的。

1.2 选Qwen还是DeepSeek：先看“脑结构”再谈智商

那开源基座选谁？我自己的判断标准不看跑分，看三件事：生态成熟度、训练路线适配度、部署性价比。

Qwen系列走的是“大而全”路线，从0.5B到72B全覆盖，还有专用的数学模型和视觉模型。它背后的开发团队背靠大规模业务场景，模型天然带很强的指令跟随能力和中文理解能力，而且衍生生态特别繁荣——各种量化版本、Agent框架适配、本地推理教程遍地都是，碰到问题搜一下基本都有答案。

DeepSeek系列走的是“技术突围”路线，靠MoE架构把推理成本打下来，数学、代码方面的能力在开源模型里属于第一梯队。它的最新版本在长上下文和复杂推理上非常能打，而且API价格低得离谱，很多团队拿它做大规模数据分析、代码补全类应用的基座。

说白了，Qwen更像一个“通识学霸”，各科稳定，适合做通用助手、客服、知识库问答；DeepSeek更像“竞赛选手”，数理逻辑强，适合做代码生成、数学推理、复杂Agent调度。选谁，取决于你的业务更偏文科还是理科。

2. Qwen与DeepSeek的核心差异：架构、上下文与推理风格

2.1 Dense与MoE：两种“大脑”结构如何影响部署成本

这里得讲透一个大部分人都忽略的点：模型的“总参数量”和“激活参数量”是两回事。

Qwen的主力版本走的是Dense架构，每次推理，所有参数全量参与计算。拿Qwen-14B举例，总参数14B，激活参数也是14B，算力消耗是实打实的。好处是行为稳定、训练简单、量化后效果损失小；坏处是贵，显存和算力需求都是线性的。

DeepSeek的多个版本走的是MoE（混合专家）架构，总参数看着吓人，但实际上每一次推理只激活其中一部分专家。比如DeepSeek-V2有236B总参数，但激活参数只有21B。这意味着什么？它的推理成本接近21B的Dense模型，但知识容量却是236B级别的。用大白话说，MoE就是雇了一百个专家，每次根据问题只喊其中最懂行的五个人来干活，脑容量大、开销小。

但MoE也不是没代价。它对量化更敏感，AWQ、GPTQ这类的量化方案在不同专家上有时候会出现效果不均衡；显存占用虽然比同等总参数的Dense模型低，但比激活参数等量的Dense模型要高，因为专家权重得都塞进显存里。部署DeepSeek之前，我建议你好好算一笔账：

2.2 上下文窗口与长文本处理：不是越长越好

另一个容易踩坑的是上下文长度。Qwen系列普遍支持较长的上下文，部分版本号称能处理百万级token的输入。DeepSeek同样把长上下文当卖点，尤其是最新版本，文档理解能力很强。

但“支持张长”和“用得好长上下文”完全是两码事。几年前我做某合同审查Demo的时候，硬塞了50万token的合同进上下文，结果模型是没报错，但关键条款的召回率一塌糊涂。后来才明白，大多数模型在超长上下文下都存在“lost in the middle”的问题——开头和结尾的内容记得清楚，中间部分注意力涣散。

实操里我有个笨办法：把长文档切成多个语义块，先用小模型或者关键词匹配定位相关内容，再把定位到的段落拼回给大模型做精读。与其迷信极限上下文，不如设计好的检索链路。这里Qwen和DeepSeek的实际差别不大，都别把长上下文当无限缓存用。

2.3 中文能力与代码数学能力：分场景实测

我在多个业务场景里对两兄弟做过对照。纯中文的客服、文案创作场景，Qwen的语感明显更自然，俚语、网络用语、语气词的拿捏都很到位，指令跟随也很听话。DeepSeek在中文场景不是不行，但它的“气质”更理性，适合写结构化内容，让它写带货文案，不如Qwen有网感。

反过来，写Python脚本、调SQL、解微积分、做逻辑推理，DeepSeek优势就出来了。模型给出的解题步骤更清晰，代码Bug率更低，面对复杂多跳推理问题时，路线规划明显更稳健。说句公道话，Qwen的代码能力也在快速追赶，但现阶段如果要搭一个自动写代码的Agent，我会首选DeepSeek。

3. 从模型到智能大脑：训练与对齐的完整链路

3.1 先搞清楚你的起点：基座模型还是对话模型

很多人下载模型时不看分支，直接拖了基座模型（Base Model）下来微调，然后抱怨“模型怎么只会续写不会聊天”。这是新手最常见的坑。

同一代Qwen和DeepSeek都分成两条线：Base版是纯预训练产物，参数里全是语料统计规律，它的使命是“预测下一个token”，不会陪你聊天；Chat/Instruct版经过了SFT和偏好对齐，学会了对话格式和人类偏好。你自己做业务，绝大多数情况都应该从Chat版继续微调，除非你要做的是底层的代码补全、词法分析这类不需要对话形态的场景。

3.2 SFT注入业务知识：数据配比比数量重要

微调的第一步是有监督微调（SFT），目的是把“通用大模型”变成“懂业务的模型”。这里面最大的误区是拼命攒数据，以为量变引起质变。真实经验是，一万条低质量业务流水账，不如三百条精挑细选的“标准答案”有用。

数据配比是我反复调出来的经验。三份数据得有层次：百分之六十是“业务核心问答”，直接教模型你的业务口径；百分之二十是“通用对话保底”，防止模型微调后忘了怎么说人话；最后百分之二十是“难点与边界案例”，专门处理过去容易答错、答漏的场景。配比失调很容易出现灾难性遗忘——模型学会了业务但退回了“早期AI腔”，那就白搞了。

SFT数据还有个要点：系统提示词和用户问题的格式必须统一。我见过某个团队微调出的模型，对话时好时坏，排查到最后发现是训练数据里有一半带了内置的JSON字段，一半不带，把模型都搞分裂了。你的训练数据长什么样，模型上线后就长什么样，这点怎么强调都不过分。

3.3 偏好对齐：DPO还是RLHF

SFT让模型“会说话”，但离“会说人话”还差一步——对齐人类偏好。过去主流是RLHF，要训练一个奖励模型，然后强化学习调优，流程长、成本高、超参数敏感，小团队跑起来很痛苦。现在开源社区更流行DPO（Direct Preference Optimization），不需要单独训练奖励模型，直接用“好答案/坏答案”的对比数据就能微调。

做DPO时注意两点。一是对比数据不能假，好答案和坏答案之间必须有真实质量差异，否则模型学不到东西；二是DPO强度别拉太满，我习惯控制在0.1到0.3之间，调太猛模型会变得过于死板，一点发散性都没有。

DeepSeek和Qwen对DPO的支持都不错，尤其是通过各家生态配套的训练脚本，直接指定模型路径和数据路径就能跑，不用自己造轮子。

3.4 LoRA微调的实际参数参考

做全参微调需要的高显存不是一般团队扛得住的，好在我们有LoRA。它的思路是冻结原模型权重，只训练一小部分低秩矩阵，参数训练量通常只有原模型的百分之一。

拿某次Qwen-14B的LoRA微调举例，我的配置长这样：

# 基于某分布式训练框架的LoRA微调命令示例 lora_rank=64 lora_alpha=128 lora_dropout=0.05 target_modules="c_attn,c_proj" learning_rate=1e-4 batch_size=4 gradient_accumulation_steps=8

rank值不用纠结，64是常规起点，任务越复杂可以适当调高；学习率比全参微调低一个数量级，1e-4附近比较稳；梯度累积是省显存的关键，八张卡跑不动大batch就靠它凑够等效batch size。一句话总结：LoRA的本质是让模型在原有能力上“偏科”，它不是万能药，但成本低、试错快，特别适合业务探索期。

4. 部署与推理：显存、量化与性能调优

4.1 模型选多大：算好这比显存账

选模型规模之前先把部署预算算清楚。推理时模型权重需要常驻显存，KV Cache还要额外占一部分。

拿单卡部署举例：Qwen-7B的BF16权重约14GB，推理时再算上KV Cache和中间激活，正规一点的部署至少要预留20GB以上显存，一张24GB的消费级显卡勉强能跑，但并发一高就容易OOM。Qwen-14B的FP16权重约28GB，单卡基本无望。DeepSeek若干MoE版本因为激活参数少，等效成本约20B级Dense模型，但总显存占用反而高，通常建议用双卡或以上。

我的建议很简单：并发要求不高、追求单机跑通，就选7B级别；要正经上生产、扛住多人访问，直接上多卡集群部署14B乃至更大的模型，别在单卡上硬撑。

4.2 推理框架与量化方案选型

业内主流的推理方案无非这三类：其一，功能最全的框架，自带OpenAI兼容API和高性能推理引擎，适合做服务化部署；其二，某推理运行时，偏轻量，适合单机快速起服务；其三，一些支持多后端的中转层，胜在能灵活切换硬件。最无脑的选择是用第一类配同品牌的模型，生态最成熟。

量化是省显存的利器，GPTQ适合离线量化后加载推理，AWQ在同等压缩率下恢复效果普遍更好，GGUF则是消费级CPU/GPU混合部署的常用量。但注意，量化是有损的——尤其是MoE架构的DeepSeek，AWQ后偶尔会出现某个“专家”退化导致局部问题，上线前必须在自测集上认真扫一遍。

4.3 从压测到线上：调优的几个关键参数

线上压测的时候，有几个参数特别影响体验：

• max-model-len：控制最大上下文长度，不是越长越好，长上下文会让KV Cache暴涨，压测前先按业务真实长度设置。
• gpu-memory-utilization：控制显存利用率，留一点余量给碎片化开销，默认0.9最好调到0.85以下。
• max-num-seqs：并发序列数，调太大会导致单条token生成变慢，调小又浪费吞吐，压测时从32开始试探。
• enforce-eager：关闭图模式可以降低首token延迟（但会损失吞吐），交互型应用可以开，高并发场景建议关掉。

我习惯压测时盯两个指标：首token延迟（TTFT）和吞吐量（tokens/s）。前者影响“用户感觉快不快”，后者决定“GPU效率高不高”。不同的场景侧重不同，智能问答更看重前者，批处理任务更看重后者。

5. 搭建智能应用：RAG与Agent如何接上模型大脑

5.1 别把模型当记忆库：RAG才是真正的长期记忆

微调完模型，很多人会误以为它已经“什么都知道”了。真相是：微调解决的是“表达方式”和“业务口径”问题，解决不了“知识新鲜度”问题。你公司每周更新的产品文档、实时变动的价格表，不可能靠微调解决。

我习惯把这套逻辑讲给团队听：模型是大脑的算力，RAG是大脑的外置记忆。RAG的流程不复杂：文档切块、向量化、存库、检索、携带上下文送进模型。但细节全在工程里——分块粒度、TopK选择、向量模型选型、重排序策略，每个环节都能让回答质量浮动的厉害。

5.2 Function Calling与Agent循环：让模型会调用工具

光会检索还不算“智能大脑”，真正让它干活的，是Function Calling与Agent循环。简单说，就是让模型输出结构化的工具调用意图，系统代为执行，再把结果反馈给模型，不断迭代直到完成用户任务。

Qwen和DeepSeek的近期版本都原生支持功能调用，官方文档都给了标准格式。实测下来，DeepSeek在复杂工具链的编排上更稳，多步骤推理不容易迷路；Qwen则胜在指令理解的“听话”程度，给它限定的工具列表，它不怎么自作主张。

跑一个简单Agent循环，核心就是维护好“系统提示词+工具定义+历史消息+工具结果”的上下文。别把工具定义塞一大堆，模型会看不过来，只给当前阶段需要的三五个就够了。

5.3 一个能直接落地的架构参考

综合几个项目经验，我常用的架构是这样组织的：

• 语言层：根据业务形态，客服问答型选Qwen，代码分析型选DeepSeek，多模态需求选Qwen-VL。
• 记忆层：长期知识走向量库，短期对话走上下文窗口，高频业务数据走API实时查询，三层解耦。
• 工具层：部署统一的Function Calling中间件，把模型输出的结构化指令翻译成真实的内部服务调用。
• 编排层：一个Agent调度器负责决定“这轮该检索、该调工具还是该直接回答”。
• 接入层：通过统一的API网关暴露标准接口，内部随便怎么换模型，对外无感知。

这套结构的好处是，模型可以被替换、升级，而业务代码不需要大改。我从Qwen切到DeepSeek做过一次迁移，只改了模型名和Prompt模板，其他一切照跑。这才是“智能大脑”该有的样子——大脑可以换，身体不动。

6. 真实项目里的经验与坑

6.1 微调救不了幻觉，RAG也救不了

先说个扎心的事实：Qwen和DeepSeek再强，都会有幻觉。微调之后幻觉并不会消失，它只是让幻觉更“隐蔽”——模型会用振振有词的语气编造一个符合业务口径的假数据。

我做过一个医疗问答类的项目，模型在回答某药品禁忌时信誓旦旦编了一个不存在的交互反应。微调解决不了，因为问题不是“表达不够好”，而是“知识没有可靠来源”。RAG一定程度上能缓解，但检索不到准确资料时，模型还是会自由发挥。

最可靠的兜底方案是“拒绝的艺术”：在Prompt里明确要求“当没有检索到相关信息时，直接回答：资料库暂未覆盖此问题”。同时加上输出约束，强制模型引用检索来源，让人工能追溯到原始出处。面对幻觉，防御永远比修复现实。

6.2 评估体系比模型本身更值得投入

很多团队评测模型喜欢拿几个Case问一下，感觉差不多就上。这种“拍脑袋评估”害死人。表面上两个模型聊起来都挺流畅，但关键的格式正确率、拒答率、引用准确率，只有跑批量评测才能暴露。

我花了两周给某问答项目搭了套离线评测集，三百条标注数据，覆盖快问快答、长文档理解、工具调用、边界拒答四类任务。每次换模型、换Prompt、换检索逻辑，都先跑一遍这套评测，用分数说话。这东西越用越香，一次投入，后续所有改动都有了照妖镜。

6.3 Demo到生产之间，还隔着运维这堵墙

最后提醒一个特别容易被忽视的点：Demo写起来很快，生产化才是硬仗。上线前至少要在卡点三件事上留出时间——第一是推理服务的稳定性，显存泄漏在高并发的推理服务里时有发生，必须有监控和自动重启；第二是并发限流的合理性，不做压测直接上线，流量一来模型服务十有八九会挂；第三是模型版本的灰度管理，新微调版本上线前要留一条快速回退的老版本通道，比例灰度放量，出了问题及时切流。

模型不是跑通一次就完事，它是需要持续喂养和运维的系统。我见过太多团队倒在“模型效果很好”和“生产服务可用”之间那道鸿沟上，希望你不要重蹈覆辙。

最后说点个人的体会。Qwen和DeepSeek的关系从来不是谁取代谁，聪明的做法是把它们当成工具包里的不同扳手。通用对话、内容生成我优先选Qwen，因为它中文语感好、生态顺滑；代码辅助、推理分析、复杂Agent流程我换DeepSeek，因为它逻辑更硬、性价比更高。往更深一层看，选基座只是起点，真正把模型喂成“智能大脑”的，是你对业务数据的理解、对齐调优的经验，以及一整套评测和运维体系的打磨。模型每年都会迭代，但希望你沉淀下来的这套方法论，能跟着业务一直往前走。