1. 从 Qwen2.5 到 Qwen3.5一条模型演进路线背后的取舍逻辑第一次把 Qwen2.5、Qwen3、Qwen3.5 三个版本的模型权重同时拉到一个目录里做对比评测的时候我盯着显存占用表看了很久。同样一个 7B 级别的稠密模型三代之间的推理显存差异不到 1GB但实际任务表现却拉开了肉眼可见的差距。这件事本身就说明了一个问题模型代际的进化早就不靠单纯堆参数了真正的变化藏在架构、训练策略和推理范式的底层。Qwen 系列是通义千问的模型家族从 Qwen2.5 开始这个系列在开源社区里被大量用于本地部署、LoRA 微调、代码生成、CTF 逆向辅助等场景。Qwen3 引入了更激进的 MoEMixture of Experts混合专家架构路线把总参数量和激活参数量这两个概念彻底分开。到了 Qwen3.5整个系列的定位进一步向多尺寸覆盖 高效推理 长上下文收敛。如果你正在纠结该用哪一代做本地部署、该拿哪一代做 LoRA 微调、或者单纯想知道 MoE 到底值不值得上那这篇内容就是给你写的。我下面会按整体设计思路 → 核心架构细节 → 实操部署与微调 → 常见问题排查这条线把三代模型掰开揉碎讲清楚。所有参数、显存估算、部署命令都是我实际跑过的能直接抄作业。2. 三代模型整体设计思路拆解2.1 为什么 Qwen2.5 是稳的代名词Qwen2.5 这一代的核心设计哲学可以用一个字概括稳。它采用的是标准的稠密DenseTransformer 架构每个 token 推理时都会激活全部参数。这意味着什么意味着它的行为极其可预测——你给它多少显存它就吃多少显存你给它多长的上下文它的推理延迟就线性增长多少。没有惊喜也没有惊吓。从工程角度看Qwen2.5 的尺寸覆盖非常完整从 0.5B、1.5B、3B、7B、14B、32B 一直到 72B几乎每个显存档位都能找到对应的模型。这一点对本地部署极其友好。我见过太多人拿着 8GB 显存的笔记本想跑 14B 模型最后只能上量化。Qwen2.5 的 7B 版本在 4-bit 量化下大约占 4.5GB 显存加上 KV Cache 和上下文开销8GB 卡能比较舒服地跑起来。Qwen2.5 的另一个特点是它的训练数据质量和指令跟随能力相比前代有质的提升。尤其是 Qwen2.5-Coder 和 Qwen2.5-Math 这两个专项版本在代码补全和数学推理上的表现让很多人在本地开发环境里直接把它当成了 Copilot 的替代品。CTF 场景下用 Qwen2.5 做逆向辅助、脚本生成也是那段时间社区里很常见的玩法。但 Qwen2.5 的天花板也很明显稠密架构下想要更强的能力就必须上更大的参数而更大的参数直接意味着更高的推理成本和更慢的速度。这个矛盾在 Qwen3 那里被正面解决了。2.2 Qwen3 的 MoE 路线把大和快拆开Qwen3 最核心的变化就是大规模引入 MoE 架构。MoE 的思路其实不复杂把一个大的前馈网络拆成很多个专家子网络每个 token 进来的时候通过一个路由网络Router只激活其中少数几个专家。这样一来模型的总参数量可以做得很大比如 235B但每个 token 实际参与计算的参数量可能只有 22B 左右。这个设计的直接好处是你用 22B 级别的推理成本获得了接近更大稠密模型的能力。对于本地部署来说这意味着你可以在有限的显存里跑一个名义上很大的模型。当然代价是显存里仍然要装下所有专家的权重所以 MoE 省的是计算量不是显存占用。这一点很多人一开始会搞混我后面会专门讲。Qwen3 系列里比较有代表性的 MoE 型号包括 Qwen3-30B-A3B总参数 30B激活 3B和 Qwen3-235B-A22B总参数 235B激活 22B。前者在消费级显卡上就能跑后者基本要上多卡或者大显存工作站。A3B 这个型号我印象特别深因为它在 24GB 显存的卡上跑起来非常流畅推理速度接近一个 3B 稠密模型但实际能力远超 3B。Qwen3 还引入了思考模式和非思考模式的切换。简单说就是模型可以选择在回答前先输出一段推理过程类似思维链也可以直接给答案。这个设计在复杂推理任务上很有用但在简单问答上就是浪费 token。实际用的时候我一般会在 API 调用里显式控制这个开关避免模型在简单问题上想太多。2.3 Qwen3.5 的收敛方向多尺寸、长上下文、高效推理到了 Qwen3.5整个系列的进化方向变得更加务实。它没有再去追求最大参数这个指标而是把重点放在了三个方向尺寸覆盖更细、上下文更长、推理效率更高。尺寸上Qwen3.5 继续保留了 MoE 和稠密两条线但在小尺寸段做了更密集的布局。这对边缘设备部署特别重要。比如 Jetson Orin Nano 这种 8GB 显存的边缘设备你不可能跑 30B 的 MoE但可以跑一个 1.5B 到 3B 的稠密版本或者一个激活参数极小的 MoE 变体。上下文长度上Qwen3.5 把长上下文支持做得更扎实。Qwen2.5 时代虽然也标称支持 128K但实际在超过 32K 之后检索准确率会明显下降。Qwen3.5 在长上下文的位置编码和注意力机制上做了优化实际测试中 64K 到 128K 区间的大海捞针准确率比前代稳定不少。推理效率上Qwen3.5 对 KV Cache 的管理做了改进配合 vLLM、SGLang 这类推理框架吞吐量比 Qwen3 同尺寸型号有明显提升。这一点在做本地 API 服务的时候体感很强——同样的并发请求数Qwen3.5 的首 token 延迟和总吞吐都更好看。2.4 三代演进的核心逻辑对比把三代放在一起看演进逻辑其实很清晰维度Qwen2.5Qwen3Qwen3.5主力架构稠密 Transformer稠密 MoE 双线稠密 MoE 双线MoE 更成熟尺寸覆盖0.5B ~ 72B0.6B ~ 235B更细粒度边缘段更密上下文标称 128K实际 32K 稳128K长文检索改善128K长文检索更稳推理范式单模式思考/非思考可切换切换更自然开销更低典型场景本地部署、LoRA 微调、代码MoE 尝鲜、复杂推理生产级本地服务、边缘部署显存友好度高稠密可预测中MoE 显存吃总参数中高KV Cache 优化这张表不是让你背的而是让你在选型的时候有个参照。比如你只有一张 12GB 的卡想做代码补全Qwen2.5-Coder-7B 量化版是最稳的选择如果你想体验 MoE 的能力又不想上多卡Qwen3-30B-A3B 是甜点如果你要做生产级的本地 API 服务Qwen3.5 的中等尺寸 MoE 配合 vLLM 是当前比较优的解。3. 核心架构细节与关键技术点解析3.1 MoE 到底怎么工作路由、专家与负载均衡MoE 的核心机制值得单独讲清楚因为很多人对它的理解停留在只激活一部分参数这个层面但实际工程里有很多细节会影响你的部署决策。一个标准的 MoE 层包含两部分一组专家网络Experts和一个路由网络Router。每个 token 的隐藏状态进来之后Router 会计算它应该分配给哪些专家通常是一个 softmax 分布然后取 top-k 个专家。比如 top-2 就是每个 token 选两个专家参与计算最后把这两个专家的输出按路由权重加权求和。这里有个关键参数叫专家容量Expert Capacity。因为一个 batch 里的 token 是并行处理的如果所有 token 都路由到同一个专家那个专家就会过载。所以工程上会设置一个容量上限超过的 token 会被丢弃或者走残差连接。这个机制叫负载均衡Load Balancing训练时会加一个辅助损失来鼓励 token 均匀分配到各个专家。实际部署的时候负载均衡做得好不好直接影响推理效率。如果路由严重倾斜某些专家被频繁激活那 MoE 省计算量的优势就打折扣了。Qwen3 和 Qwen3.5 在这方面做了不少优化路由的稳定性比早期 MoE 模型好很多。注意MoE 省的是计算量FLOPs不是显存。所有专家的权重都必须加载到显存里所以一个总参数 30B 的 MoE 模型显存占用和 30B 稠密模型是接近的只是推理速度接近 3B 稠密模型。3.2 稠密模型为什么在边缘设备上仍然不可替代虽然 MoE 很火但在边缘设备上稠密模型仍然是主力。原因很简单边缘设备的瓶颈往往不是计算量而是显存和功耗。MoE 虽然计算量小但显存占用大而且路由网络本身也有开销。在 Jetson Orin Nano 这种设备上你跑一个 3B 稠密模型显存占用可控推理延迟稳定功耗也低。跑 MoE 反而可能因为显存不够而频繁 swap得不偿失。Qwen2.5 和 Qwen3.5 都有小尺寸稠密版本这些版本在边缘部署场景下非常实用。比如做本地语音助手、离线文档问答、嵌入式代码补全小稠密模型配合量化是当前最务实的方案。3.3 思考模式与非思考模式的实际差异Qwen3 开始引入的思考模式切换本质上是在推理时控制模型是否生成中间推理步骤。开启思考模式时模型会先输出一段类似让我想想……的推理链然后再给最终答案。这个机制在数学题、逻辑推理、复杂代码生成上确实能提升准确率但代价是输出 token 数可能翻好几倍。我在实际使用中的经验是对于简单的信息抽取、格式转换、短问答一定要关掉思考模式否则响应时间会明显变长而且有时候模型会过度思考导致答案反而跑偏。对于需要多步推理的任务比如解一道算法题、分析一段复杂代码的逻辑开启思考模式收益明显。Qwen3.5 在这个切换上做得更自然模型对什么时候该想、什么时候不该想的判断更准但显式控制仍然是最稳的做法。3.4 量化对三代模型的影响差异量化是本地部署绕不开的话题。Qwen2.5 时代GGUF 格式的 4-bit 量化Q4_K_M是社区标配7B 模型量化后大约 4.5GB质量损失很小。Qwen3 的 MoE 模型量化起来就复杂一些因为专家层的量化误差会累积而且不同专家的敏感度不一样。实际测试下来Qwen3 的 MoE 模型用 Q4_K_M 量化后能力下降比同尺寸稠密模型更明显一些建议 MoE 模型尽量用 Q5 或 Q6 量化。Qwen3.5 在训练时对量化友好度做了优化Q4 量化后的表现比 Qwen3 同级别更好。但如果你显存允许我仍然建议 MoE 模型上 Q5 以上稠密模型 Q4 就够用。4. 本地部署实操从环境准备到跑通第一个请求4.1 硬件选型与显存估算部署之前先算账。显存需求大致可以按这个公式估算显存需求 ≈ 模型参数量 × 每参数字节数 KV Cache 框架开销以 Qwen2.5-7B 为例FP16 下每参数 2 字节权重约 14GB4-bit 量化下每参数约 0.5 字节权重约 3.5GB。KV Cache 取决于上下文长度和 batch size128K 上下文下可能额外占几 GB。框架开销一般留 1~2GB。具体到常见硬件硬件显存推荐模型量化建议RTX 3060 12GB12GBQwen2.5-7B / Qwen3-8BQ4_K_MRTX 4090 24GB24GBQwen3-30B-A3BQ4_K_M 或 Q5Jetson Orin Nano8GBQwen2.5-3B / Qwen3.5-3BQ4Mac M2 16GB统一内存Qwen2.5-7BQ4_K_M双卡 409048GBQwen3-30B-A3BQ8 或 FP16这张表是我实际跑过的配置不是理论值。Jetson Orin Nano 上跑 3B 模型用 llama.cpp 的 CUDA 后端速度大概在 15~20 token/s做本地问答完全够用。4.2 用 llama.cpp 部署 Qwen2.5 的完整流程llama.cpp 是本地部署最通用的方案支持 GGUF 格式跨平台性好。以下是在 Linux 上的完整流程# 1. 克隆并编译 git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDAON cmake --build build --config Release -j # 2. 下载 GGUF 模型以 Qwen2.5-7B-Instruct Q4_K_M 为例 # 从模型仓库下载对应的 gguf 文件到 models/ 目录 # 3. 启动推理服务 ./build/bin/llama-server \ -m models/qwen2.5-7b-instruct-q4_k_m.gguf \ -c 8192 \ -ngl 99 \ --host 0.0.0.0 \ --port 8080参数说明-c 8192是上下文长度-ngl 99表示把所有层都放到 GPU 上。如果你的显存不够可以调小-ngl让部分层跑在 CPU 上但速度会明显下降。启动后访问http://localhost:8080就能看到 Web UI或者直接用 OpenAI 兼容的 API 接口调用curl http://localhost:8080/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5, messages: [{role: user, content: 用 Python 写一个快速排序}], temperature: 0.7 }4.3 用 vLLM 部署 Qwen3 MoE 的注意事项Qwen3 的 MoE 模型用 vLLM 部署体验最好因为 vLLM 对 MoE 的专家并行和 PagedAttention 支持比较成熟。但有几个坑要注意# 安装 vLLM pip install vllm # 启动 Qwen3-30B-A3B 服务 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen3-30B-A3B \ --tensor-parallel-size 1 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --port 8000第一个坑是--gpu-memory-utilization。vLLM 默认会预分配 90% 的显存如果你还要跑其他任务记得调低。第二个坑是--max-model-len设得太大 KV Cache 会吃掉大量显存32K 是个比较稳的起点。第三个坑是 MoE 模型的加载时间比稠密模型长因为专家权重多第一次启动可能要等几分钟。提示Qwen3 MoE 模型在 vLLM 下如果遇到显存不足优先降低--max-model-len而不是降低量化精度。长上下文对 MoE 的显存影响比稠密模型更大。4.4 Jetson Orin Nano 上的边缘部署实录Jetson Orin Nano 是很多边缘 AI 项目的首选硬件8GB 统一内存。在上面部署 Qwen 需要一些特殊处理。首先Jetson 的 CUDA 版本和桌面版不一样编译 llama.cpp 时要指定正确的架构cmake -B build -DGGML_CUDAON -DCMAKE_CUDA_ARCHITECTURES87 cmake --build build --config Release -j487 对应 Orin 系列的 GPU 架构。编译完成后跑一个 3B 的 Qwen2.5 或 Qwen3.5 模型./build/bin/llama-server \ -m models/qwen2.5-3b-instruct-q4_k_m.gguf \ -c 4096 \ -ngl 99 \ --port 8080实测下来3B Q4 模型在 Orin Nano 上占用约 2.5GB 内存推理速度 15~20 token/s功耗在 10W 左右。这个配置做本地语音助手的后端完全够用。注意 Jetson 的内存是 CPU 和 GPU 共享的所以不要同时跑太多其他进程。5. LoRA 微调实战用 Qwen 做领域适配5.1 为什么选 LoRA 而不是全量微调LoRALow-Rank Adaptation的核心思路是在预训练模型的权重矩阵旁边挂两个小矩阵只训练这两个小矩阵冻结原模型权重。这样做的好处是显存占用大幅降低7B 模型的 LoRA 微调在 16GB 显存的卡上就能跑而全量微调至少需要 80GB 以上。对于 Qwen 系列LoRA 微调的典型场景包括领域术语适配医疗、法律、金融、输出格式固定JSON、特定模板、风格迁移客服话术、代码注释风格。我做过一个 Qwen2.5-7B 的 LoRA用来把技术文档转成问答对训练数据 2000 条在单张 4090 上跑了 3 个 epoch大约 40 分钟效果比 prompt engineering 稳定得多。5.2 LoRA 微调的关键参数与实操用 LLaMA-Factory 做 Qwen 的 LoRA 微调是目前比较省心的方案。核心配置如下model_name_or_path: Qwen/Qwen2.5-7B-Instruct stage: sft do_train: true finetuning_type: lora lora_rank: 16 lora_alpha: 32 lora_target: all dataset: my_dataset template: qwen cutoff_len: 2048 per_device_train_batch_size: 2 gradient_accumulation_steps: 8 learning_rate: 1.0e-4 num_train_epochs: 3 bf16: true output_dir: outputs/qwen2.5-lora几个关键参数的解释lora_rank是低秩矩阵的秩16 是常用起点任务越复杂可以调到 32 或 64。lora_alpha一般设为 rank 的两倍。lora_target: all表示对所有线性层都加 LoRA也可以只针对 q_proj、v_proj 等注意力层显存更省但效果可能略差。learning_rate用 1e-4 到 2e-4 之间比较稳太高容易训崩。训练完成后可以把 LoRA 权重合并回原模型python src/export_model.py \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --adapter_name_or_path outputs/qwen2.5-lora \ --template qwen \ --finetuning_type lora \ --export_dir outputs/qwen2.5-merged合并后的模型就是一个标准的 Qwen2.5 模型可以直接用 llama.cpp 或 vLLM 部署。5.3 MoE 模型微调的特殊考量Qwen3 和 Qwen3.5 的 MoE 模型做 LoRA 微调时有一个容易被忽略的问题路由网络的行为可能会因为 LoRA 的介入而发生变化。因为 LoRA 改变了专家层的输入分布Router 的选择可能偏移导致某些专家被过度激活或完全不被激活。实际做法是对 MoE 模型做 LoRA 时建议把lora_target限制在注意力层不要动专家层的 FFN。这样可以保持路由行为的稳定。另外MoE 模型的 LoRA 训练显存占用比稠密模型高因为所有专家权重都要加载即使不训练它们。5.4 微调数据的准备与常见坑数据质量决定微调效果的上限。我踩过的坑包括数据格式不统一导致 template 解析错误、样本长度超过 cutoff_len 被截断、训练集和验证集分布差异太大导致过拟合。一个实用的建议是先用 100 条数据跑一个快速实验确认整个流程能跑通、loss 正常下降再上全量数据。另外Qwen 系列的 chat template 比较特殊用 LLaMA-Factory 的时候一定要指定template: qwen否则对话格式会错乱。6. 常见问题与排查技巧实录6.1 部署阶段的典型报错与解决问题现象可能原因解决方法启动时报显存不足模型太大或上下文设太长降低量化精度或减小 max-model-len推理速度极慢部分层跑在 CPU 上检查 -ngl 参数确认 GPU 层数API 返回空结果template 不匹配确认请求格式和模型 template 一致MoE 模型加载卡住专家权重多IO 慢用 SSD耐心等待首次加载输出乱码或重复量化质量差或温度过高换更高精度量化降低 temperature连接报证书错误本地 HTTPS 配置问题改用 HTTP 或配置正确的证书链6.2 推理质量问题的排查思路模型输出质量差先别急着换模型按这个顺序排查第一检查 prompt 是否清晰Qwen 系列对指令的格式比较敏感用官方推荐的 chat template 效果最好。第二检查 temperature 和 top_p创意任务用 0.7~0.9精确任务用 0.1~0.3。第三检查量化精度Q4 以下的量化在复杂任务上质量下降明显。第四检查上下文是否超长导致关键信息被截断。6.3 性能优化的几个实用技巧如果推理速度不理想可以尝试开启 vLLM 的连续批处理continuous batching提升吞吐用 FP8 或 INT8 量化在支持的硬件上加速调整 KV Cache 的 block size对 MoE 模型开启专家并行。在 Jetson 设备上还可以通过调整功耗模式nvpmodel来平衡性能和功耗。6.4 版本选型的决策清单最后给一个简单的选型决策清单显存 8GB 以下Qwen2.5 或 Qwen3.5 的 3B 稠密模型Q4 量化显存 12~16GBQwen2.5-7B 或 Qwen3-8BQ4_K_M显存 24GBQwen3-30B-A3B MoEQ4_K_M 或 Q5显存 48GBQwen3-30B-A3B FP16 或 Qwen3.5 中等 MoE需要微调Qwen2.5-7B 稠密模型LoRA 方案最成熟需要长上下文Qwen3.5长文检索最稳边缘设备Qwen2.5 或 Qwen3.5 小稠密模型我个人在实际操作中的体会是不要盲目追新。Qwen2.5 在很多场景下仍然是性价比最高的选择尤其是你需要稳定、可预测的行为时。Qwen3 的 MoE 适合尝鲜和中等规模部署Qwen3.5 则是当前生产环境里比较均衡的选项。选型的时候先算显存账再看任务需求最后才看版本号。