我先把这套系统跑起来的关键路径讲清楚。这个项目解决的是信息过载问题每天几十个技术社区、开源动态、行业资讯渠道真正值得花时间看的可能不到五条。大多数人选择刷手机被动接收而我选择让本地小模型先替我读一遍每天自动产出一份结构化的新闻简报。MiniCPM5-2B是这套系统的核心引擎2B参数量量化后最低6GB显存就能跑完全离线、零API费用、数据不出本机。这篇文章会完整记录我从选型、部署到写代码跑通的全部过程包括踩过的坑和最终的优化方案。适合正在折腾本地大模型、又恰好被信息流困扰的开发者。1. 为什么这个场景非用本地模型不可1.1 云端API的隐性成本与本地部署的真实收益做新闻简报这个需求第一反应当然是调云端大模型API。我自己一开始也是这么想的把RSS抓回来塞给某个对话接口让它总结完事。但真跑起来才发现事情没那么简单。先说经济账。新闻简报是高频任务每天至少跑两轮早报和晚报每轮要处理二十到三十条新闻。把这些内容全部发给云端模型做摘要按token计费一个月下来开销不小。如果用的是免费额度又要面对限流和并发限制。更要命的是延迟不稳定高峰期一个摘要请求可能要等三十秒整个任务跑下来有时候要十几分钟。再说隐私和数据边界。我抓取的很多内容是企业内部技术动态、竞品公开信息、行业情报。这些内容从公网抓下来本身没问题但全部转发给第三方模型服务心里总有根刺。去年好几个云厂商都在服务条款里写明用户输入可能被用于模型训练这意味着我发的每一条内容都可能变成别人模型的知识这让人非常不舒服。本地部署就没有这些顾虑。模型权重文件直接放在你机器上推理过程完全在本地完成数据不出这台设备。这不仅仅是省了API费用这么简单而是把整个系统的边界收缩到一个自己完全可控的范围内。对于新闻简报这类有固定格式、固定频次、重复性很强的任务本地小模型完全够用。1.2 MiniCPM5-2B的选型逻辑与硬件门槛确定走本地部署路线之后模型选型成了第一个问题。我前后对比过几类方案7B级别的通用模型、13B级别的大模型、以及2B左右的端侧模型。选择MiniCPM5-2B的核心原因有三点。第一是显存门槛足够低。4bit量化之后的MiniCPM5-2B实测占用显存只有4.5GB左右这意味着你不需要一张昂贵的专业卡。我测试用的是一张普通的消费级显卡8GB显存跑起来非常从容显存还有将近一半的余量。如果你没有独立显卡用纯CPU跑也行就是要忍受推理速度慢一些20条新闻摘要可能要跑一百多秒。第二是它的指令跟随能力在端侧模型里确实能打。新闻简报这个任务对模型的要求很清晰从一堆新闻条目里挑重点按固定格式输出摘要用中文表达。MiniCPM5-2B在摘要和结构化文本生成这两块做了针对性优化实际测试下来格式稳定性比同级别的其他模型高出一截。第三是中文处理能力。做中文新闻简报模型的中文语感和表达流畅度直接决定产出质量。MiniCPM系列在中文语料上的训练比其他端侧模型更充分它的输出不会出现那种翻译腔也没有英文模型常见的中文夹英文的毛病。硬件门槛可以用一张表说清楚配置方案显存/内存要求推理速度20条摘要适合场景8GB显存GPU 4bit量化显存约4.5GB约40秒推荐方案兼顾速度与质量16GB内存纯CPU 4bit量化内存约8GB约2-3分钟无GPU时的备选方案16GB显存GPU 8bit量化显存约9GB约30秒追求更好生成质量时可考虑实际体验下来4bit量化版和8bit量化版的输出质量差距肉眼几乎不可见但显存占用差距很大。所以我的建议是能用小跑的就用小跑的省下来的显存留给后面加RAG部分的向量数据库。2. 部署MiniCPM5-2B两条路都能跑通2.1 Ollama部署五分钟让模型跑起来本地部署大模型最简单粗暴的方式是用Ollama。这个工具把模型下载、依赖管理、推理服务封装成几条命令对开发者极其友好。我整个部署过程大约只花了五分钟。# 1. 安装ollamamacOS/Linux一行命令Windows去官网下exe curl -fsSL https://ollama.com/install.sh | sh # 2. 拉取MiniCPM5-2B模型about 2GB取决于网络速度 ollama pull minicpm5:2b # 3. 启动服务默认监听11434端口设成常驻进程 ollama serve拉完模型之后先做一次快速验证确保模型是真的能跑而不是只把文件下下来就完事ollama run minicpm5:2b 用一句话概括什么是RSS订阅如果这一步能正常输出中文回答说明模型已经就绪。这时Ollama已经自动在11434端口起了一个OpenAI兼容的API服务接下来就可以直接写Python代码去调它了。这里有个容易被忽略的点Ollama默认不会随系统自动启动。如果服务器重启mongmodel是不会自动加载的。建议把这个服务注册成系统服务或者写进开机启动项。我是在Linux服务器上用systemd管理的写一个简单的service文件就能搞定。[Unit] DescriptionOllama Service Afternetwork-online.target [Service] ExecStart/usr/local/bin/ollama serve Restartalways RestartSec3 [Install] WantedBymulti-user.target把这段存成/etc/systemd/system/ollama.service然后执行sudo systemctl enable --now ollama服务就能在开机后自动拉起模型。2.2 显存与上下文窗口的合理设置这里单独说一个很多新手容易踩坑的地方Ollama默认的上下文窗口大小。Ollama启动服务时默认num_ctx是2048个token。做新闻简报的时候一个prompt里要放二十条新闻的标题和摘要再要求模型输出结构化内容经常一算就超过2000个token。一旦超出上下文窗口模型会出现仿佛失忆的表现——比如让它挑五条最重要的新闻它只输出三条然后开始胡乱发挥。解决办法是在启动服务时手动指定更大的上下文窗口ollama serve --num_ctx 8192或者干脆在模型配置文件里固定下来。在~/.ollama/下创建一个Modelfile内容如下FROM minicpm5:2b PARAMETER num_ctx 8192 PARAMETER temperature 0.3然后用ollama create minicpm5-news -f Modelfile生成一个专门给新闻简报用的模型实例。关于温度参数我强烈建议在摘要生成任务里把temperature调低到0.3到0.5之间。新闻摘要要求的是忠实度和稳定性不是创造性发散。默认的0.7温度下模型偶尔会自己加戏在摘要里冒出一句没有出处的主观评论这对新闻场景是致命的。上下文窗口和温度这两个参数是MiniCPM5-2B做新闻摘要任务最影响输出质量的两个旋钮调好它们效果能提升一个台阶。3. 新闻简报系统的整体链路设计3.1 三个核心模块抓取、理解、排版整个新闻简报系统可以拆成三个独立模块每个模块各司其职互不干扰。这样设计的好处是某个环节出问题时可以单独重启或替换不会牵连整个系统。数据抓取层负责从各来源获取原始内容。我主要用RSS订阅源和少量公开API。RSS的优点是标准、轻量、稳定不需要处理复杂的页面结构。选源的时候要注意时效性和稳定性我建议优先选择那些更新频率固定、存活时间长的源比如技术社区的热帖、知名博客的独立RSS。抓取频率也不要太激进每四小时拉一次就够了高频抓取既浪费资源又容易被对方拉黑。内容处理层是系统的中枢大脑。这一层承载两个任务一是对原始内容做清洗和去重把HTML标签、广告噪声、重复内容过滤掉二是调用MiniCPM5-2B对每一条新闻做摘要然后合并所有单条摘要再让模型生成一份带有重点排序和观察评论的完整简报。输出层负责把模型生成的结果渲染成可读性强的格式。我选择输出Markdown因为Markdown既能直接阅读也能方便地转成HTML邮件、PDF等格式。输出层还会做一次自检检查简报格式是否完整——如果模型出现输出中断系统会重新生成一次而不是把半成品发出去。3.2 数据流转与失败兜底机制这三个模块之间通过一个简单的队列衔接我用的就是Python标准库的queue模块没有引入额外的消息中间件因为当前的复杂度完全不需要。抓取层每完成一次抓取把原始数据push到队列里处理层从队列里取数据逐条处理处理完的结果再输入输出层。整个数据流是一个单向管道RSS源 - 抓取模块 - 清洗去重 - 单条摘要 - 汇总排序 - Markdown渲染 - 本地文件/邮件推送这个链路上每个环节都可能出问题所以必须设计兜底机制。我的经验是不要让任何一个模块的失败中断整个流程。抓取模块如果某个RSS源挂了就跳过这个源继续抓下一个不能因为一个源出问题导致整个任务卡死模型调用如果超时重试两次两次失败就跳过这条新闻也不能让进程挂在那里等。我把每次运行的详细日志写入digest.log包括每个源抓了多少条、过滤了多少条、模型处理每一条耗时多少、最终简报生成了没有。这样一旦某天简报内容有问题直接翻日志看是在哪个环节出的偏差不用瞎猜。4. 代码逐段拆解从RSS抓取到简报输出4.1 数据抓取与正文清洗的实现我用feedparser这个库来处理RSS解析简单直接。抓取模块的代码并不复杂关键在于清洗逻辑要做得干净。import feedparser import re import html from datetime import datetime def fetch_rss_feeds(feed_configs): 从多个RSS源抓取新闻返回标准化后的条目列表 feed_configs: [{name: source_alias, url: http://...}, ...] all_items [] for feed_cfg in feed_configs: try: feed feedparser.parse(feed_cfg[url], agentNewsDigestBot/1.0) for entry in feed.entries[:20]: # 每个源最多取20条 item { source: feed_cfg[name], title: html.unescape(entry.get(title, )).strip(), link: entry.get(link, ), summary: clean_html(entry.get(summary, )), published: entry.get(published, ), fetched_at: datetime.now().isoformat() } if item[title] and len(item[title]) 5: all_items.append(item) except Exception as e: # 单个源挂了记日志继续跑不能中断整个任务 print(f[ERROR] RSS源失败: {feed_cfg[name]}, {e}) continue return all_items def clean_html(raw_text): 去掉HTML标签压缩空白截断过长文本 # 去掉所有HTML标签 text re.sub(r[^], , raw_text) # 反转义HTML实体 text html.unescape(text) # 压缩多余空白和换行 text re.sub(r\s, , text).strip() # 摘要控制在300字内避免prompt过长 return text[:300]这个抓取模块有几个细节值得说。agent参数必须设置这是网络礼仪告诉对方服务器我是谁每个源控制最多取20条因为后续要喂给模型做摘要太多了token会爆单个源抓取失败用try-except兜住绝对不能让它中断整个任务。抓回来的原始数据里有很多是凑数的低质量内容比如只有标题没正文的广告帖、已经过时的旧闻。如果把这些全喂给模型既浪费token又稀释重点。所以在进入模型之前我还做了一道轻量级的过滤把标题含广告推广等明显标记的条目剔除把抓取时间超过三天的旧条目剔除。这步逻辑写在后面的调度代码里这里先不展开。4.2 让2B小模型说人话的Prompt设计Prompt设计是整个系统的灵魂。MiniCPM5-2B是个2B参数的小模型它对Prompt的敏感度比大模型高很多——同一个任务Prompt写得含糊和写得清晰输出质量是天壤之别。我拿新闻摘要这个任务前后迭代了四版Prompt最终稳定在一个模板上。第一版Prompt只写了请为以下新闻写摘要模型输出的是复述原文没有提炼信息。第二版加上了用一句话概括结果模型把一句话写得又长又碎。第三版开始给格式约束要求输出标题xxx\n摘要xxx格式总算稳定了但摘要内容还是不够精炼。直到第四版引入了角色设定 明确输出要求 示例的三层结构输出才真正达到可用的水平。SYSTEM_PROMPT 你是一位技术新闻编辑擅长从杂乱信息中提炼要点。你的文字简洁有力杜绝空话套话。 def build_summary_prompt(item): 构造单条新闻摘要的prompt return f请阅读以下新闻内容提取最核心的信息用一句话中文摘要概括不超过50字。 要求 1. 摘要必须包含谁/什么 做了什么 影响是什么三个要素 2. 只陈述事情本身不要评论不要使用值得注意的是令人震惊的是这类表达 3. 保持客观中立直接给出结论 新闻标题{item[title]} 新闻内容{item[summary]} 摘要 def build_digest_prompt(items): 构造最终简报生成的promptitems是已完成摘要的条目列表 news_block \n.join([ f{i1}. 标题{it[title]}\n 摘要{it[summary]}\n 来源{it[source]} for i, it in enumerate(items) ]) return f基于以下{len(items)}条已摘要新闻生成一份当日技术新闻简报。 要求 1. 从中挑出最重要的5条按重要程度从高到低排序 2. 每条保留原有摘要不要重新扩写 3. 在简报末尾写一段今日观察用3-5句话总结今日技术动态的整体趋势 4. 严格使用以下Markdown格式输出 ## 今日要闻 1. **新闻标题**来源 摘要内容 2. ... ## 今日观察 你的观察评论 ----- 待处理新闻 {news_block} SYSTEM_PROMPT之所以单独抽出来是因为Ollama的API支持system角色把角色设定放在system里比放在user prompt里更有效。模型在system角色里会更好地进入状态输出的正式感明显增强。还有个细节摘要要求里明确写了不要使用『值得注意的是』这类表达。这是因为我发现小模型特别喜欢用这种废话连接词你不禁止它它每一句摘要前面都要加一个。这个负面约束是调小模型时非常实用的技巧。4.3 调用本地模型的核心代码写完了Prompt接下来就是把Prompt喂给模型拿到输出。这里我直接用requests库调Ollama的chat接口不需要引入LangChain之类的重量级框架。对于这种简单的单模型调用标准库加requests完全可以搞定。import requests import json import time def call_local_model(messages, temperature0.3, max_retries2): 调用Ollama的chat接口带重试机制的封装 messages: [{role: system/user/assistant, content: ...}] url http://localhost:11434/api/chat payload { model: minicpm5-news, # 用前面创建的专属模型实例 messages: messages, stream: False, temperature: temperature, max_tokens: 1500, } for attempt in range(max_retries 1): try: resp requests.post(url, jsonpayload, timeout90) resp.raise_for_status() data resp.json() return data[message][content].strip() except Exception as e: print(f[WARN] 模型调用失败(第{attempt1}次): {e}) if attempt max_retries: time.sleep(2 * (attempt 1)) return None def summarize_news(item): 对单条新闻生成摘要 messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: build_summary_prompt(item)}, ] result call_local_model(messages) return result if result else 摘要生成失败 def create_digest(items): 对全部已摘要新闻生成最终简报 digest_block generate_digest(items) return digest_block这里有个重要设计先逐条摘要再统一生成简报而不是一次性把二十条新闻全塞给模型让它一次输出。原因有二一是单次prompt太长会超上下文窗口二是一次性让模型输出太多内容2B小模型后半段容易跑偏越写越离谱。逐条摘要是让模型的注意力集中在一条新闻上输出质量高得多最后喂给模型的已经是精炼过的短摘要prompt短模型排序和观察时也更加专注。4.4 简报渲染与本地持久化模型生成完简报后最后一步是把它写成Markdown文件。这里要做一层简单的后处理因为模型偶尔会在输出的开头或者结尾多出一些无关文字需要清洗掉。def clean_markdown_output(raw_text): 清洗模型输出剥离可能的前缀噪声 # 去掉开头可能的以下是...等前缀 cleaned re.sub(r^(以下是|根据要求|好的|好的这是).*\n, , raw_text) # 确保以二级标题开头 if not cleaned.startswith(## ): # 如果模型没有按格式输出尝试从第一个##截取 idx cleaned.find(## ) if idx ! -1: cleaned cleaned[idx:] return cleaned.strip() def save_digest(markdown_content, output_dirdigests): 保存简报为带日期的Markdown文件 os.makedirs(output_dir, exist_okTrue) today datetime.now().strftime(%Y-%m-%d) filepath os.path.join(output_dir, fnews_digest_{today}.md) header f 自动生成的新闻简报 | 日期{datetime.now().strftime(%Y-%m-%d %H:%M)}\n\n with open(filepath, w, encodingutf-8) as f: f.write(header) f.write(markdown_content) print(f[INFO] 简报已保存: {filepath}) return filepath每天生成的简报按日期归档方便后续查历史记录。如果你有邮件推送的习惯也可以在保存后把Markdown转成HTML文件内容用smtplib发到自己邮箱。这一步不是必须的但实测下来每天早上收到一封排版好的简报邮件比打开文件看要舒服得多。5. 实测记录模型表现与踩坑修复5.1 连续三天跑下来的实际数据系统连续跑了一段时间后我记录了一些关键指标。拿最近这三天的数据说话每天配置了6个RSS源每轮每个源取20条合计约120条原始内容。经过清洗去重后剩60条左右有效新闻模型对每条生成摘要再从中挑5条最重要的生成简报。单轮完整处理时间在80秒到140秒之间其中模型推理占了大头。逐条摘要60条新闻每条大约1到1.5秒合计60到90秒最后生成汇总简报一次推理约20秒。这个速度对于每天早上出报的使用场景来说绰绰有余完全不用考虑并发加速的问题。指标实际数值有效新闻条数清洗后55-65条/轮单条摘要耗时1-1.5秒单轮总耗时80-140秒摘要准确率人工抽检约85%简报格式合规率约95%显存占用4.5GB4bit量化摘要准确率85%这个数字我解释一下评判标准。抽检是指把模型生成的摘要和原文对照核心信息完整、没有事实错误就记为准确。剩下15%的不准确主要问题出在指令跟随偏差模型偶尔会把新闻里的背景信息当成核心信息来写或者摘要里混入了原文没有的推断。这不是毁灭性的缺陷但说明2B模型在处理复杂长文时的信息筛选能力依然和7B、13B模型有差距。5.2 高频问题排查温度、上下文与格式跑这三天遇到的问题集中在三个高频点每个都有明确的排查路径和修复方案。问题一摘要内容重复或复读。现象是模型连续几条摘要都是XX公司发布了XX产品该产品具有XX功能句式完全雷同等于什么都没说。排查后发现主因是temperature设高了。温度过高会让小模型的采样空间变大而2B模型的概率分布本身就不如大模型尖锐更容易陷入熟路复读。修复方式是全局把temperature从0.7降到0.3损失了一点点多样性但换来了稳定的输出。问题二模型输出语言混夹英文。明明我要求用中文摘要但部分专业术语它会自动切换成英文比如该模型采用了transformer架构使用GPU进行inference。中文环境的读者看到这种夹生表达非常不舒服。修复方式是在system prompt里加了一条专有名词首次出现时保留英文原名其余一律使用中文表述。实测加了这个约束后混合语言比例大幅下降。问题三简报格式偶尔被模型自由发挥。比如该输出Markdown的二级标题的时候它输出成了三级或者在今日观察里加了个表格破坏了整体排版。我的处理方式不是去改prompt因为改了很多次还是会偶发而是加一道后处理校验如果模型输出不包含## 今日要闻和## 今日观察这两个必需区块就判定生成失败重新调用一次。第二次调用时给它一个更严格的few-shot示例格式几乎必定恢复正常。5.3 用日志海洋倒查问题的完整链路有段时间简报质量忽高忽低我决定从日志里把每个环节的数据都翻出来看。这一步对排查问题太重要了。我在代码里给每个环节都加了时间戳和状态标记。抓到120条原始内容记录下每个源各多少条清洗去重后剩60条记录下被过滤掉的链接和原因模型摘要的60条记录记录每条耗时和输出长度最终简报生成后记录模型返回的原始内容和清洗后的内容。翻日志的时候发现一个有趣的现象那天简报质量差的根源并不在模型而在抓取环节。某个资讯源在当天临时改版RSS输出的正文全部变成了乱码。30条有效内容里有14条来自这个源实际可用的信息量骤降简报自然显得空洞。这个问题如果用云端API照样会遇到——数据源质量决定了模型输出的上限模型再强也变不出信息。这条经验我刻进了代码里给每个RSS源的单轮有效条数设一个阈值如果连续两轮某个源的输出量下降了50%以上就在简报末尾加一行提示检测到内容源异常。这样我不用天天看日志系统自己会告诉我谁出了状况。6. 再往前走一步从简报生成到知识沉淀6.1 引入RAG做话题追踪基础版简报跑通之后我开始琢磨更进一步的事能不能让简报系统不仅告诉我今天发生了什么还能告诉我这件事和上周那件事是不是同一件事的延续这就涉及RAG检索增强生成的思路了。我目前的做法是在简报生成之后把每天的简报内容向量化后存入本地向量数据库。当天的简报生成时会先去向量库里检索过去七天的历史简报找出语义相近的历史条目把它们作为上下文一并喂给模型让模型在今日观察里加入对比和延续判断。存储层我用的是chromadb同样完全本地运行。对MiniCPM5-2B生成的简报做向量化时我用的不是模型自带的embedding而是单独挂了一个轻量级的embedding模型比如bge-small-zh。这样做的原因是摘要模型和embedding模型是两种职责混用同一个模型效果会打折。import chromadb from chromadb.utils import embedding_functions # 初始化本地向量数据库 client chromadb.PersistentClient(path./chroma_store) embedding_fn embedding_functions.SentenceTransformerEmbeddingFunction( model_nameBAAI/bge-small-zh-v1.5 ) collection client.get_or_create_collection( namenews_digest_history, embedding_functionembedding_fn ) def store_digest(date_str, digest_markdown): 把每天的简报存入向量库用于后续检索 collection.add( documents[digest_markdown], ids[date_str], metadatas[{date: date_str}] ) def search_related_news(query, top_k3): 检索与当前查询最相关的历史简报 results collection.query( query_texts[query], n_resultstop_k ) return results[documents][0]引入RAG之后今日观察的生成质量明显提升了一个档次。以前模型只是孤立地总结今天的新闻现在它会说该产品与上周发布的XX产品形成直接竞争或者此消息延续了本月以来的XX趋势。这种跨时间的洞察力是单纯用单日数据训练出的简报不具备的。6.2 定时任务与多渠道触达最后一步是把整套系统变成全自动无人值守的定时任务。我用crontab实现了每四小时跑一轮抓取和摘要每天早上八点统一生成日报并推送。# crontab配置每4小时抓取一次每天早上8点生成日报 # 分 时 日 月 周 命令 0 */4 * * * cd /opt/news-digest /usr/bin/python3 main.py --mode fetch 0 8 * * * cd /opt/news-digest /usr/bin/python3 main.py --mode digest为什么抓取和生成日报要分开两个任务跑这是因为新闻源在一天不同时段的更新节奏不一样有些源早上更新集中有些源下午才有新内容。如果只在早上八点抓一次会漏掉前一晚的深夜更新。分开跑的好处是每四小时抓取一次的内容会先落到本地缓存早上八点生成日报时取的是过去24小时全部抓取的结果信息覆盖更完整。推送渠道我选择了邮件和本地文件双轨制。邮件用Python的smtplib发送Markdown渲染后的HTML本地文件则是前面代码里那个按日期归档的MD文件。之所以保留本地文件是因为它比邮件更原始直接看能方便排查问题同时也留了一份长期数据供RAG查询。这套方案还有一个容易被忽视的好处断电断网不丢数据。所有中间产物都在本机日报也生成本地文件即使推送渠道出了故障数据本身不会丢失。对于我这种什么都想自动化又什么都想掌控的人来说这是最踏实的架构。6.3 最后分享一个调优小技巧整个项目跑稳定之后我最大的感触是本地小模型项目的天花板不在模型本身而在你围绕模型搭的那套工程脚手架上。同样一个MiniCPM5-2B直接用和精心设计Prompt、合理拆分任务、加上后处理校验产出效果能差出一倍。小模型就像一位能力不错的实习生你交代得越细它完成得越好你指望它自己领会意图它就给你自由发挥。我的建议是拿到任何小模型先花时间把任务拆细把指令写明确把输出规范约束死再处理特殊情况的兜底——把人靠谱这件事前置到系统设计里而不是事后祈祷模型发挥稳定。这套系统的代码总量不超过五百行全部用Python标准库加feedparser、requests、chromadb这几个轻量依赖维护成本极低。如果看到这里你也想动手搞一套建议从一天的RSS源加十行代码的最小版本起步跑通之后再加模型再加定时再加RAG——一步一步来每一层都是稳的。
