基于ms-swift的新闻摘要生成系统训练与部署全记录

基于 ms-swift 的新闻摘要生成系统训练与部署实践

在信息爆炸的时代，每天产生的新闻文本量已远超人工处理能力。主流媒体、资讯平台和内容聚合服务都在寻求一种高效、准确且可扩展的自动化摘要方案。然而，理想中的“一键生成”背后，是模型选型、长文本建模、显存瓶颈、推理延迟等一系列工程挑战。

以 Qwen3-7B 这类大语言模型为例，其原生能力虽强，但直接用于中文新闻摘要仍面临诸多问题：生成内容冗余、关键信息遗漏、响应速度慢、部署成本高……如何将这样一个“通才”模型，塑造成一个专注、稳定、高效的“专业编辑”？这正是ms-swift框架的价值所在。

不同于传统微调工具链的割裂体验，ms-swift 提供了一条从数据准备到生产上线的完整路径。它不只关注“能不能跑”，更致力于解决“能不能用”、“好不好用”、“省不省资源”的实际问题。接下来，我们将以构建一套面向中文新闻场景的摘要系统为线索，深入拆解这套框架是如何在真实项目中落地的。

整个系统的构建并非一蹴而就，而是遵循“先适配、再优化、后压缩、终部署”的渐进式思路。我们选择 Qwen3-7B 作为基础模型，不仅因为它在中文语境下表现出色，更因为 ms-swift 对其提供了开箱即用的支持——无需手动修改模型结构或编写复杂的加载逻辑，仅需一条命令即可启动训练。

第一步是让模型学会“看懂新闻并提炼要点”。我们整理了约10万条经过人工校验的中文新闻-摘要对，格式如下：

{ "messages": [ { "role": "user", "content": "请为以下新闻生成一段简洁摘要：\n\n[新闻正文]" }, { "role": "assistant", "content": "[标准摘要]" } ] }

使用 LoRA 微调是最合理的起点。7B 级别的全参数微调对大多数团队来说仍是不可承受之重，而 LoRA 只需更新低秩矩阵，大幅降低了显存需求。实际测试中，在单张 A10（24GB）上运行如下命令：

swift sft \ --model_type qwen3-7b \ --train_dataset news_summary_train.jsonl \ --val_dataset news_summary_val.jsonl \ --output_dir ./output-qwen3-lora \ --lora_rank 64 \ --lora_alpha 16 \ --batch_size 4 \ --num_train_epochs 3 \ --max_length 4096 \ --use_loss_scale_sampler true

全程显存占用控制在 8.7GB 左右，训练吞吐达到每秒近两个样本。这里值得一提的是--use_loss_scale_sampler参数——它会动态调整难例的采样频率，让模型更关注那些容易出错的样本，比如涉及多事件嵌套或专业术语密集的财经报道。这种细粒度的数据调度策略，在提升最终生成质量方面起到了微妙但关键的作用。

但监督微调（SFT）只是起点。你会发现，即使 Loss 下降明显，模型输出仍可能过于啰嗦、风格不统一，甚至出现“正确但无用”的泛泛而谈。这时候就需要引入人类偏好对齐机制。

我们通过 A/B 测试收集了数千组对比数据：同一段新闻输入，由不同温度设置下的模型生成两个版本摘要，交由标注员判断哪个更优。基于这些偏好数据，采用 DPO（Direct Preference Optimization）算法进行第二阶段训练：

swift sft \ --model_type qwen3-7b \ --train_dataset dpo_news_pairs.jsonl \ --sft_type dpo \ --beta 0.1 \ --output_dir ./output-qwen3-dpo \ --resume_from_checkpoint ./output-qwen3-lora

DPO 的优势在于无需额外训练奖励模型，直接利用偏好数据优化策略。经过一轮 DPO 微调后，人工评估显示摘要的“可读性”和“信息密度”显著提升，尤其在避免重复表达和突出核心事实方面表现突出。这也印证了一个经验：SFT 解决“会不会”，DPO 解决“好不好”。

当模型能力趋于稳定，下一步就是考虑如何让它走出实验室，进入生产环境。此时最大的障碍往往是资源消耗。

原始 FP16 版本的 Qwen3-7B 推理需要约 14GB 显存，这意味着至少得用 A10 或更高规格卡才能部署。但对于中小规模应用而言，这样的硬件投入并不经济。有没有办法在消费级显卡上运行？

答案是肯定的——量化。

ms-swift 内置了对 GPTQ、AWQ 和 BNB 等主流量化方案的支持。我们选择了 GPTQ-4bit 方案，在保持生成质量基本不变的前提下，将模型体积压缩至原来的 1/3 左右：

swift export \ --model_type qwen3-7b \ --ckpt_dir ./output-qwen3-dpo \ --quant_method gptq \ --quant_bits 4 \ --output_dir ./qwen3-gptq-4bit

导出后的模型仅需约 6GB 显存即可加载，RTX 3090、4090 等消费级显卡均可胜任。但这还不够，我们还需要高并发服务能力。

为此，ms-swift 集成了 vLLM 作为推理后端。vLLM 的 PagedAttention 技术能有效管理 KV 缓存，实现连续批处理（Continuous Batching），极大提升了吞吐效率。启动服务仅需一行命令：

swift infer \ --model_type qwen3-7b \ --ckpt_dir ./qwen3-gptq-4bit \ --infer_backend vllm \ --port 8080 \ --api_key my-secret-key

服务启动后自动暴露 OpenAI 兼容接口，客户端可通过标准方式调用：

curl http://localhost:8080/v1/chat/completions \ -H "Authorization: Bearer my-secret-key" \ -H "Content-Type: application/json" \ -d '{ "model": "qwen3-7b", "messages": [{"role": "user", "content": "请用一句话总结以下新闻：..."}] }'

实测在单卡环境下，P99 延迟控制在 800ms 以内，支持超过 50 QPS 的稳定请求处理。对于日均百万级访问量的资讯平台来说，这一性能足以支撑核心业务场景。

当然，真正的生产系统不能只追求“快”，还要“稳”和“安全”。

我们在推理链路中加入了后处理模块，负责执行关键词提取、句子去重和长度截断等操作。更重要的是，集成了敏感词过滤和基础事实核查插件，防止生成包含不当表述或明显错误的内容。这些虽然不属于 ms-swift 的核心功能，但得益于其开放的接口设计，很容易与外部组件集成。

此外，面对未来可能的扩展需求——例如结合知识库增强生成准确性（RAG）、支持多模态输入（如图文新闻）——ms-swift 同样具备前瞻性支持。其多模态 packing 能力允许将图像 token 与文本混合训练；Agent Template 机制则能让模型学会调用外部工具获取实时数据。这意味着今天的摘要系统，明天可以轻松演进为一个智能新闻助理。

回顾整个流程，有几个关键设计点值得强调：