本地大模型实战：用MiniCPM5-2B构建每日新闻简报系统

1. 项目概述与整体设计思路

1.1 为什么要做一个本地新闻简报系统

先说一下我做这个项目的背景。每天早上一睁眼，各种新闻客户端推送、公众号更新、行业邮件涌进来，信息量非常大。我关注的科技、开源社区、AI 领域的动态散布在几十个不同来源里，逐个去刷非常浪费时间。之前也试过用云端的大模型 API 做摘要，但有两个问题一直让我不踏实：一是新闻正文和链接全部要传给第三方服务器，隐私上没法保证；二是有时候就想快速看下某个技术方向的进展，来回调 API 既慢又烧钱。

后来我接触到 MiniCPM5-2B 这个本地大模型，2B 参数量意味着它对硬件的要求并不算高，量化之后在中低配置的电脑上也能流畅运行。我就在想，能不能用它在本地跑一个全自动的新闻简报系统：批量抓取我订阅的信息源，用本地模型做摘要和分类，最终生成一份干净的 Markdown 或者 HTML 简报，早上起来扫一眼就够了。

这个系统做下来之后，效果确实超出预期。它对硬件的要求很宽松，我平时用的是一台 16GB 内存的笔记本，没有独立显卡，纯 CPU 推理也能在可接受的时间内完成一二十个新闻源的摘要生成。整个过程不依赖任何外部 API，除了抓取 RSS 源之外完全不联网，数据的私密性也有保障。对于信息获取需求比较固定、又在意隐私的人来说，这套方案很适合复制一套。

1.2 系统架构与核心模块划分

整个系统的设计思路可以拆成四个层次：

• 信息采集层：负责抓取 RSS/Atom 订阅源，解析出标题、链接、发布时间和正文摘要。这是整个系统的入口，也是最容易出错的一层，因为各个信息源的 RSS 格式并不完全统一，正文也可能残缺不全。
• 内容预处理层：对抓取到的原始文本做清洗、去重和截断。小模型的上下文窗口有限，必须在送入模型之前把文本裁剪到合理长度，同时去掉 HTML 标签、广告噪声和重复段落。
• 摘要生成层：调用本地部署的 MiniCPM5-2B 模型，通过设定好的 Prompt 模板，把每篇新闻压缩成几句话的摘要。这一层最考验 Prompt 的编写质量，直接决定了简报的可读性。
• 展示分发层：把生成好的摘要汇总成统一格式的简报，可以输出到终端、保存为 Markdown/HTML 文件，也可以通过邮件或即时通信工具推送到手机。

这套架构的核心优势是每个模块都可以独立替换。比如不想用 RSS 了，把采集层换成一个爬虫脚本就行；觉得 2B 模型摘要不够准，换更大的模型改动也只在生成层内部。模块之间通过标准的文本文件或者 JSON 结构传递数据，调试起来很直接。

2. MiniCPM5-2B 部署与分析能力边界

2.1 模型选型：为什么是 2B 参数规模

我一直认为，不是所有任务都需要几百亿参数的大模型。新闻摘要这种任务，本质上是对单篇文本的信息压缩，它对“常识推理”和“长文本理解”的要求远没有写代码、做数学推理那么高。2B 参数级别的模型，经过良好微调之后，完全能够胜任提取关键信息、归纳段落主旨这一类工作。

MiniCPM5-2B 还有一个很现实的优势——部署门槛低。我用 Ollama 做推理运行时，把模型量化到 Q4 之后，模型文件大小只有 1.5GB 左右。这意味着它不光能在普通笔记本上跑，甚至放到树莓派、NVIDIA Jetson 这类边缘设备上也有机会运行。在功耗和响应速度之间，2B 是一个目前看下来甜点级的平衡点。

当然，2B 模型的能力边界摆在那里。它对输入文本的长度有限制，上下文窗口通常只有 4K 到 8K token，如果一篇新闻正文超过这个长度就需要截断或者分片。另外，它生成的摘要偶尔会遗漏细微的时间信息或者数字，这属于小模型的通病。解决的办法不是换更重的模型，而是在 Prompt 里强制要求输出关键要素，并在预处理阶段把最相关的段落保留下来。

2.2 部署流程与量化参数选择

用 Ollama 部署这个模型非常省心，我直接把部署全过程整理成可复现的步骤。

安装 Ollama 之后，拉取模型镜像只需要一条命令：

ollama pull minicpm5:2b

如果网络环境下载慢，可以手动下载模型文件放到 Ollama 的模型目录下，然后用ollama create命令创建一个自定义的本地模型镜像。我自己是直接跑了个Modelfile，把默认温度调低了一些：

FROM minicpm5:2b PARAMETER temperature 0.3 PARAMETER top_p 0.9 PARAMETER num_ctx 4096

这里解释一下我为什么这么设置。temperature控制在摘要生成时的随机性，新闻摘要需要准确而非创意，所以调到 0.3，避免模型自由发挥；top_p保持 0.9 左右，在采样的多样性上留一点余地；num_ctx直接决定了模型能看到的文本长度，4096 对这个任务来说比较充裕，如果机器内存紧张可以降到 2048。

模型跑起来之后，用一行命令就能验证推理是否正常：

ollama run minicpm5:2b "请用一句话概括：本地大模型正在改变信息处理的方式。"

看到输出结果正常，说明模型已经可以投入使用了。如果打算长期高频调用，建议把 Ollama 的服务端口固定下来，默认是11434，后续的 Python 代码要直接通过 HTTP 接口调它。

2.3 本地推理的性能实测数据

我自己在几台不同配置的机器上跑过这个任务，实测数据给大家做个参考。测试场景是单条新闻正文约 1500 字，模型文件是 Q4 量化版本：

说实话，即便是纯 CPU 推理，一晚上处理 30 条左右的新闻也只要几分钟，放在睡前跑或者清晨自动跑完全够用。真正影响体验的不是推理速度，而是起进程时的冷启动时间。我实际使用中发现，如果频繁调ollama run命令，每次加载模型都得好几秒，所以最好让模型常驻内存，通过 HTTP 接口连续请求。

3. 核心系统实现与关键代码解析

3.1 新闻源采集与内容清洗

采集层我是基于 Feedparser 做的，这个库几乎支持所有标准的 RSS/Atom 格式，处理起来比较省事。

import feedparser import hashlib import html import re def fetch_articles(feed_urls, max_per_feed=10): articles = [] for url in feed_urls: feed = feedparser.parse(url) for entry in feed.entries[:max_per_feed]: title = html.unescape(entry.get('title', '')) link = entry.get('link', '') summary = html.unescape(entry.get('summary', '')) published = entry.get('published', '') # 清洗文本：去掉HTML标签和多余空白 summary = re.sub(r'<[^>]+>', '', summary) summary = re.sub(r'\s+', ' ', summary).strip() # 用链接做去重指纹 doc_id = hashlib.md5(link.encode()).hexdigest() articles.append({ 'doc_id': doc_id, 'title': title, 'link': link, 'summary': summary, 'published': published }) return articles

这个函数做了一件很容易被忽略但很重要的事情——用链接的 MD5 值作为去重指纹。因为很多新闻站点会把同一条新闻同时发布在首页 RSS 和分类 RSS 里，如果不做去重，简报里就会反复出现同一条内容，非常影响阅读体验。

采集到的summary通常是 RSS 里附带的摘要或者正文开头部分，质量参差不齐。有些源的 summary 只有十几字，有些源则直接把正文全部塞进来。所以我在预处理时加了一道保底逻辑：如果 summary 太短，就用爬虫抓取正文全文，二选一，保证送进模型的内容有足够信息量。

3.2 文本截断与分块策略

MiniCPM5-2B 的上下文窗口是有限的，把一整篇 5000 字的文章直接塞进去，很容易超出窗口限制导致报错。我的做法是设定一个安全阈值——按字符数计算，单篇文本控制在 800 字以内，然后用 token 再做一次兜底判断。

def truncate_text(text, max_chars=800): if len(text) <= max_chars: return text # 优先保留开头和结尾，很多新闻的关键结论在尾部 head = text[:int(max_chars * 0.6)] tail = text[-int(max_chars * 0.4):] return head + '……' + tail

先说结论：对于新闻这种“倒金字塔”结构的文本，最核心的信息往往在开头，所以直接截断前面部分通常就能覆盖要点。但我也踩过坑，有些深度报道把结论放在最后，所以后来我改成了一种混合策略——开头截取 60%，结尾截取 40%，中间用省略号衔接。这样哪怕前面的段落只是引入，关键结论也不会丢。

如果你发现模型生成的摘要总缺关键数据，比如金额、时间、人名，那就说明你这边的正文截断策略太粗暴，把含有关键信息的段落切掉了。这时候可以适当放宽到 1200 字，或者改进截断逻辑，优先保留包含数字、年份、品牌名的句子。

3.3 摘要生成的 Prompt 与 API 调用

摘要生成层的核心不是模型本身，而是 Prompt 的设计。2B 模型对大段复杂的指令理解能力有限，所以我用了一套“短指令-明确要素-输出格式”的模板。

import requests import json OLLAMA_URL = "http://localhost:11434/api/generate" def summarize_article(article): prompt = f"""请为以下新闻写三句话摘要。 要求：第一句话说明核心事件；第二句话补充关键数据或影响；第三句话点明意义。 标题：{article['title']} 正文：{article['summary']} 摘要：""" payload = { "model": "minicpm5:2b", "prompt": prompt, "stream": False, "options": { "temperature": 0.3, "top_p": 0.9, "max_tokens": 256 } } resp = requests.post(OLLAMA_URL, json=payload, timeout=120) resp.raise_for_status() result = resp.json() return result['response'].strip()

写这个 Prompt 时，我犯过不小的错。一开始我让它“写一段精彩的摘要”，结果 2B 模型经常发挥不稳定，有时候冒出一堆套话，有时候抓不住重点。后来我把输出要求拆成三句话，每句话都有明确的职责，模型的表现立刻稳定了很多。

这里有个很重要的心理预期：2B 模型不是让你做创作，而是在做信息压缩。指令越具体，它完成得越可靠。如果你在 Prompt 里给它“发挥空间”，它反而容易跑偏。

3.4 简报生成：汇总成 Markdown 和 HTML

等所有文章都生成完摘要，接下来就是汇总。我做了两个输出格式：一份 Markdown 用于本地阅读，一份 HTML 用于邮件推送。Markdown 的生成逻辑很直接：

def build_markdown_report(articles_with_summaries): lines = ["# 今日科技简报", "", f"生成时间：{datetime.now().strftime('%Y-%m-%d %H:%M')}", ""] for idx, item in enumerate(articles_with_summaries, 1): lines.append(f"## {idx}. {item['title']}") lines.append("") lines.append(item['summary']) lines.append("") lines.append(f"来源链接：{item['link']}") lines.append("") lines.append("---") lines.append("") return "\n".join(lines)

HTML 版本则是在 Markdown 的基础上做了一层转换，用正则或者markdown库转成 HTML，加一些简单的 CSS 样式。这样邮件客户端里打开就是一份排版清晰、链接可点的简报。

我建议至少保留 Markdown 版本，因为它可以直接被 Obsidian、Typora 这类工具打开，方便后续做笔记归档。我自己的使用习惯是：每天早上自动生成一份带日期的 Markdown 文件，存放在一个专门建好的本地目录里，用文件夹按年月分组。

3.5 自动化调度与推送配置

手动跑脚本只是第一步，真正让这个系统“活”起来的，是让它每天固定时间自动执行，并且把结果推送到手机上。

Linux 或 macOS 上直接用 crontab 就能搞定：

# 每天早上 7:30 生成新闻简报 30 7 * * * cd /home/user/news-briefing && /usr/bin/python3 main.py >> logs/briefing.log 2>&1

Windows 上可以用任务计划程序，原理一样，创建一个每天触发的任务，执行python main.py即可。

推送这部分我试过两种方案：邮件和即时通信机器人。邮件用 Python 内置的smtplib就能实现，把 HTML 简报作为正文发送；机器人方案更轻量，Webhook 一调就完事。这里就不展开讲具体的配置了，因为不同平台的 Webhook 地址有一定差异，但整体思路一致。

自动化跑起来之后，最大的体验改变是：我不再需要主动“刷”信息了。每天早上看到的就是一份过滤好的简报，碰到特别感兴趣的主题再点原文链接深入阅读，信息获取效率高了一截。

4. 常见问题与调试实录

4.1 高频报错与解决办法

我在搭建和运行这套系统的过程中，整理了一份出现频率最高的调试备忘。

4.2 摘要质量不稳定的排查思路

这是大家在本地模型项目里遇到最多的坑。2B 模型生成的摘要，有时候效果惊艳，有时候一塌糊涂，表现起伏很大。我排查了一圈之后发现，真正的问题往往不出在模型本身，而是出在输入文本的质量上。

这里我举一个实际的例子。某个技术博客的 RSS 源，摘要字段只有一句“本文继续介绍上一篇文章的话题”，这种低信息量的输入，任何模型都无能为力。后来我加了内容抓取逻辑，发现文章正文是可以访问的，就改成优先抽取正文全文。摘要质量立刻有了明显提升。

另外一个小技巧是给 Prompt 里加一个“关键词提取”的中间步骤。先让模型输出文章里的 3-5 个关键词，再基于关键词生成摘要。这个策略用在小模型上意外地有效，相当于给模型一个“先理解再总结”的过程，比直接让它总结要稳得多。

4.3 性能调优的三个方向

• 并发优化：采用多线程并发调用模型的 HTTP 接口，单线程处理 20 篇新闻可能要 5 分钟，改成 4 个并发线程之后能压缩到 1 分半左右。不过要注意内存占用，并发线程太多容易超内存。
• 模型常驻：用 Ollama 的OLLAMA_KEEP_ALIVE参数让模型保持内存常驻，避免每次请求都重新加载模型权重，这个优化对 CPU 机器效果尤其明显。
• 增量去重：把已经处理过的新闻指纹存成一个本地processed.json文件，每次跑之前先加载，跳过那些已经收录过的链接，避免同样的新闻反复进简报。

5. 扩展玩法与个人使用感受

5.1 给简报增加分类与评分

基础版的简报只是把新闻按时间顺序排列，用久了之后我加了两个增强功能。第一个是简单的话题分类，在摘要生成时多加一行指令，让模型判断这篇文章属于“AI 技术”、“开源动态”、“硬件评测”还是“行业新闻”，然后存成标签字段。第二个是相关性打分，因为只关注自己领域内最重要的动态，所以会让模型给每篇文章的“技术参考价值”打个 1-5 分，排序时高分排前面。

这个方案不需要任何额外模型，就是在原有 Prompt 里加了两行指令。实测下来，2B 模型打分精度虽然有些波动，但排列优先级的时候够用了，毕竟我已经把范围控制在十几个固定科技源里。

5.2 用本地知识库增强背景信息

如果想进一步升级，可以在摘要生成之后，把文章里的关键实体和本地笔记库做一次匹配。比如文章提到了某个开源项目，如果你的笔记库里已经有关于这个项目的背景记录，可以把相关笔记段落附加到 Prompt 里，让模型结合背景生成摘要。

这个功能我自己做的是很轻量的版本，就是用关键词匹配本地 Markdown 文件，找到就拼进 Prompt，找不到就不管。缺点是匹配精度一般，但胜在零成本、零依赖。有精力的话可以接一个真正的向量数据库，效果会好很多。

5.3 我个人的使用体验

这套系统我已经稳定跑了两个多月，目前每天早上 7:30 自动生成一份简报，工作日大约 20 到 30 条新闻，周末频率降低到 10 条以内。从实用角度看，它最大的价值不是省了多少时间，而是让我不再焦虑：信息源就摆在那里，每天有人帮你盯着，有重要内容不会错过。

另一个层面的收获是对本地模型能力边界有了更直观的认知。以前总觉得要上大模型才能做正经事，等真正把 2B 模型跑起来，放到一个边界清晰的任务里，发现它的可用性远超预期。关键不在于模型多大，而在于你有没有把任务拆解到位、有没有把输入质量管好。

如果你也想搭一套，我的建议是：别一开始就追求大而全，先跑通一个最简单版本——一个 RSS 源、一篇新闻、一句摘要。等这个链路跑通了，再慢慢加源、加功能、加自动化。这个系统最难的环节不是代码，也不是模型选型，而是你会不会持续用起来。每天固定时间看简报，坚持两周，你就会感受到这种主动过滤信息的方式，比被动刷信息流舒服太多了。