笔记本和普通服务器上，可以部署哪些小型开源模型？

最近看到小米开源了 Xiaomi-OCR-0，只有 0.8B 参数，却能做文档解析、文字识别和文档问答。这让我想顺手整理一下：如果只想在自己的笔记本、台式机或者一台普通服务器上跑 AI，现在有哪些值得关注的小模型？

除了聊天，扫描件识别、录音转写、资料搜索也都有小模型可选。有些不到 1B 参数，适合围绕一个具体功能搭建本地工具。下面按用途整理，模型名都附上官方链接。

本地 AI 应用主题配图，由 AI 生成，非实际运行截图。

本文依据截至 2026 年 10 月 31 日的官方资料整理，讨论的是下载权重后在自己的机器上运行推理，尚未逐一实测。这一篇先把各模型的用途和差异讲清楚，后面再逐个下载安装，记录真实的配置、速度、效果和遇到的问题。

通用助手：先从一个小聊天模型开始

如果想做本地聊天、摘要、信息提取，或者对图片提问，可以先关注下面几组模型。

Qwen3.5-4B：一个模型同时处理文字和图片

Qwen3.5-4B 是带视觉编码器的通用模型。除了文字聊天，还可以输入截图或文档图片，让它解释页面内容、提取字段，或者结合图片回答问题。对于希望给现有工具增加问答入口的人，这种通用性意味着可以先围绕一个模型接文字和图片两类任务。官方模型卡

例如，给它一张软件报错截图，问题可以是“错误信息是什么，下一步该检查什么”；换成一段发布日志，又可以让它整理影响范围。这些是适合拿来验证的应用方向，不代表小模型已经能稳定完成所有步骤。

它还有一个会影响体验的设置：官方示例默认启用思考模式，也提供直接回答的方式。做简单分类或摘要时，值得比较两种模式的延迟和输出；只记每秒生成多少 token，可能忽略了开始得到答案前的等待时间。

Qwen3.5-9B：用来判断更大的模型是否值得

9B 与 4B 都支持文字和图像，适合放在同一组任务里比较。官方模型卡列出了两者的评测结果，但对个人部署而言，更实际的问题是：更大的模型是否减少了自己任务里的错误，增加的内存和等待时间能否接受。官方模型卡

比如字段提取可以检查 JSON 是否符合格式、缺失字段是否乱填；长文摘要可以检查数字和前提是否保留；看图任务可以检查模型是否遗漏小字。比较时要固定提示词、量化精度和思考模式，否则很难分清差异来自模型规模还是运行设置。

两者的官方上下文长度都是 262,144 token，但这是模型支持的长度，不是笔记本上的免费容量。输入变长后，处理时间和运行占用也要一起记录。单纯因为模型支持长上下文，就一次塞入整本资料，并不是好的初次试用方式。

Ministral 3 3B：适合考察结构化输出和工具接入

Ministral 3 3B 包含约 3.4B 的语言模型和 0.4B 的视觉编码器。这里列出的是经过指令训练的 Instruct FP8 版本；同一家族还有 Base 和 Reasoning 版本，下载时要辨认完整名称。官方给出的部署参考是该 FP8 版本可放入 8GB 显存。模型说明

它支持 JSON 输出和函数调用，因此除了聊天，也可以作为小工具中的任务处理模块：从邮件中提取日期与事项，或根据用户问题生成一次查询工具的参数。这里的“工具调用”是模型提出调用请求，真正执行操作的仍然是应用程序。

后续试用时，比“回答像不像人”更值得看的是：参数是否填对、缺少信息时会不会猜测、返回结果能否持续被程序解析。这些会直接影响它能否接进一个长期使用的工具。

Gemma 4 E2B / E4B：面向端侧，但型号不是总内存

Gemma 4 的 E2B、E4B 面向端侧场景，支持文字、图像和原生音频输入。与只做文字的模型相比，可以进一步考察截图问答或音频理解；不过模型支持某种输入，并不代表所选桌面客户端已经开放了对应能力。官方概览

E 表示有效参数规模。这两个版本使用逐层嵌入（PLE），其中的嵌入表也需要存储空间，因此不能直接按“E2B 就是总共 2B 参数”估算文件大小。选择时要对应具体量化文件，桌面版本和移动端优化版本也不能混用容量数字。

如果后续拿它与 Qwen 对比，除了中文回答质量，还可以记录启用视觉、音频前后的加载与运行变化。多模态是否真的方便，最终取决于模型、运行时和输入接口能否配合。

编程助手：30B MoE 是进阶选项

如果目标是修改代码、生成程序，或者接入编程 Agent，可以关注 Qwen3-Coder-30B-A3B-Instruct。

它的总参数约 30.5B，每次计算激活约 3.3B，是 MoE（混合专家）模型。这个设计减少了每次计算需要用到的参数，但不等于部署时只需要装下一个 3B 模型，其他专家的权重仍然要有地方存放。

它属于这份清单里的进阶选项，资源需求明显高于前面的轻量模型。按总参数粗算，纯 4-bit 权重约为 15.25GB，实际量化文件和运行占用还会更大。是否装得下，应结合具体量化包和运行设置判断，不能只看“A3B”。

它的定位也比“聊天时会写代码”更进一步：官方提供编程 Agent 和工具调用的接入说明。一个实际流程可以是读取文件、生成修改、运行检查，再根据错误继续调整；模型只是其中负责判断和生成的一部分，工具、上下文管理与测试仍由外部程序承担。模型与接入说明

后续测试适合从一个范围明确的代码修改开始，记录修改是否正确、是否碰了无关文件、测试是否通过。仅让它生成一个排序算法，看不出它处理现有项目时的表现。

OCR：不到 1B 的模型也能承担实用功能

如果需求是把扫描件转成文字，或从 PDF 页面中提取表格，下面三个模型更对题。它们都不足 1B 参数。

Xiaomi-OCR-0：从页面内容到结构化结果

Xiaomi-OCR-0 从 Qwen3.5-0.8B 出发训练，围绕文档解析、关键信息提取和文档问答做了专门优化。它不只是把图片变成一行行文字：官方流程可以把页面整理为 Markdown，处理表格与 LaTeX 公式，也可以按要求提取 JSON 字段，或回答关于文档内容的问题。官方项目

这几种输出对应不同需求。归档一篇扫描文章，需要尽量保留阅读顺序；提取一张单据，则可能只需要日期、编号和金额。后者还要检查字段对应关系，不能因为识出了数字就认为提取成功。

官方同时提供整页与区域解析。规则印刷文档可以先检测区域再分别识别；手写、古籍或不规则页面则可能因切分丢失上下文。后续实测值得把同一页放进两种流程，观察表格、脚注和多栏文字是否被正确拼回。

本地部署有浏览器 Demo 和推理服务接入方式；其中 Ollama 路线目前标为实验性支持，社区 BF16 包含文字模型和视觉投影器，下载量约 1.8GB。

使用 Xiaomi-OCR-0 时，建议沿用官方 Demo 的图片预处理、提示词和解码设置。区域解析还涉及额外的版面检测依赖，所以下载量不能直接当作整个 OCR 服务的运行占用。

PaddleOCR-VL-1.6：适合关注整份文档的还原

PaddleOCR-VL-1.6 的视觉语言模型约为 0.9B，覆盖文字、表格、公式、图表和印章等内容。官方介绍中特别提到对表格、中文古籍、生僻字和印章等场景的改进；这些是后续可选择的测试材料，并不意味着每一类文档都会获得同样效果。官方模型卡

它值得关注的还有配套解析流程。官方 PaddleOCR 示例提供 JSON、Markdown 导出，因而可以考察从页面输入到结构化文件输出的整条链路，而不只是一张裁剪图片上的识字结果。需要区分 0.9B 模型本身和完整流水线，版面处理及配套组件也会影响部署成本。

测试复杂表格时，可以先看合并单元格和行列关系，再核对数字。一个看上去整齐的 Markdown 表格，也可能把金额放到错误项目下；这种错误比少识一个标点更影响后续数据处理。

GLM-OCR：版面分析之后，再并行识别区域

GLM-OCR 由视觉编码器、跨模态连接部分和语言解码器组成，整体约 0.9B。官方完整流程结合 PP-DocLayoutV3，先做版面分析，再对区域进行并行识别。这样的设计提醒我们，最终结果既受识别模型影响，也受页面切分影响。官方模型卡

例如双栏文章被切成哪些区域、页眉是否混入正文、一个表格是否被拆开，都会改变最终输出。若要比较 GLM-OCR 与另外两个模型，应该区分“同一裁剪区域的识别效果”和“完整 PDF 的解析效果”，否则很容易把流程差异当成模型差异。

官方还给出了结构化信息提取的提示格式，要求输出遵循指定 JSON 结构。对接程序时应同时检查 JSON 能否解析、字段是否齐全以及数值是否来自正确位置。

如果要处理年报、合同或扫描 PDF，可以拿同一批文件比较这三个模型。除了看识字率，还应该检查表格的行列关系、阅读顺序、数字和单位、跨页内容，以及有没有漏掉小字。模型公布的综合分数，不能代替业务样本验证。

语音与检索：给工具增加输入、输出和搜索能力

不一定要把所有事情都交给一个聊天模型。语音输入、朗读和搜索，都有专门的小模型。

Qwen3-ASR-0.6B：语音输入与录音转写

Qwen3-ASR 系列有 0.6B 和 1.7B 两个版本，这里关注较小的一个。官方说明覆盖 30 种语言和 22 种中文方言，并提供流式与离线推理工具。离线转写适合处理已有录音，流式输入则关系到能否边说边出现文字。官方模型卡

对个人工具来说，可以先用它把语音转成文字，再把文字交给搜索或聊天模型。转写、摘要和执行指令是三个不同环节，拆开后也容易定位错误究竟出在哪一步。

后续实测可以准备普通话、夹杂英文技术词、带背景噪声的几段录音，分别检查术语、数字和长句。若要做字幕，还要单独关注时间戳；官方另有 ForcedAligner 配套方案，不能默认基础转写输出就带有满足字幕要求的对齐结果。

Qwen3-TTS-0.6B-CustomVoice：从文字到可听的回答

表中这个完整型号是 Qwen3-TTS-12Hz-0.6B-CustomVoice，提供 9 种预设音色，支持包括中文在内的 10 种语言。它适合接在文本输出之后，用于朗读通知、文章或语音助手的回答。这里介绍的是预设音色版本，不应把它理解成任意声音克隆模型。官方模型卡

短句试听容易让人只注意音色，真正用于工具时，还要看连续朗读是否自然。日期、金额、英文缩写、多音字以及句间停顿，都可以作为测试材料；长文章则要观察分段拼接后有没有突兀变化。

部署体验还涉及生成第一段声音要等多久、能否持续播放，以及能否与 ASR 或聊天模型共享机器资源。这些需要在实际运行时测量，不能直接拿官方服务场景的低延迟数字当作笔记本表现。

Qwen3-Embedding-0.6B：先把自己的资料搜出来

Embedding 模型则很适合用在本地资料库：先把文档转换成向量，再根据问题找相关段落。它负责“找资料”，聊天模型负责“根据资料组织答案”。如果只是想给自己的笔记和文档加一个语义搜索入口，甚至可以先不接聊天模型。

Qwen3-Embedding-0.6B 支持多语言及代码检索，最大输入长度为 32K token，输出向量最高 1024 维，也支持更小维度和任务指令。向量维度会影响索引的存储与查询成本；较长输入能力则不意味着应该把整本资料压成一个向量。官方模型卡

以开发笔记为例，用户搜“连接池耗尽怎么办”，原文可能写的是数据库连接超时。语义检索要解决的就是词面不完全一致时的查找问题。但能否找对，还取决于文档如何分段、查询指令和索引设置。后续测试应先看相关段落有没有进入前几条结果，再接聊天模型，避免把检索错误误判为回答模型的问题。

EmbeddingGemma：更小的端侧检索候选

这里指的是 google/embeddinggemma-300m，约 308M 参数的文本嵌入模型。它支持多语言，最大输入为 2048 token，默认输出 768 维向量，也可使用 512、256、128 维。与前面的 Qwen 相比，它提供了另一组模型规模、输入长度和向量维度的取舍。模型卡

2048 token 的限制会更直接地影响资料分段。长笔记需要拆开，同时保留标题与上下文，不能简单截掉后半篇。试用时可以用同一套文档和问题，对比两种模型的检索命中、索引大小和 CPU 处理时间；参数更少不自动等于更适合中文资料。

下载还需要留意两点：Hugging Face 页面要求接受相应使用条款；官方示例注明激活不支持 float16，需按硬件使用 float32 或 bfloat16。这类具体条件比笼统说“轻量、可本地运行”更影响能否顺利装起来。

没有 GPU 的普通服务器，也可以从 CPU 支持的向量推理方案入手，按批次处理文档。它不要求像聊天那样连续生成一长段回答，但批量处理速度仍取决于机器和输入长度。

公开评测：哪些成绩可以放在一起比较

性能有两层含义：一层是任务做得对不对，另一层是本机上跑得快不快、占多少资源。下面补充的是前一层的公开成绩，核对日期为 2026 年 10 月 31 日。主要采用模型团队的评测资料，属于公开报告摘录，不是本文复测，也不是实时全球排名。量化版和不同推理设置的结果需要另外验证。

通用模型：先看同一团队、同一张表里的差异

Qwen 官方模型卡同时给出了 4B 和 9B 的成绩，下面几项均为越高越好：MMLU-Pro 看综合知识与推理，C-Eval 关注中文知识，IFEval 检查指令遵循，LiveCodeBench v6 是代码题评测。Qwen 官方评测表

在这四项里，9B 都领先；代码题这一项的分差更明显。不过代码题得分不等于修改现有项目的成功率，后者还需要工具与工程任务验证。

Gemma 官方也提供 E4B 与 E2B 的对照。下面保留其指令微调模型的三个项目，数值按原表百分比展示。Gemma 4 官方模型卡

这组数据可以帮助理解 E4B 相对 E2B 的能力差异。它与上一张表来自不同团队，提示词、思考预算和评测配置没有在本文统一，因此不把两张表拼成跨系列名次。

Ministral 的 Instruct 官方表中，3B 版本的 WildBench 为 56.8，MM MTBench 为 7.83；这两个指标也不等同于上面的知识或代码测试。它的 Reasoning、Base 成绩另有表格，不能用来替代本文介绍的 Instruct 版本。Ministral 官方评测

编程模型还可以查 SWE-bench 官方榜单。它评测真实仓库问题，成绩对应模型与 Agent 执行流程的组合。比较 Qwen3-Coder 时，要同时看 Agent、允许的交互次数和测试集，不能只摘一个百分比与 LiveCodeBench 混排。

OCR：三个候选在同一对比表中的位置

小米官方仓库给出了包含三者的文档解析对比。下面只摘取本文介绍的模型，并按 OmniDocBench v1.6 分数排序；“顺序”只限这三个候选。Real5 和 Wild 分别沿用原表的 Real5-OmniDocBench、Wild-OmniDocBench 指标，三列都是 Overall，越高越好。小米官方对比表

这张表里小米在三个项目上都领先，但它是小米团队发布的对比，不能当作独立第三方重测；仓库也注明小米的这些成绩采用两阶段解析流程。小米与 Paddle 在 OmniDocBench v1.6 上相差 0.50 分，是否影响自己的扫描件，需要看具体页面。不同版本的 OmniDocBench 或不同统计指标不能直接混用。

检索：综合分和资源代价一起看

EmbeddingGemma 技术报告的 Table 5 同时收录了本文两个检索候选。下面摘取任务平均分（Mean Task），均为越高越好；是报告中的历史快照，不代表今天的榜单名次。多语言一列中 Qwen 为 64.34，和 Qwen 自家模型卡的 64.33 略有差异，这里统一采用同一张来源表。EmbeddingGemma 技术报告 Table 5

这两项综合分是 Qwen 更高，但没有包含“索引是否更小、CPU 是否更快”的答案。EmbeddingGemma 的官方模型卡还给出量化对照：768 维 Q4_0 的多语言平均分为 60.62，全精度为 61.15。它展示了特定量化方案的取舍，不表示所有模型量化后都只损失这么多。量化评测来源

跟进榜单时可以看 MTEB 官方入口，注意区分 Mean Task、Mean Type 和 Borda 排名。综合分领先，也不保证在自己的中文笔记或专业术语上命中更好。

语音识别：错误率越低越好，语言和数据集要分开

Qwen3-ASR 技术报告 Table 3 提供了中文测试集对比。下表摘取中文字符错误率 CER，单位为百分比；Whisper-large-v3 是报告中的参照模型，其数字来自 Qwen 团队运行测试，不是本文测得。Qwen3-ASR 报告与指标说明

这三项里 1.7B 的错误率更低，0.6B 也优于表中的 Whisper 结果；这只说明所列中文测试集，不能据此宣布所有语言的总排名。英文通常用词错误率 WER，也不能直接与这里的 CER 求平均。另可通过 Open ASR Leaderboard 跟进公开结果，但要核对语言范围和评测设置。

语音合成：内容读对与听起来好听是两回事

Qwen3-TTS 报告 Table 9 有 12Hz CustomVoice 的对比，但采用的是特定目标说话人 Aiden Voice 的微调评测。下表保留报告标为 WER 的内容一致性错误率，越低越好；它不是下载后任意预设音色的通用排名。Qwen3-TTS 报告 Table 9

这类指标看生成内容是否与文本一致，不能直接代表自然度、音色偏好和长文听感。因此后续试用仍要保留试听片段，也要单独记录首段音频延迟和连续播放情况。

硬件怎么估算：显存、内存和上下文要一起看

判断一台机器能否运行某个模型，先看所选文件的大小和格式，再看推理框架支持哪些设备。

单看权重，粗略计算是：参数量 × 每个参数的存储位数 ÷ 8。例如 4B 参数在纯 4-bit 存储下约为 2GB，9B 约为 4.5GB。这里用的是十进制 GB，只计算权重的理论存储量；实际量化文件还有额外数据，运行时还需要缓存、计算缓冲区和框架本身的空间。

所以，“模型文件只有几 GB”不能直接推出“几 GB 显存就够了”。上下文越长、并发越多、图片越大，占用通常越高。Apple Silicon 使用统一内存，还要给系统和其他应用留空间，也不能把整机内存全部算给模型。

像 Ministral 官方给出的“FP8 可放入 8GB 显存”，可以作为该版本的部署参考，不能推广到所有同参数模型。准备下载前，最好确认具体量化包、运行框架、上下文设置；跑起来后，再看生成速度是否能接受。本文没有实测数据，因此不按显存容量给出通用的硬件购买建议。

从哪里开始部署

想先体验聊天，可以从 Ollama、LM Studio 这类工具入手；希望自己控制量化文件、CPU 推理或 CPU/GPU 混合加载，可以关注 llama.cpp。Qwen3.5 的官方模型卡也提供了量化版本入口。

如果要在服务器上提供接口，再按模型官方说明选择 vLLM、SGLang 或专用推理包。新模型的架构支持往往有版本要求，安装了框架也要确认版本是否支持当前模型。OCR、ASR 和 TTS 尤其应该先沿用各自的官方示例。

许可证与资料边界

本文列出的 Qwen3.5、Ministral 3、PaddleOCR-VL-1.6 等模型采用 Apache 2.0，GLM-OCR 的模型卡标注为 MIT。用于产品时，还需分别检查所选权重、配套代码和依赖的许可证。

后续会把这些模型逐个下载安装，单独记录使用过程。每篇至少写清运行环境、模型与量化版本、安装中遇到的问题、资源占用，以及固定样本下的输出结果。OCR 留原图和解析结果，语音留测试片段，检索留问题与命中段落，编程则保留修改和检查结果。这样再回到这份导览时，就能把“官方提供什么”与“实际用起来怎样”对应起来。