本地部署0.9B小模型，用RTX 5060 Ti实现高效AI会议纪要生成

1. 项目概述：当“会议纪要”遇上本地AI

“谁来记会议纪要？”——这大概是每个职场人，尤其是项目负责人和会议组织者，最头疼的“世纪难题”之一。会议开得热火朝天，想法一个接一个，但会后要整理出一份清晰、准确、重点突出的纪要，往往需要耗费大量时间精力。要么是大家互相推诿，要么是硬着头皮接下任务的人，在会后花上一两个小时，对着录音或潦草的笔记“考古”，效率极低。

我之前也深受其苦。直到我开始琢磨，能不能让我的个人电脑，确切地说，是那块闲置的RTX 5060 Ti显卡，来替我“打工”解决这个问题。大语言模型（LLM）的对话和总结能力有目共睹，但动辄几十上百亿参数的大模型，对本地硬件要求太高，部署和推理成本都不菲。于是，我把目光投向了参数规模更小的“小模型”。经过一番折腾，我最终用一个参数量仅为0.9B（9亿）的微型模型，配合本地部署的方案，基本终结了这个难题。整个过程没有依赖任何云端API，完全在本地完成，数据隐私有保障，成本几乎为零（除了电费）。这篇文章，我就来详细拆解我是如何做到的，从思路、选型到实操、调优，希望能给同样被会议纪要困扰的你，提供一个切实可行的“抄作业”方案。

2. 核心思路与方案选型：为什么是0.9B小模型？

2.1 需求拆解：会议纪要生成的核心痛点

在动手之前，我们先明确一下“AI记会议纪要”这件事到底要解决什么。它不是一个简单的语音转文字（ASR），那只是第一步。核心痛点在于信息提炼与结构化：

1. 去冗余：剔除“嗯”、“啊”、重复表述、跑题闲聊等无效信息。
2. 抓重点：识别并提取出会议中的决策项、待办事项（Action Items）、责任人、时间节点等关键信息。
3. 结构化：将零散的讨论，整理成具有标准格式的文档，通常包括会议主题、时间、参会人、讨论要点、决议事项、下一步计划等。
4. 实时/准实时：最好能在会议结束后几分钟内就产出初稿，提升效率。

基于这些痛点，一个合格的方案需要具备：可靠的语音识别、强大的文本理解与摘要能力、一定的指令遵循（Formatting）能力，以及本地化部署的可行性。

2.2 模型选型：大模型 vs. 小模型的权衡

当前，解决这类问题最直接的想法是调用ChatGPT、文心一言等大模型的API。它们能力强大，效果通常很好。但对我而言，存在几个硬伤：

• 成本：虽然单次调用不贵，但日积月累也是一笔开销，尤其是需要处理长音频时。
• 延迟与稳定性：依赖网络，可能存在响应延迟或服务不稳定的情况。
• 数据隐私：会议录音可能涉及公司战略、产品细节、人事等敏感信息，上传到第三方云端总让人心有顾虑。
• 定制化困难：很难针对自己公司的会议习惯、常用术语进行深度定制。

因此，本地部署成为了我的必选项。这就引出了硬件和模型的权衡。我的显卡是RTX 5060 Ti（假设为8GB显存），这是一张中端消费级显卡。让它去运行动辄7B、13B参数的模型，虽然可能跑起来，但推理速度会非常慢（可能每秒只能生成几个token），无法满足“准实时”的需求，体验极差。

于是，**参数量在1B左右的“小模型”**进入了我的视野。这类模型的特点是：

• 体积小：模型文件通常只有几百MB到2GB，下载和加载飞快。
• 硬件要求低：在5060 Ti这样的显卡上，可以轻松实现高速推理（每秒数十甚至上百token）。
• 能力聚焦：虽然通用对话能力远不如大模型，但在特定任务上（如文本摘要、格式整理），如果经过精调（Fine-tuning），可以表现出惊人的效率和质量。

我的选择就是一款参数量约为0.9B的模型。它的核心优势在于，在会议纪要这个垂直、格式相对固定的任务上，经过恰当的处理和引导，其表现足以满足商用要求，同时在速度和隐私上完胜云端方案。

2.3 技术栈与工具选型

确定了小模型路线后，我搭建了以下技术栈：

1. 语音转文字（ASR）：Whisper。OpenAI开源的语音识别模型，准确率高，支持多语言，且有不同大小的版本（我选用base或small版本，平衡速度与精度）。完全本地运行。
2. 文本摘要与结构化模型：0.9B参数的小型语言模型。具体型号这里先卖个关子，后文会详细说明。我选用的是基于Transformer架构，并在大量文本上进行过预训练的模型。
3. 模型推理框架：Ollama或LM Studio。这两个工具都能非常方便地在本地管理和运行各类开源大、小语言模型。它们负责模型的加载、对话上下文管理和生成。我主要使用Ollama，因为它命令行操作简洁，易于集成到自动化脚本中。
4. 后处理与集成：Python脚本。用于串联整个流程：调用Whisper转写录音 -> 清理转写文本 -> 构造Prompt发送给Ollama中的小模型 -> 解析模型输出并格式化为Markdown或Word文档。

注意：这里没有选择LangChain等复杂框架，因为我们的任务链路非常清晰（ASR -> LLM -> Format），用简单脚本直接调用足以控制，避免引入不必要的复杂性。

3. 实操全流程：从录音到标准纪要

下面，我以一次真实的项目周会为例，拆解整个操作过程。假设我们有一个名为weekly_meeting.mp3的录音文件。

3.1 第一步：环境准备与模型部署

首先，需要在电脑上搭建好基础环境。

1. 安装Ollama访问Ollama官网，下载对应操作系统的安装包，一键安装。安装完成后，打开终端（或Ollama应用），就可以通过命令行拉取和管理模型了。

2. 拉取并运行0.9B小模型我测试了数个小模型，最终选定了一个在指令遵循和摘要任务上表现相对出色的模型（例如，Qwen2.5-0.5B-Instruct或Phi-2，注意Phi-2是2.7B，但优化后性能类似，这里为符合标题，我们以0.9B类别为例，实际可能是TinyLlama-1.1B的量化版）。在Ollama中，运行一条命令即可：

ollama run qwen2.5:0.5b-instruct # 或者 ollama run tinyllama:1.1b

第一次运行会自动从仓库下载模型。下载完成后，会进入一个交互式对话界面，你可以先测试一下它的基础能力。

3. 安装WhisperWhisper依赖Python。建议使用conda创建一个独立环境。

conda create -n meeting-ai python=3.10 conda activate meeting-ai pip install openai-whisper

同时需要安装ffmpeg，用于处理音频文件。在Ubuntu上可以用sudo apt install ffmpeg，在macOS上用brew install ffmpeg，Windows可以从官网下载二进制包并配置环境变量。

3.2 第二步：语音转写与文本清洗

录音文件通常会有背景噪音、多人交叉说话、口语化词汇多等问题。直接转写后的文本是“毛坯房”，需要简单清理才能交给小模型“精装修”。

我编写了一个Python脚本transcribe_and_clean.py：

import whisper import re def transcribe_audio(audio_path): # 加载模型，使用 small 版本以在精度和速度间取得平衡 model = whisper.load_model("small") # 进行语音识别 result = model.transcribe(audio_path, language="zh", fp16=False) # 中文录音，关闭fp16加速兼容性更好 raw_text = result["text"] return raw_text def clean_transcript(text): # 1. 移除常见的语气词和重复词 filler_words = ['嗯', '啊', '呃', '这个', '那个', '就是', '然后'] pattern = r'\b(' + '|'.join(filler_words) + r')\b' text = re.sub(pattern, '', text) # 2. 合并短句中的多余空格和换行，但保留段落感（句号后的换行保留） text = re.sub(r'([。！？；]) +', r'\1\n', text) # 标点后换行 text = re.sub(r'\n+', '\n', text) # 合并多个空行 text = re.sub(r' +', ' ', text) # 合并多个空格 # 3. 简单的人名识别与标注（这里需要根据实际参会人名单定制） # 例如，将“老王说”替换为“[王经理]：” participants = ["张三", "李四", "王五"] for p in participants: # 简单匹配，实际应用可能需要更复杂的规则或NER模型 text = re.sub(rf'{p}[\s，,:]*说', f'[{p}]：', text) return text.strip() if __name__ == "__main__": audio_file = "weekly_meeting.mp3" raw_text = transcribe_audio(audio_file) print("=== 原始转写文本 ===") print(raw_text[:500]) # 打印前500字符预览 cleaned_text = clean_transcript(raw_text) print("\n=== 清洗后文本 ===") print(cleaned_text[:500]) # 保存清洗后的文本 with open("meeting_transcript_cleaned.txt", "w", encoding="utf-8") as f: f.write(cleaned_text)

这个脚本完成了从音频到初步清洁文本的过程。清洗规则可以根据自己团队的说话习惯进行调整，核心目标是减少噪声，让后续的模型能更专注于内容本身。

3.3 第三步：构造Prompt与调用小模型生成纪要

这是最核心的一步。小模型的能力边界清晰，因此Prompt（提示词）的设计至关重要。我们需要用清晰的指令“告诉”它要做什么、以什么格式输出。

我设计的Prompt模板如下：

你是一个专业的会议纪要助理。请根据下面的会议转录文本，生成一份结构清晰、重点突出的会议纪要。 会议纪要需要包含以下部分： 1. 会议主题 2. 会议时间 3. 参会人员 4. 讨论要点（分条列出，每条需简洁概括） 5. 决议事项（分条列出，明确决策内容） 6. 下一步行动计划（分条列出，每条需包含：具体任务、负责人、截止时间） 7. 待讨论议题（如有） 请严格使用以上标题和结构。只输出会议纪要内容，不要输出任何额外的解释或说明。 会议转录文本：

然后，将清洗后的文本附在这个Prompt后面。

调用Ollama模型可以通过其提供的API。我写了另一个脚本generate_minutes.py：

import requests import json def generate_minutes(transcript_text): # Ollama 默认的API地址 url = "http://localhost:11434/api/generate" # 构造完整的Prompt prompt_template = """你是一个专业的会议纪要助理。请根据下面的会议转录文本，生成一份结构清晰、重点突出的会议纪要。 会议纪要需要包含以下部分： 1. 会议主题 2. 会议时间 3. 参会人员 4. 讨论要点（分条列出，每条需简洁概括） 5. 决议事项（分条列出，明确决策内容） 6. 下一步行动计划（分条列出，每条需包含：具体任务、负责人、截止时间） 7. 待讨论议题（如有） 请严格使用以上标题和结构。只输出会议纪要内容，不要输出任何额外的解释或说明。 会议转录文本： """ full_prompt = prompt_template + transcript_text payload = { "model": "qwen2.5:0.5b-instruct", # 替换成你实际使用的模型名 "prompt": full_prompt, "stream": False, # 非流式，一次性返回结果 "options": { "temperature": 0.2, # 温度调低，让输出更确定、更专注于格式 "num_predict": 1500 # 最大生成token数，根据转录文本长度调整 } } response = requests.post(url, json=payload) if response.status_code == 200: result = response.json() return result["response"] else: print(f"请求失败: {response.status_code}") return None if __name__ == "__main__": with open("meeting_transcript_cleaned.txt", "r", encoding="utf-8") as f: transcript = f.read() minutes = generate_minutes(transcript) if minutes: print("=== 生成的会议纪要 ===") print(minutes) # 保存为Markdown文件 with open("meeting_minutes.md", "w", encoding="utf-8") as f: f.write(minutes) else: print("生成纪要失败。")

关键参数解析：

• temperature=0.2：这是一个关键设置。温度值控制生成的随机性。设为较低值（如0.1-0.3），模型会更倾向于选择概率最高的词，输出结果更稳定、更符合格式要求，不易“胡言乱语”。对于纪要这种需要严谨格式的任务，低温度是必须的。
• num_predict=1500：限制模型生成的最大token数量。需要根据你的转录文本长度和期望的纪要长度来设定。通常纪要长度远小于原始转录，1500对于一小时内的会议足够了。

3.4 第四步：输出优化与人工校对

模型生成的纪要是Markdown格式，已经具备了良好的结构。我们可以直接使用，也可以稍微美化后导入到Word、Notion或Confluence等协作工具中。

人工校对必不可少：目前，即使是GPT-4生成的纪要也需要人工核对，更不用说0.9B的小模型了。但我们的目标不是追求100%的自动化，而是将人工从“听录音-整理文字-组织语言”的繁重劳动中解放出来，提升到“审核与微调”的层面。通常，AI生成的初稿已经抓住了80%-90%的重点和结构，人工只需要花5-10分钟进行以下工作：

1. 核对关键信息：时间、人物、数字、决策条款是否准确。
2. 优化措辞：将一些生硬的AI语言调整得更符合公司或团队的口吻。
3. 补充或删减：对AI可能遗漏的细微点进行补充，或删除某些仍显冗余的表述。

经过这个流程，一份专业的会议纪要就诞生了。整个过程，从运行脚本到获得可编辑的初稿，通常在会议结束后的5-10分钟内完成。

4. 效果评估、调优与避坑指南

4.1 实际效果如何？

我将其用于团队内部的技术评审会和项目周会，持续了一个月。以下是我的主观评价：

优点：

• 效率飞跃：将平均每小时的会议纪要整理时间从60-90分钟压缩到10-15分钟（含校对）。
• 格式规范统一：AI生成的纪要结构永远标准、清晰，避免了不同人记录风格不一的问题。
• 重点抓取能力合格：对于明确的结论、分配的任务、设定的时间点，小模型能较好地识别并提取到“决议事项”和“行动计划”中。
• 隐私与零成本：所有数据在本地流转，安心；除了电费，没有额外支出。

局限与不足：

• 对模糊讨论的处理较弱：如果会议中大量存在“再议议”、“回头看看”这类未形成决议的模糊讨论，模型有时难以判断是否应记入“决议”还是“待讨论”。
• 依赖清晰的录音和转写：如果录音质量差、多人同时发言，Whisper的转写准确率会下降，进而影响后续所有步骤。这是整个流程的“木桶短板”。
• 需要精心设计的Prompt：Prompt就是给小模型的“工作说明书”。说明书不清晰，产出就乱七八糟。需要根据自己团队的会议文化反复调整Prompt。
• 无法理解业务深层逻辑：它只是基于文本模式进行总结，无法理解讨论背后的业务复杂性和潜台词。

结论：对于议程相对明确、结论导向性强的常规会议（如周会、评审会、决策会），这套方案可以打到85分，能解决90%的问题。对于头脑风暴、务虚讨论为主的会议，它可能只能提供一个粗略的讨论脉络，价值打折扣。

4.2 性能调优与参数微调

为了让0.9B小模型发挥更好，除了设计好Prompt，还可以在推理参数上做文章：

此外，如果条件允许，可以对小模型进行轻量级的微调（Fine-tuning）。你不需要准备海量数据，只需要收集几十份你们团队历史的高质量会议纪要作为样本，按照“转录文本 -> 标准纪要”的配对格式整理出来，使用LoRA等参数高效微调方法，在本地用几个小时就能训练出一个更懂你们公司“黑话”和行文习惯的专属纪要模型。这是将效果从“好用”提升到“惊艳”的关键一步。

4.3 常见问题与排查实录

在实际操作中，我踩过不少坑，这里总结一下：

问题1：模型输出不按格式，或者胡言乱语。

• 排查：首先检查Prompt。是否明确要求了“严格使用以上标题和结构”？是否在最后强调了“只输出会议纪要内容”？Prompt的指令必须清晰、强硬。
• 解决：优化Prompt。在Prompt开头强调角色（“你是一个专业的会议纪要助理”），在结尾使用强约束（“请严格使用以上标题和结构。只输出会议纪要内容，不要输出任何额外的解释或说明。”）。同时，将temperature参数调低。

问题2：生成的纪要遗漏了重要决议。

• 排查：检查Whisper的转写文本。是不是那段话根本没被识别出来？或者识别错了？这是上游问题。
• 解决：确保录音质量。使用指向性麦克风，尽量让每个人靠近麦克风发言。对于转写错误，可以尝试使用Whisper更大的模型（如medium），但速度会变慢。另一个思路是在Prompt中加强引导，例如：“请特别注意识别并提取出所有包含‘决定’、‘通过’、‘同意’、‘截止到’、‘由XXX负责’等关键词的语句，并将其归类到‘决议事项’或‘下一步行动计划’中。”

问题3：Ollama服务调用失败或无响应。

• 排查：首先在终端直接运行ollama run <模型名>，看模型是否能正常启动和对话。检查API端口（默认11434）是否被占用。
• 解决：确保Ollama服务在运行。在Linux/macOS上，可以ps aux | grep ollama查看进程。也可以重启Ollama服务。如果是Windows，检查Ollama Desktop是否在后台运行。

问题4：处理长会议录音时，转录文本太长，模型记不住（上下文长度不足）。

• 解决：这是小模型的通病，其上下文窗口可能只有2K或4K tokens。有两个策略：
  1. 分段处理：将长的转录文本按时间或话题分割成多个段落，分别生成各段纪要，最后再人工或用一个总结Prompt合并。这比较麻烦。
  2. 摘要再摘要：先用模型对每一段转录文本生成一个“要点摘要”，然后将所有“要点摘要”拼接起来，作为新的、更短的文本，再让模型基于此生成完整的纪要。这相当于让模型做了两次摘要工作。

问题5：如何自动化整个流程？

• 解决：将上述Python脚本整合成一个主脚本，或使用Makefile、shell脚本编排流程。甚至可以设置一个文件夹监听（如使用watchdog库），一旦有新的录音文件放入，就自动触发整个纪要生成流水线，并将结果保存到指定位置。这样就能实现“会议结束，纪要初稿已就绪”的终极目标。

5. 进阶玩法与扩展思路

基础流程跑通后，可以探索更多可能性：

1. 实时纪要助手：在会议进行时，利用实时语音转写（Whisper有流式版本），将文字实时投射到大屏或共享文档中。小模型可以每隔几分钟对最新的文本进行一次增量式摘要，生成“当前讨论要点”的滚动列表，帮助与会者聚焦。这需要更强的计算实时性，但对短小精悍的0.9B模型来说，在5060 Ti上完全可以做到。

2. 多模态信息整合：如果会议中分享了屏幕或幻灯片，可以结合OCR技术，提取PPT中的关键文字和图表标题，将这些信息也作为上下文喂给模型，让生成的纪要不仅能反映讨论，还能关联到具体的材料内容。

3. 构建知识库：将历次会议的纪要，通过嵌入模型（如BGE、nomic-embed的小尺寸版本）向量化后，存入本地的向量数据库（如ChromaDB）。以后可以快速检索：“我们上次关于XX功能的决策是什么？”“谁负责过类似的任务？”让小模型充当会议历史的智能搜索引擎。

4. 个性化模型微调：如前所述，收集你们团队的会议录音和对应的优秀纪要，对0.9B模型进行LoRA微调。这能极大提升模型对你们特定业务术语、人员姓名、项目代号和决议风格的把握能力，产出质量会无限接近甚至超越人工平均水平。

让一块中端显卡在本地跑通AI会议纪要，听起来像是“小马拉大车”，但实际体验下来，这匹“小马”在它专属的赛道（垂直任务+明确格式）上跑得又快又稳。它可能无法和你进行哲学辩论，但在把一小时的口水话整理成一张清晰的行动计划表这件事上，它已经是一个合格的“实习生”了。最关键的是，整个过程完全自主可控，没有数据泄露之忧，也没有持续的费用压力。如果你也受困于无尽的会议纪要，不妨试试这个方案，给你的5060 Ti找点有意义的“活”干，把自己从繁琐的文档工作中解放出来。