13 Token/s 值得欢呼吗：端侧多模态的"能跑"与"好用"之间还隔着什么【免费下载链接】MiniCPM-V-4.7-35B-A3BMiniCPM-V 4.7 是 MiniCPM-V 系列的最新模型，提供 35B-A3B 变体，其中 35B-A3B 是 MiniCPM-V 系列中的首个 MoE（混合专家）模型。它在家族现有的单图、多图和视频理解能力基础上，结合了更强的基础能力、高效的视觉编码以及端侧推理特性。项目地址: https://ai.gitcode.com/OpenBMB/MiniCPM-V-4.7-35B-A3B面壁智能的 MiniCPM-V 4.7 35B-A3B 发布后，社区里流传最广的一句话是："首个开源、无损运行的端侧 MoE 模型，在 iPhone 17 Pro Max 上实现 13+ Token/s 的生成速度，仅需 3GB 内存。"总参数 350 亿、单 token 只激活 30 亿的 MoE 结构，能在手机里不降能力地流畅推理，这确实是端侧多模态发展史上的一个节点。但 13 Token/s 到底意味着什么？把"能跑"当成"好用"，中间还隔着多少东西？本文从真实交互体感、内存工程的代价、功耗与生态短板三个维度拆解，最后给"可用"画一条可检验的线。一、先别急着欢呼：13 Token/s 的真实体感是什么把 13 Token/s 换算成人能感知的速度：MiniCPM-V 4.7 的语言底座采用 Qwen 系列 tokenizer（tokenizer_config.json，tokenizer_class: Qwen2Tokenizer，词表 248144），中文文本平均每个 token 对应 0.7~1.5 个汉字。取中间值粗算，13 Token/s ≈ 10~13 汉字/秒 ≈ 每分钟 600~780 字。而真人对话的语速大约是每分钟 200~300 字。也就是说，一旦开始流式输出，模型打字的速度其实是"超过人说话"的——只看 tokens/s 这个数，它并不慢，甚至快于多数云端聊天产品对用户的限速。真正的体感瓶颈在第一个 token 出现之前。多模态推理的 prefill 成本远高于纯文本：一张高分辨率图进入模型，要先经过 27 层 ViT 编码（config.json 中vision_config.num_hidden_layers: 27、image_size: 980），再按max_slice_nums（默认 9，可调至 36）切块；视觉 token 默认按downsample_mode: "16x"压缩以节省算力，追求细节时可切到"4x"——细节与延迟在此刻直接互斥；视频输入默认最多抽 128 帧（max_num_frames: 128），每一帧都要走一遍视觉编码。这些开销全部发生在用户按下快门之后、第一个字吐出来之前。再加上enable_thinking思考模式和 generation_config.json 中temperature: 1.0、top_k: 20、top_p: 0.95的采样配置，一次"看图回答"的真实等待 = 图像编码时间 + 首 token 延迟 + 13 Token/s 的生成时间。短答案（50 token）尚可在数秒内完成，一旦进入长文总结、多轮追问，延迟是累积的——这才是"体感慢"的真正来源。官方在 iPhone 17 Pro Max 上的演示视频展示的是流式渲染下的观感，真实但经过了场景选择：结论先行：13 Token/s 本身不丢人，它丢分的地方是"开始回答之前的那段沉默"。二、3GB 的魔术：首个"无损"端侧 MoE 到底解决了什么先看这个模型有多"重"。从 model.safetensors.index.json 的total_size: 70425751648可知，原始 bf16 权重约 70.4GB，被切成 16 个 safetensors 分片。而 MoE 结构的规模藏在 config.json 里：num_experts: 256（每层 256 个专家）、num_experts_per_tok: 8（每个 token 只激活 8 个）、另有shared_expert，共 40 层，且按full_attention_interval: 4的模式在 linear_attention（类 Mamba 线性注意力）与 full_attention 之间 3:1 混合，moe_intermediate_size: 512。MoE 的"激活 3B"是算力上的优势，却是内存上的灾难：不同 token 在不同层会路由到不同的专家，设备内存装不下全部 256×40 份专家权重，只能把权重放在闪存里按需换入换出——如果没有调度优化，反复的换页停顿会让解码卡到无法交互。这就是为什么此前 MoE 在端侧只能"能跑"，谈不上"流畅"。MiniCPM-V 4.7 用三件套回答了这个问题（README 的 On-Device Capability 一节有完整说明）：Lookahead Expert Scheduling（LES）：用跨层路由预测预加载下一层可能用到的专家，被真实 router 选中的专家优先计算，预测落空的专家照常加载计算——预取只影响调度，计算始终遵循模型原始的 token 级路由，这是"无损"成立的技术前提；细粒度逐层量化：降低专家权重的存储与访存开销；DSpark 投机采样：把投机解码整合进端侧推理链路。优化前后的差距在官方对比动图里非常直观——左侧是经过 LES 调度的推理，右侧是无优化的同模型，右侧几乎处于"逐字卡顿"状态：但要澄清一个容易被传播误导的数字：3GB 是运行时工作内存，不是模型的存储体积。35B 权重即使量化到 int4 也需约 17GB 闪存，GGUF/BNB/AWQ/GPTQ/FP8 等变体解决的是存储与访存带宽，3GB 解决的是常驻内存。二者是不同的约束，宣传口径里常被混为一谈。三、"能跑"与"好用"之间：功耗、内存与生态的三道坎第一道坎：功耗与散热。手机 SoC 在持续高负载下推理，发热与降频是端侧的老问题；MoE 频繁的专家换页还意味着持续高强度的闪存 IO，其能耗在官方文档中并未披露。13 Token/s 是峰值速度还是可持续速度、跑 10 分钟对话后是否掉到个位数，这些数据目前是缺失的——严谨地说，我们只看到了"最好的一次测量"。第二道坎：安装与内存的现实。社区部署教程里反复出现的问题——显存不足、加载报错、中文乱码（如 2024~2025 年间围绕 MiniCPM-V 2.6/2.5 的 Ollama、llama.cpp、vLLM 部署帖）——在 35B 量级只会更突出。量化位宽每降一档，能力损失与可用内存之间就要重新做一次权衡；而 README.md 明确推荐的downsample_mode、max_slice_nums、max_num_frames等参数，本质上都是用户亲手在"细节"与"速度"之间调平衡。第三道坎：生态成熟度。从纸面看，MiniCPM-V 4.7 的生态铺得很开：iOS / Android / HarmonyOS 三端，Rockchip、Houmo、Intel、AMD、Arm 芯片的 day-0 支持，SGLang、vLLM、llama.cpp、Ollama、OpenVINO 推理框架，SWIFT、LLaMA-Factory 微调链路，GGUF/BNB/AWQ/GPTQ/FP8/int4 量化体系，外加 Self-Replay Fine-Tuning 定制方案。但"框架支持"和"App 好用"是两码事：真正每天可用的端侧多模态，需要相机/相册接入、离线包管理、多轮会话持久化、隐私边界设计——这些属于产品工程，不在模型仓库的交付范围之内。社区用户已经开始拿"图片的搞笑之处""图像像素值"这类刁钻问题考验模型，说明大众对它的期待已经超越"能跑"，进入"理解得到不到位"的层面。四、性能换效率：35B-A3B 的底气在数据里如果只看推理速度，端侧模型的军备竞赛里总有更小的选手——同系列还有 1B 变体，上一代 MiniCPM-V 4.6 的 1.3B 版本号称"6GB 内存即可运行"。35B-A3B 的真正价值在于能力与效率的帕累托前沿：README 的评测章节给出，Instruct 模式下 35B-A3B 在更短的推理时间内拿到了高于 Qwen3.6 35B-A3B 的综合分数，而后者同样是一个 35B 总参数、3B 激活的 MoE：视觉-语言能力层面同样有完整的 Instruct 模式对比（overall_performance_35ba3b_instruct.png）。换句话说，这个模型追求的不是"端侧最快"，而是"端侧能力天花板最高"，13 Token/s 只是这个目标在 iPhone 上的副产品。对开发者而言，这才是比单点测速更值得关注的数字：它意味着在一台主流旗舰手机上，能拿到接近云端 35B 级 MoE 的理解质量。五、什么时候才算真正"可用"：三条可检验的线与其争论"值不值得欢呼"，不如给"好用"画三条可检验的底线：端到端延迟：拍一张照片到拿到答案，应进入 3 秒以内；看一段视频出结论，应进入 30 秒以内。tokens/s 只决定后半个流程，prefill 与前处理才决定体感。长会话不掉速：上下文从几十 token 涨到数万 token 时，生成速度不应大幅衰减（注意 config.json 的max_position_embeddings: 262144上限）；连续使用 10 分钟，设备不应烫手、续航不应断崖。能力无显著妥协：OCR、图表理解、多图对比、视频事件定位等端侧高频场景，量化后不应出现明显的能力塌陷——官方以"路由不变、无损推理"承诺了这一点，但它需要第三方复现验证，而不是厂商自证。对照这三条，MiniCPM-V 4.7 35B-A3B 在"短问答、单图理解"上已经接近可用线，在"长文生成、复杂多轮推理、持续交互"上仍处于"能跑"区间。13 Token/s 值得记录，因为它是"首个无损端侧 MoE"这个技术拐点的注脚——LES、逐层量化和投机采样共同证明，MoE 的稀疏性红利可以在手机内存里兑现。但把 13 Token/s 当成"端侧 AI 已经好用"的证据，就混淆了两件不同的事：工程上能跑起来，和产品上值得每天用，中间隔着的正是首 token 延迟、功耗曲线与生态打磨这三道还没有被完整回答的问题。【免费下载链接】MiniCPM-V-4.7-35B-A3BMiniCPM-V 4.7 是 MiniCPM-V 系列的最新模型，提供 35B-A3B 变体，其中 35B-A3B 是 MiniCPM-V 系列中的首个 MoE（混合专家）模型。它在家族现有的单图、多图和视频理解能力基础上，结合了更强的基础能力、高效的视觉编码以及端侧推理特性。项目地址: https://ai.gitcode.com/OpenBMB/MiniCPM-V-4.7-35B-A3B创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
13 Token/s 值得欢呼吗：端侧多模态的"能跑"与"好用"之间还隔着什么【免费下载链接】MiniCPM-V-4.7-35B-A3BMiniCPM-V 4.7 是 MiniCPM-V 系列的最新模型，提供 35B-A3B 变体，其中 35B-A3B 是 MiniCPM-V 系列中的首个 MoE（混合专家）模型。它在家族现有的单图、多图和视频理解能力基础上，结合了更强的基础能力、高效的视觉编码以及端侧推理特性。项目地址: https://ai.gitcode.com/OpenBMB/MiniCPM-V-4.7-35B-A3B面壁智能的 MiniCPM-V 4.7 35B-A3B 发布后，社区里流传最广的一句话是："首个开源、无损运行的端侧 MoE 模型，在 iPhone 17 Pro Max 上实现 13+ Token/s 的生成速度，仅需 3GB 内存。"总参数 350 亿、单 token 只激活 30 亿的 MoE 结构，能在手机里不降能力地流畅推理，这确实是端侧多模态发展史上的一个节点。但 13 Token/s 到底意味着什么？把"能跑"当成"好用"，中间还隔着多少东西？本文从真实交互体感、内存工程的代价、功耗与生态短板三个维度拆解，最后给"可用"画一条可检验的线。一、先别急着欢呼：13 Token/s 的真实体感是什么把 13 Token/s 换算成人能感知的速度：MiniCPM-V 4.7 的语言底座采用 Qwen 系列 tokenizer（tokenizer_config.json，tokenizer_class: Qwen2Tokenizer，词表 248144），中文文本平均每个 token 对应 0.7~1.5 个汉字。取中间值粗算，13 Token/s ≈ 10~13 汉字/秒 ≈ 每分钟 600~780 字。而真人对话的语速大约是每分钟 200~300 字。也就是说，一旦开始流式输出，模型打字的速度其实是"超过人说话"的——只看 tokens/s 这个数，它并不慢，甚至快于多数云端聊天产品对用户的限速。真正的体感瓶颈在第一个 token 出现之前。多模态推理的 prefill 成本远高于纯文本：一张高分辨率图进入模型，要先经过 27 层 ViT 编码（config.json 中vision_config.num_hidden_layers: 27、image_size: 980），再按max_slice_nums（默认 9，可调至 36）切块；视觉 token 默认按downsample_mode: "16x"压缩以节省算力，追求细节时可切到"4x"——细节与延迟在此刻直接互斥；视频输入默认最多抽 128 帧（max_num_frames: 128），每一帧都要走一遍视觉编码。这些开销全部发生在用户按下快门之后、第一个字吐出来之前。再加上enable_thinking思考模式和 generation_config.json 中temperature: 1.0、top_k: 20、top_p: 0.95的采样配置，一次"看图回答"的真实等待 = 图像编码时间 + 首 token 延迟 + 13 Token/s 的生成时间。短答案（50 token）尚可在数秒内完成，一旦进入长文总结、多轮追问，延迟是累积的——这才是"体感慢"的真正来源。官方在 iPhone 17 Pro Max 上的演示视频展示的是流式渲染下的观感，真实但经过了场景选择：结论先行：13 Token/s 本身不丢人，它丢分的地方是"开始回答之前的那段沉默"。二、3GB 的魔术：首个"无损"端侧 MoE 到底解决了什么先看这个模型有多"重"。从 model.safetensors.index.json 的total_size: 70425751648可知，原始 bf16 权重约 70.4GB，被切成 16 个 safetensors 分片。而 MoE 结构的规模藏在 config.json 里：num_experts: 256（每层 256 个专家）、num_experts_per_tok: 8（每个 token 只激活 8 个）、另有shared_expert，共 40 层，且按full_attention_interval: 4的模式在 linear_attention（类 Mamba 线性注意力）与 full_attention 之间 3:1 混合，moe_intermediate_size: 512。MoE 的"激活 3B"是算力上的优势，却是内存上的灾难：不同 token 在不同层会路由到不同的专家，设备内存装不下全部 256×40 份专家权重，只能把权重放在闪存里按需换入换出——如果没有调度优化，反复的换页停顿会让解码卡到无法交互。这就是为什么此前 MoE 在端侧只能"能跑"，谈不上"流畅"。MiniCPM-V 4.7 用三件套回答了这个问题（README 的 On-Device Capability 一节有完整说明）：Lookahead Expert Scheduling（LES）：用跨层路由预测预加载下一层可能用到的专家，被真实 router 选中的专家优先计算，预测落空的专家照常加载计算——预取只影响调度，计算始终遵循模型原始的 token 级路由，这是"无损"成立的技术前提；细粒度逐层量化：降低专家权重的存储与访存开销；DSpark 投机采样：把投机解码整合进端侧推理链路。优化前后的差距在官方对比动图里非常直观——左侧是经过 LES 调度的推理，右侧是无优化的同模型，右侧几乎处于"逐字卡顿"状态：但要澄清一个容易被传播误导的数字：3GB 是运行时工作内存，不是模型的存储体积。35B 权重即使量化到 int4 也需约 17GB 闪存，GGUF/BNB/AWQ/GPTQ/FP8 等变体解决的是存储与访存带宽，3GB 解决的是常驻内存。二者是不同的约束，宣传口径里常被混为一谈。三、"能跑"与"好用"之间：功耗、内存与生态的三道坎第一道坎：功耗与散热。手机 SoC 在持续高负载下推理，发热与降频是端侧的老问题；MoE 频繁的专家换页还意味着持续高强度的闪存 IO，其能耗在官方文档中并未披露。13 Token/s 是峰值速度还是可持续速度、跑 10 分钟对话后是否掉到个位数，这些数据目前是缺失的——严谨地说，我们只看到了"最好的一次测量"。第二道坎：安装与内存的现实。社区部署教程里反复出现的问题——显存不足、加载报错、中文乱码（如 2024~2025 年间围绕 MiniCPM-V 2.6/2.5 的 Ollama、llama.cpp、vLLM 部署帖）——在 35B 量级只会更突出。量化位宽每降一档，能力损失与可用内存之间就要重新做一次权衡；而 README.md 明确推荐的downsample_mode、max_slice_nums、max_num_frames等参数，本质上都是用户亲手在"细节"与"速度"之间调平衡。第三道坎：生态成熟度。从纸面看，MiniCPM-V 4.7 的生态铺得很开：iOS / Android / HarmonyOS 三端，Rockchip、Houmo、Intel、AMD、Arm 芯片的 day-0 支持，SGLang、vLLM、llama.cpp、Ollama、OpenVINO 推理框架，SWIFT、LLaMA-Factory 微调链路，GGUF/BNB/AWQ/GPTQ/FP8/int4 量化体系，外加 Self-Replay Fine-Tuning 定制方案。但"框架支持"和"App 好用"是两码事：真正每天可用的端侧多模态，需要相机/相册接入、离线包管理、多轮会话持久化、隐私边界设计——这些属于产品工程，不在模型仓库的交付范围之内。社区用户已经开始拿"图片的搞笑之处""图像像素值"这类刁钻问题考验模型，说明大众对它的期待已经超越"能跑"，进入"理解得到不到位"的层面。四、性能换效率：35B-A3B 的底气在数据里如果只看推理速度，端侧模型的军备竞赛里总有更小的选手——同系列还有 1B 变体，上一代 MiniCPM-V 4.6 的 1.3B 版本号称"6GB 内存即可运行"。35B-A3B 的真正价值在于能力与效率的帕累托前沿：README 的评测章节给出，Instruct 模式下 35B-A3B 在更短的推理时间内拿到了高于 Qwen3.6 35B-A3B 的综合分数，而后者同样是一个 35B 总参数、3B 激活的 MoE：视觉-语言能力层面同样有完整的 Instruct 模式对比（overall_performance_35ba3b_instruct.png）。换句话说，这个模型追求的不是"端侧最快"，而是"端侧能力天花板最高"，13 Token/s 只是这个目标在 iPhone 上的副产品。对开发者而言，这才是比单点测速更值得关注的数字：它意味着在一台主流旗舰手机上，能拿到接近云端 35B 级 MoE 的理解质量。五、什么时候才算真正"可用"：三条可检验的线与其争论"值不值得欢呼"，不如给"好用"画三条可检验的底线：端到端延迟：拍一张照片到拿到答案，应进入 3 秒以内；看一段视频出结论，应进入 30 秒以内。tokens/s 只决定后半个流程，prefill 与前处理才决定体感。长会话不掉速：上下文从几十 token 涨到数万 token 时，生成速度不应大幅衰减（注意 config.json 的max_position_embeddings: 262144上限）；连续使用 10 分钟，设备不应烫手、续航不应断崖。能力无显著妥协：OCR、图表理解、多图对比、视频事件定位等端侧高频场景，量化后不应出现明显的能力塌陷——官方以"路由不变、无损推理"承诺了这一点，但它需要第三方复现验证，而不是厂商自证。对照这三条，MiniCPM-V 4.7 35B-A3B 在"短问答、单图理解"上已经接近可用线，在"长文生成、复杂多轮推理、持续交互"上仍处于"能跑"区间。13 Token/s 值得记录，因为它是"首个无损端侧 MoE"这个技术拐点的注脚——LES、逐层量化和投机采样共同证明，MoE 的稀疏性红利可以在手机内存里兑现。但把 13 Token/s 当成"端侧 AI 已经好用"的证据，就混淆了两件不同的事：工程上能跑起来，和产品上值得每天用，中间隔着的正是首 token 延迟、功耗曲线与生态打磨这三道还没有被完整回答的问题。【免费下载链接】MiniCPM-V-4.7-35B-A3BMiniCPM-V 4.7 是 MiniCPM-V 系列的最新模型，提供 35B-A3B 变体，其中 35B-A3B 是 MiniCPM-V 系列中的首个 MoE（混合专家）模型。它在家族现有的单图、多图和视频理解能力基础上，结合了更强的基础能力、高效的视觉编码以及端侧推理特性。项目地址: https://ai.gitcode.com/OpenBMB/MiniCPM-V-4.7-35B-A3B创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考