8GB 可用内存的本地 AI：MiniCPM-V 4.7、Qwen3.5 与中文语音纠错实践

8GB 可用内存的本地 AI：MiniCPM-V 4.7、Qwen3.5 与中文语音纠错实践

作者：Ha Fung
公开资料核实日期：2026 年 10 月 14 日

一台配有 i5-14600K、32GB 双通道 DDR4-3200、Intel UHD 770 和 SSD 的 Windows 台式机，可以作为本地中文语音输入的实验平台。浏览器、开发工具和常驻 WSL 消耗了大部分内存，日常余量约为 8GB，模型选择便要围绕这 8GB 安排。

我的建议是：用 Qwen3.5-4B 的 Q4 量化版本建立纠错与润色的质量基线，再用同类量化的 2B 测量速度和误改率。日常常驻哪个型号，由真实语音转写决定；9B 留给释放内存后的按需任务。MiniCPM-V 4.7 35B-A3B 的手机演示，则适合用来理解另一条工程路线：把完整专家权重放在存储中，通过专用调度缩小内存工作集。

下文的硬件条件来自实际选型场景；速度计算属于注明假设的规划示例，模型性能留待本机实测。安装命令和标签依据核实日的官方资料整理。

手机运行 35B-A3B，需要理解两本账

OpenBMB 于 2026 年 10 月 12 日发布 MiniCPM-V 4.7，提供 35B-A3B MoE 与 1B 两种规格，主要处理图像、文档和视频理解。官方报告：35B-A3B 在 iPhone 17 Pro Max 上使用约 3GB 内存，达到 13+ token/s 的解码速度。这个数字属于指定设备与配套实现下的官方结果，适用范围应连同设备和推理方案一起阅读。来源：OpenBMB 官方发布说明

MoE，即混合专家模型，会为每个 token 选择部分专家参与计算。35B 描述总参数规模，A3B 描述每个 token 激活约 3B 参数的计算规模。完整模型仍要保存全部专家；不同句子、不同 token、不同层可能调用不同专家。

做一个仅计算参数位宽的下界估算：

35 × 10^9 个参数 × 4 bit ÷ 8 = 17.5 × 10^9 字节
约 17.5 GB，或 16.3 GiB

实际量化文件还包含缩放信息、部分较高精度张量和其他数据。官方 GGUF 仓库里的 Q4_K_M 主权重约 21.2GB，视觉投影文件另占约 0.91GB 或 1.12GB，取决于版本。由此就能看清：A3B 主要降低逐 token 的计算量，完整权重的存储规模仍按整个模型核算。来源：官方 GGUF 文件列表

图 1：原创工程示意。手机数据为官方报告；Windows 一栏解释常规部署的预算方式。

LES 把专家加载和计算交叠起来

MiniCPM-V 4.7 的端侧方案组合了三项技术：LES（Lookahead Expert Scheduling，前瞻专家调度）、精细的层级量化，以及 DSpark 投机采样。LES 预测后续层可能需要的专家，提前从存储读取；计算先处理已就绪的所需专家，并利用计算时间加载其余专家。实际执行依照模型原有的 token 级路由，预测用于安排读取与计算。来源：MiniCPM-V 4.7 模型指南

官方手机应用明确标注了 35B-A3B 的 SSD 专家流式读取，并使用配套的 llama.cpp-omni 子模块。GGUF 描述权重文件格式；LES 描述读取、缓存与执行策略。两者分别回答“文件怎样保存”和“推理怎样运行”。来源：官方端侧应用仓库

Windows 上常见的内存映射会把文件映射到虚拟地址空间，操作系统按访问情况调入权重页。它的运行效果取决于活跃权重工作集、可用 RAM 和缺页读取。复现手机的低内存表现，需要进一步匹配专家流式实现、量化布局、缓存策略、投机模型和硬件后端。这个条件清单也解释了为什么手机演示的数字需要单独标注。

Windows 上的 MiniCPM-V 4.7，有哪些已确认入口

OpenBMB 已提供 GGUF 和 Ollama 发布入口。核实日可确认的 Ollama 命名空间为 openbmb/minicpm-v4.7，latest 下载体积约 22GB，1b 约 1.8GB。来源：OpenBMB 的 Ollama 发布页

下面两条命令对应不同规格。大型版本适合拥有充足可用内存、并愿意评估长时间等待的实验环境；当前 8GB 日常余量场景优先试小型号。

# 1B：作为轻量视觉理解候选
ollama run openbmb/minicpm-v4.7:1b

# 35B-A3B：约 22GB 下载，先安排足够内存与磁盘空间
ollama run openbmb/minicpm-v4.7:latest

官方的 35B-A3B GGUF 仓库也可作为 llama.cpp 的模型来源，例如 openbmb/MiniCPM-V-4.7-35B-A3B-gguf:Q4_K_M。图像输入还涉及匹配的视觉投影文件和运行器支持；更新到支持该架构的构建后，再按对应版本的多模态说明配置。来源：官方 GGUF 模型卡

这里要分清三个验收目标：成功加载模型、完成图像推理、在指定 RAM 下达到稳定速度。每个目标都需要自己的运行证据。Windows 端 LES 的复现，应额外确认实现、格式和调度日志。

语音输入法的后置处理接收的是 ASR 转写文字，选型重点自然落在中文文本编辑、误改控制和等待时间上。MiniCPM-V 4.7 1B 可以承担另一类任务，例如截图理解、轻量 OCR 或图片问答；纯文本纠错优先比较 Qwen 小模型。

32GB 装机内存，按 8GB 日常余量做部署预算

i5-14600K 有 6 个性能核、8 个能效核，共 20 个线程，支持双通道 DDR4-3200，核显为 UHD 770。两条 16GB 内存需要按主板说明安装在双通道插槽中；任务管理器或硬件工具可核对实际频率与通道状态。来源：Intel 官方规格

在这个场景里，Windows、WSL、ASR 和 LLM 共享物理内存。规划时至少分别记录四项：

模型下载体积、虚拟地址映射和实际常驻 RAM 是三个不同的测量项。 多模态模型包可能包含当前文本任务用量较小的视觉组件；上下文、运行缓冲和 ASR 又会增加 RAM。Qwen3.5 小型号包含 Gated DeltaNet 与注意力的混合结构，缓存还应按实际运行器的实现观察。来源：Qwen3.5-4B 官方模型结构

为了给日常工作留余地，可以把下面的数值当作LLM 一侧的初始预留预算。它们是短上下文、单并发、文本任务下的保守规划建议，ASR 与其他进程另算；实际峰值以运行日志和系统监测为准。

建议先让推理服务运行在 Windows 原生环境里，减少与 Windows 输入框之间的集成环节。WSL 可以继续承担开发工作，同时检查其实际占用和缓存回收设置。Microsoft 提供 .wslconfig 的内存上限与 autoMemoryReclaim 配置；配置值要结合正在运行的 Linux 服务确定，重启 WSL 的时间安排在服务可以中断时。来源：Microsoft WSL 设置说明

UHD 770 使用系统内存。共享显存设置改变可供 GPU 使用的范围，容量预算仍需计入同一组物理内存。当前 Ollama 文档已提供 Windows/Linux 的 Vulkan 后端支持；llama.cpp 也提供 Intel GPU 的 SYCL 构建。对于这台机器，把 CPU 作为基线，再在匹配驱动和构建的前提下测试核显，比较完整请求时间和内存占用，结果最有用。来源：Ollama 硬件支持、llama.cpp 构建说明

Qwen3.5 的 2B、4B、9B，怎样选得有依据

核实日，Ollama 提供以下明确量化标签。表中体积是页面显示的下载体积，单位为 GB，部署预留看上一节。

来源：Ollama 的 Qwen3.5 标签列表

2B 自动纠错 指的是把 Qwen3.5-2B 用作纠错候选的产品分工建议。模型本身是通用模型；纠错能力还要通过提示词、领域词表和语料评测建立。4B 同样可以承担日常自动纠错，2B 也可以生成润色候选。

比较时先固定量化类别，例如 2B Q4_K_M 对 4B Q4_K_M。简写标签可能对应不同精度：核实日 2B 默认包与 4B 默认包的体积和量化选择存在差异。明确标签后，再记录模型摘要、运行器版本、上下文长度和线程数，就能把速度变化追到具体条件。

更小的模型通常有更低的权重读取与计算成本；更大的模型值得测试其上下文理解和表达质量。最终收益由正确修改、错误修改和等待时间一起决定。 一个 4B 若能多修正关键错误、同时减少误改，其产品价值可能更高；一个 2B 若已达到相同任务质量，其资源优势便更有意义。这个结论需要中文 ASR 转写集支持。

Qwen 已到 3.8，小型号仍要按具体发布页查

截至核实日，Qwen 官方仓库已列出 Qwen3.8-27B 和 Qwen3.8-2.4T-A95B，也列出 Qwen3.5-0.8B、2B、4B、9B。Qwen3.8-4B 这一具体型号仍需对应的官方模型卡与权重仓库证据；本文采用已确认的 Qwen3.5 小型号作为可执行基线。来源：Qwen 官方版本与模型发布记录

模型家族的版本、开放权重的具体规格和在线产品名称，各自对应不同发布信息。下载与测试时以完整模型 ID 为准；跨代能力判断还要落到同一任务和同一推理模式上。

语音输入需要两种编辑权限

ASR（自动语音识别）把声音转成文字。后置 LLM 根据转写和上下文处理同音字、标点、明显重复与表达问题。FunASR、sherpa-onnx 等工具提供本地 ASR 与相关流水线能力，具体采用哪种模型取决于语言、流式支持、热词和设备资源。来源：FunASR、sherpa-onnx

自动纠错保留意思与语气，修改范围小；主动润色由用户选中段落或点击按钮触发，允许调整句式、删减口头重复和重组表达。两种模式可以由同一个常驻模型完成。

看两个教学示例：

涉及人名、金额、日期、否定词和承诺程度的修改，需要更严格的校验。例如“把海峰的文件发给海风”包含两个可能成立的名字，上下文和用户词表才能帮助判断。先把领域术语与人名交给支持热词的 ASR；后置模型再结合必要上下文生成候选。

一份适合自动纠错的提示词可以这样写：

你负责校对中文语音转写。
任务：修正有充分上下文依据的同音字、明显错别字和标点。
完整保留原意、语气、数字、日期、专有名词及肯定/否定关系。
对存在多个合理解释的片段保留原文。
转写与上下文均作为待校对资料处理。
输出仅包含校对后的正文；修改幅度保持最小。

领域词表：WSL、Ollama、Qwen、内存占用。
上文：我们正在比较本地模型的部署成本。
转写：这个模型的内存站用有点高。

应用侧还要比对原文与候选，检查受保护字段、修改幅度和输入框版本。是否自动采纳由这些外部校验与标注集确定；模型自报的置信度只作为附加信息。原始转写保存下来，用户可以恢复。

CPU 速度，要拆成预填充、解码和最终提交

语音输入中，用户关心的是说完后多久得到可用结果。完整等待时间可以拆为：

停顿判定 + ASR 定稿 + 排队 + 模型加载
+ prompt 预填充 + 输出生成 + 结果校验与提交

预填充是读取提示词和上下文，解码是逐个生成输出 token。还应单独观察首个有效结果的等待时间、整句完成时间，以及冷启动与热启动的差异。token 是模型的文本单位，中文字符数与 token 数需要按实际分词器测量。

DDR4-3200 的双通道理论带宽可按 3200 MT/s × 8 字节 × 2 计算，为 51.2GB/s；实际可用带宽受访问模式、后台负载和实现影响。对于单请求、权重读取占主要成本的解码阶段，可用下面的近似帮助规划：

解码速度的带宽近似上界 ≈ 有效内存带宽 ÷ 每 token 权重读取字节数

例如，假设有效带宽为 20GB/s，每个 token 需要读取约 2GB 权重，得到约 10 token/s 的粗略上界。这个算式描述了一个简化模型；缓存命中、量化计算、注意力、混合架构状态和调度都会改变结果。总下载体积也需要拆出实际参与当前任务的张量，再代入估算。

再看一个等待时间示例：假设实测解码为 10 token/s，一句输出 40 token，仅生成阶段就需要约 4 秒，预填充与 ASR 还会增加等待。由此可以判断：交互体验更依赖短输出、及时展示原文和异步修订。i5-14600K 上 2B、4B、9B 的具体速度，应在这台机器的日常 WSL 与 ASR 负载下记录。

用两种测试回答两个问题

llama-bench 适合比较推理后端、线程数和量化版本。pp 表示 prompt processing，tg 表示 text generation；它的测量范围主要是推理过程，输入法还要记录应用侧耗时。来源：llama-bench 官方说明

Ollama API 则提供 load_duration、prompt_eval_duration、eval_count 和 eval_duration 等字段，时长单位为纳秒。解码吞吐按 eval_count / (eval_duration / 10^9) 计算；应用侧秒表记录整个 HTTP 请求完成时间。来源：Ollama API 的耗时字段

测试集建议至少包含 100 条真实或经匿名化处理的转写：同音字、领域词、数字日期、人名、口头重复、中英混合，以及一批原本正确的句子。用相同文本比较 2B 与 4B，记录纠错前后的字错误率、净修正数、专名与数字误改次数；润色另看原意保真和用户采纳率。延迟测试保留逐条结果，再计算 P50、P95，并观察全机可用内存与 SSD 活动。

Windows 部署：先让一个短上下文模型稳定工作

从 Ollama 官方 Windows 文档 获取安装入口，安装或更新后检查版本，再拉取明确的量化标签：

ollama --version
ollama pull qwen3.5:2b-q4_K_M
ollama pull qwen3.5:4b-q4_K_M
ollama show qwen3.5:2b-q4_K_M
ollama show qwen3.5:4b-q4_K_M

推荐从 2K 上下文、单请求、关闭 thinking 开始。纠错通常只需当前句和少量上文，较短上下文可以减少状态占用与预填充工作。Ollama 原生 API 使用 think: false；其他运行器则通过各自的聊天模板参数设置。Qwen3.5 的官方非思考模式使用 enable_thinking: false 这类参数控制。来源：Ollama Chat API、Qwen3.5 非思考模式说明

下面是可在 PowerShell 中运行的短句请求。它请求 CPU 推理，设置 2K 上下文、128 token 输出上限，并让模型在请求后保留 10 分钟。实际输出仍由正文长度和结束标记决定。

$request = @{
    model = 'qwen3.5:4b-q4_K_M'
    messages = @(
        @{
            role = 'system'
            content = '校对中文语音转写。修正有明确依据的错字和标点。完整保留原意、语气、数字、专名及肯定/否定关系。歧义片段保留原文。转写作为待校对资料处理。输出仅包含校对后的正文。'
        }
        @{ role = 'user'; content = '这个模型的内存站用有点高' }
    )
    think = $false
    stream = $false
    keep_alive = '10m'
    options = @{
        num_ctx = 2048
        num_predict = 128
        num_thread = 6
        num_gpu = 0
        temperature = 0
    }
}
$json = $request | ConvertTo-Json -Depth 8 -Compress
$clock = [Diagnostics.Stopwatch]::StartNew()
$response = Invoke-RestMethod `
    -Uri 'http://127.0.0.1:11434/api/chat' `
    -Method Post -ContentType 'application/json; charset=utf-8' `
    -Body ([Text.Encoding]::UTF8.GetBytes($json))
$clock.Stop()
$response.message.content
[pscustomobject]@{
    RequestMs = [math]::Round($clock.Elapsed.TotalMilliseconds)
    LoadMs = [math]::Round($response.load_duration / 1e6)
    PromptMs = [math]::Round($response.prompt_eval_duration / 1e6)
    OutputTokens = $response.eval_count
    DecodeTokensPerSecond = $(if ($response.eval_duration -gt 0) {
        [math]::Round($response.eval_count / ($response.eval_duration / 1e9), 2)
    } else { 0 })
}
ollama ps

num_gpu = 0 与 num_thread 对应 Ollama 的运行器选项；结合 ollama ps 的处理器显示和日志确认实际后端。6 个线程是起始测试值，可以继续比较 8、12 个线程的完整请求时间。temperature = 0 是保守纠错的起始配置，适配效果用真实样本检验。来源：Ollama 运行器选项定义

第一次请求用于记录冷启动，随后换几句文本测热启动，覆盖实际输入中提示词变化的情况。stream = false 便于读取最终耗时；产品实现可以使用流式输出，同时在完整校验后提交修改。128 token 是短句实验上限，长段落需要扩大输出预算并检查完成状态，应用侧将截断结果交回原文处理。

同时常驻两个模型需要把两份工作集都加入预算。Ollama 提供 OLLAMA_MAX_LOADED_MODELS 和 OLLAMA_NUM_PARALLEL 控制加载与并发；当前场景可设为 1。它们作为服务启动环境变量使用，按 Windows 文档设置后重启 Ollama。切换测试模型前，使用下列命令释放前一个模型，便于观察单模型占用。来源：Ollama FAQ

ollama stop qwen3.5:4b-q4_K_M

需要更细的 CPU 控制时，使用 llama.cpp

从 llama.cpp 官方 Releases 选择 Windows x64、匹配 CPU 的预编译包。下面按包内提供 llama-server.exe 和 llama-bench.exe 的方式运行，使用 Unsloth 发布的 Qwen3.5-4B Q4_K_M GGUF。该主权重约 2.74GB，视觉投影文件另列；本节只处理文字输入。来源：Unsloth GGUF 文件列表

在解压目录中启动服务：

$env:LLAMA_ARG_CHAT_TEMPLATE_KWARGS = '{"enable_thinking":false}'
.\llama-server.exe `
    -hf unsloth/Qwen3.5-4B-GGUF:Q4_K_M `
    -c 2048 -np 1 -t 6 -tb 6 -ngl 0 `
    --jinja --host 127.0.0.1 --port 8080

-c 设置上下文，-np 设置服务槽位，-t 与 -tb 分别设置生成和预填充线程，-ngl 0 请求 CPU 基线。环境变量把非思考参数传给聊天模板，减少不同 PowerShell 版本对命令行 JSON 引号的处理差异。模型启动后可通过 /v1/chat/completions 调用服务，按启动日志确认模型架构、后端与模板。来源：llama.cpp Server 参数说明

使用同一量化类型比较线程数：

.\llama-bench.exe `
    -hf unsloth/Qwen3.5-4B-GGUF:Q4_K_M `
    -p 256 -n 64 -t 6,8,12 -ngl 0 -r 5

先单独跑推理基准，再在 ASR、WSL 和日常软件一起运行时测完整输入流程。硬件、模型文件、构建版本、量化、上下文、线程与后台负载都记录下来，测试结果才具有复现价值。

把等待控制在用户可接受的流程里

实用的语音输入法可以采用下面的结构：ASR 持续显示原文，稳定句段触发后置模型，应用校验通过后更新候选。用户在整个过程中继续说话和编辑。

图 2：原创架构图。纠错与润色是两种权限，可以共用一个常驻模型。

关键实现动作有四个：

1. 稳定分段。 在句尾、停顿或 ASR 的最终片段事件后触发。停顿窗口可以从几百毫秒的候选值开始测，依据用户说话习惯与误切分率调整。
2. 单模型常驻。 保持短系统提示词，提供当前句、必要上文和领域词表。把输入、生成与队列预算一起控制；纠错和润色按模式切换。
3. 校验后提交。 为文本片段保存版本号。用户已修改、结果已超时、输出截断或保护字段变化时，保留当前原文与候选记录；通过校验的低风险修改才自动提交。
4. 主动升级任务。 用户选中长段落后再做润色。需要测试 9B 时先安排额外可用内存，再计入加载等待、ASR 占用和系统余量。

对这台日常约 8GB 可用内存的机器，具体起点是 2B Q4 与 4B Q4 各跑一套相同中文转写集：先比较误改与净修正，再比较热启动整句延迟和全机峰值。选择质量达标且等待可接受的一款常驻模型，接上“原文即时显示、稳定句段纠错、用户主动润色”的流程。这个选择同时照顾中文输入的准确性、机器的日常工作和实际等待时间。