千问3.8 Flash Next实测：单卡部署碾压DeepSeek V4？

昨天，千问再次开源，发布了千问3.8 Flash Next——一款采用下一代千问4架构的Flash模型，开源当天就放出了完整权重。对于热衷本地部署的玩家而言，这无疑是一份惊喜。本文基于B站UP主bwd6的全套实测，深入解析这款模型的架构特点、部署方案，以及它与刚发布的DeepSeek V4 Flash的正面对决表现。

全新架构：用空间换计算的Ngram设计

千问3.8 Flash Next是一个全新架构的多模态混合专家（MoE）模型，主模型拥有1250亿参数，推理时仅激活60亿参数。

混合专家（Mixture of Experts, MoE）是一种稀疏激活的神经网络架构，其核心思想是将模型参数分散到多个"专家"子网络中，每次推理时只通过一个门控网络（Router）选择性激活其中少数几个专家来处理输入。这意味着模型可以拥有极大的总参数量（决定了模型的知识容量上限），但每次推理的实际计算量远低于同等参数规模的密集模型。千问3.8 Flash Next的1250亿总参数/60亿激活参数，意味着其稀疏率约为95%，每次推理只动用不到5%的参数，这是当前MoE模型中非常激进的稀疏比例。作为对比，Mixtral 8x7B的激活率约为25%，DeepSeek-V2的激活率约为10%。更低的激活率带来更快的推理速度，但也对专家路由策略提出了更高要求，需要确保不会出现"专家坍缩"——即大部分输入总是被路由到少数几个专家的问题。为了应对这一挑战，业界发展出了多种负载均衡策略，包括辅助损失函数（auxiliary loss）、专家容量限制（expert capacity）以及DeepSeek提出的无辅助损失负载均衡方法。千问3.8 Flash Next在95%的极端稀疏率下仍能保持稳定的输出质量，说明其路由机制经过了精心设计。

它最大的亮点在于额外引入了510亿参数的Ngram模块——可以理解为一张巨大的局部短语记忆表。Ngram（N元语法）是自然语言处理中最经典的统计模型之一，它通过统计文本中连续N个词元共同出现的频率来建模语言的局部规律。例如，一个3-gram模型会记录所有连续三个词的出现频率，当给定前两个词时，可以直接查表得出第三个词的概率分布。在千问3.8 Flash Next中，Ngram模块被赋予了全新的含义——它不再是传统的统计频率表，而是一个经过深度学习训练的、包含510亿参数的巨型查找结构。其工作原理类似于"投机解码"（Speculative Decoding）中的草稿模型：当主MoE模型需要生成下一个token时，Ngram模块会先根据当前上下文中的局部短语模式快速预测候选结果。如果预测命中（即主模型验证通过），就可以跳过主模型的完整前向传播计算，直接采用Ngram的预测结果。投机解码最早由Google DeepMind在2023年系统化提出，其关键洞察是：用一个小而快的草稿模型先"猜"多个token，再用大模型并行验证这些猜测，在数学上可以证明这不会改变输出分布——只要被拒绝的token会触发回退重新采样。千问将510亿参数的Ngram模块作为草稿模型的角色，相比传统投机解码中使用独立小模型的方案，Ngram表的查询速度更快（接近O(1)的查表操作），且由于是与主模型联合训练的，命中率预计也会更高。这种机制对高频短语、固定搭配、代码模板等具有高度重复性的内容特别有效。

这张短语记忆表的核心思路是「用空间换计算」。当模型遇到常见短语和局部模式时，可以直接查表获取结果，从而跳过重复计算。因此它的计算负载会明显低于参数量相近的其他模型。当然，代价也很直接：你需要额外准备大约50G到100G的内存或显存来承载这张Ngram表。

模型发布后，本地部署玩家最关心三个问题：

1. Ngram能否卸载到系统内存甚至固态硬盘？ 目前主流推理框架都在推进Ngram的内存卸载支持，但尚未看到让它常驻固态硬盘的官方路径。从技术角度看，Ngram表的访问模式是随机查询而非顺序读取，固态硬盘的随机读取延迟（通常为几十微秒）相比系统内存（约100纳秒）高出两到三个数量级，这可能会严重拖慢推理速度。因此内存卸载是更现实的折中方案。
2. 96G、128G统一内存设备能否稳定运行？ 大量使用此类设备（如Apple Silicon Mac）的玩家正在焦急等待成熟方案。Apple Silicon的统一内存架构（Unified Memory Architecture）将CPU和GPU共享同一块物理内存，消除了传统PC上CPU内存与GPU显存之间的数据搬运开销，理论上非常适合需要频繁在主模型和Ngram表之间切换的混合推理场景。但目前的挑战在于MLX等Apple生态推理框架对MoE+Ngram这种复合架构的支持尚不成熟。
3. 真实表现能否打败DeepSeek V4 Flash？ 这是最多人关心的问题。

本地部署实战：单卡96G显存跑通完整方案

本次测试租用了一台配有96G显存和188G系统内存的机器，通过将嵌入表卸载到系统内存，让显存和系统内存协同完成混合推理。

推理框架选择了vLLM，因为目前只有它能在SM120显卡上跑通完整方案。vLLM是由加州大学伯克利分校Sky Computing Lab开发的高性能大语言模型推理和服务框架，其核心创新是PagedAttention技术——借鉴操作系统虚拟内存的分页管理思想，将KV Cache（键值缓存）拆分为固定大小的页面进行动态分配，极大地减少了显存碎片和浪费。在传统推理框架中，KV Cache需要预先分配一整块连续显存，当多个请求的序列长度各不相同时，会产生大量内部碎片（已分配但未使用的空间）和外部碎片（无法被利用的零散空间）。PagedAttention通过将KV Cache切分为类似操作系统中4KB内存页的固定小块，支持非连续存储和动态释放，将显存利用率从传统方案的约50%-60%提升到接近100%。在本文的测试场景中，vLLM还展示了另一个关键能力：支持将部分模型参数（如嵌入表、Ngram模块）卸载到系统内存，实现显存与内存的协同推理。

这里提到的SM120，指的是NVIDIA最新一代Blackwell GPU架构中的流式多处理器编号。NVIDIA GPU的每一代架构都会更新SM版本号：Ampere为SM80/SM86，Hopper为SM90，而Blackwell则为SM100/SM120。SM（Streaming Multiprocessor，流式多处理器）是NVIDIA GPU的基本计算单元，每个SM包含若干CUDA核心、张量核心（Tensor Core）、共享内存和寄存器文件。不同的SM版本号意味着不同的指令集和硬件特性——例如SM90引入了异步执行和TMA（Tensor Memory Accelerator），SM100/SM120则进一步优化了FP4/FP8低精度计算能力。由于架构较新，许多推理框架的CUDA kernel尚未针对SM120进行适配和优化。SGLang暂不支持这张显卡，会在预热阶段直接崩溃；llama.cpp则仍在优化合并请求中。经过约两小时的调试，UP主成功在96G显存的单卡上跑起了模型。

实测发现，Ngram必须放进系统内存，但对推理速度的影响微乎其微。开启MTP（Multi-Token Prediction，多token预测）后，不同上下文长度下的生成速度全部保持在每秒100 token以上，prefill阶段更是全部超过每秒1万token。MTP是近年来大语言模型推理加速的重要技术方向——传统自回归语言模型每次只预测一个token，而MTP允许模型在一次前向传播中同时预测多个连续的token。这一概念最初由Meta在其研究论文中系统化提出，并在Llama系列模型的训练中进行了验证：在训练阶段让模型学习同时预测未来2-4个token，不仅能加速推理，还能提升模型对长程依赖的建模能力，因为预测更远的token迫使模型学习更深层的语义表征。千问3.8 Flash Next的Ngram模块本质上就是MTP理念的一种工程实现：通过Ngram表快速提供多个候选token，再由主模型并行验证，从而将每次推理的有效输出从1个token提升到多个token。这解释了为什么开启MTP后生成速度能突破每秒100 token的门槛。

值得解释的是，大语言模型的推理过程分为两个截然不同的阶段：Prefill（预填充）和Decode（解码）。Prefill阶段是模型一次性处理所有输入prompt的过程，由于输入token可以并行计算注意力，主要受限于计算带宽（compute-bound），此时GPU的算力（FLOPS）是瓶颈；Decode阶段则是模型逐个生成输出token的过程，每生成一个token都需要读取完整的KV Cache，主要受限于内存带宽（memory-bound），此时GPU的显存带宽（GB/s）是瓶颈。这两个阶段的算术强度（arithmetic intensity，即每字节数据传输对应的浮点运算次数）差异巨大：Prefill的算术强度通常在100-1000 FLOP/Byte的量级，而Decode仅为1-10 FLOP/Byte。文中prefill速度超过每秒1万token而decode速度为每秒100+ token，两者之间百倍的差距正是这两个阶段不同瓶颈特征的典型体现。也正因如此，业界出现了Prefill-Decode分离部署的架构思路，用不同的硬件配置分别优化这两个阶段。

用UP主的话说，「部署完成后的体感真的是疯一样的速度」。

更值得关注的是，对比DeepSeek V4 Flash，这套方案可以省下一张显卡，速度反而更快。这对本地部署玩家而言是极具吸引力的性价比优势。

八项基准对决：千问 vs DeepSeek V4 Flash

本次评测采用UP主自建的8项大模型评测基准，与上周五刚发布的DeepSeek V4 Flash视觉实验版（代称「小鲸鱼」）进行一对一对比。需要说明的是，该DeepSeek实验版目前仅有官方API可用，权重尚未开放。

语言与推理能力

• 中文写作：千问7分，小鲸鱼8分。千问的写作风格偏「平」，不算出彩。
• 逻辑推理（异形神明谜题）：两者均拿到满分，毫无压力。

多模态与视觉能力

• 发票识别：千问28项数据全部正确得10分，小鲸鱼有一个字段出错得9分。
• 长上下文探针：两者均准确命中目标信息并完成推理，双双满分。长上下文探针测试（常被称为"大海捞针"测试，Needle in a Haystack）是评估模型长文本处理能力的标准方法：在极长的文本中随机插入一条关键信息，然后要求模型找到并基于该信息进行推理。这项测试考验的是模型注意力机制在超长序列中的有效覆盖范围——如果模型的注意力存在"中间遗忘"（Lost in the Middle）现象，就可能遗漏插入在文本中段的关键信息。2023年斯坦福大学的研究首次系统化揭示了这一现象：当关键信息位于长文本的中间位置时，多数模型的召回率会显著下降，而位于开头或结尾时则表现良好，这与人类阅读长文本时的注意力衰减模式颇为相似。两个模型均满分，说明它们在长上下文窗口内的注意力分配是均匀且有效的，很可能受益于训练阶段针对长序列的特殊优化策略，如位置编码外推（RoPE scaling）和长文本课程学习。
• 高级识图：千问满分，「你永远可以相信千问的识图能力」；小鲸鱼出现两项细节错误得8分。千问系列模型在视觉理解方面的持续领先，很大程度上得益于阿里在多模态预训练数据（特别是中文OCR和文档理解数据）上的长期积累，以及Qwen-VL系列在视觉编码器与语言模型对齐方面的技术沉淀。Qwen-VL采用的视觉编码器基于ViT（Vision Transformer）架构，通过将图像分割为固定大小的patch并将每个patch映射为一个token，实现了图像信息与文本token的统一表征。在此基础上，跨模态对齐模块（通常是一个可学习的投影层或Q-Former结构）负责将视觉特征映射到语言模型的语义空间中。这个实验版的V4 Flash视觉模型在识图精度上离顶级水平仍有差距。
• 办公应用（理解171个多模态文件并整理表格）：两者均满分。

长程复杂任务

第七项是最考验模型综合能力的长程任务：处理约一季的原始素材，写入数据库、构建后端接口，最终交付一个全站应用。这类任务也被称为"Agentic Coding"——模型不再是简单地回答问题或生成代码片段，而是需要作为一个自主agent，在多个步骤间保持状态一致性、管理文件系统、处理错误并迭代修正，完成一个端到端的工程任务。这对模型的指令遵循能力、长程规划能力和上下文管理能力都是严峻考验。值得注意的是，Agentic Coding与传统的代码生成基准（如HumanEval、MBPP）有本质区别：后者通常只测试模型生成单个函数的能力，而Agentic Coding要求模型在一个有状态的环境中持续工作数十分钟甚至数小时，涉及文件读写、数据库操作、API调用等真实工程操作。SWE-Bench是目前最具代表性的Agentic Coding评测之一，它要求模型在真实的GitHub仓库中定位并修复bug，但本文中UP主的测试更加激进——从零构建一个完整的全栈应用，这在复杂度上远超单个bug修复。

千问3.8耗时51分钟，消耗1900万Token，主要扣分项是缺少暗色模式和一些排版瑕疵。小鲸鱼花了41分钟，但消耗了比千问多70%的Token，排版瑕疵更多，功能完成度也不如千问。

千问3.8 Flash Next最亮眼之处，是用比其他模型少得多的Token拿到了全站应用的第二高分，堪称一个极其高效的模型。这里的"高效"有双重含义：一方面，更少的Token意味着更低的API调用成本——以千问官方定价计算，1900万Token和3200万Token之间的成本差距在长期高频调用场景下会累积成相当可观的金额；另一方面，它也意味着模型在理解和执行复杂指令时更加精准，不需要通过冗长的"思考"过程来弥补理解上的不足。在大模型领域，Token效率正在成为与准确率同等重要的评价维度——一个需要10万Token才能完成的任务和一个只需5万Token就能完成相同任务的模型，后者在实际生产环境中的价值显然更高。Token效率的背后反映的是模型的"信息密度"——即每个生成token所承载的有效信息量。低效的模型往往会生成大量冗余的推理链、重复的确认语句或不必要的格式化内容，而高效的模型则能直击要害。这也与近期学术界对"思维链（Chain-of-Thought）冗余"问题的研究相呼应：过长的推理链不仅浪费token，在某些情况下甚至会引入错误的中间步骤，反而降低最终答案的准确率。

最终排名与价格优势

在UP主评测过的所有本地模型中，千问3.8 Flash Next排名第二，以一分之差惜败给同门的27B（但27B使用的是满血BF16无量化版本）。这里提到的BF16（Brain Floating Point 16）是Google Brain提出的一种16位浮点数格式，与更常见的FP16相比，BF16保留了与FP32相同的8位指数位（因此具有相同的数值范围，约为±3.4×10³⁸），但只有7位尾数位（精度略低于FP16的10位尾数）。在大模型推理中，BF16被认为是"无量化"的基准精度——低于它的INT8、INT4等格式都属于量化压缩，会在不同程度上损失模型精度。量化的基本原理是用更少的位数来表示模型权重：例如INT4量化将每个权重从16位压缩到4位，存储空间直接减少75%，但代价是有效精度的损失。不同的量化方法（如GPTQ、AWQ、GGUF）在压缩效率和精度保持之间做出不同的权衡。千问3.8 Flash Next作为一个1250亿参数的MoE模型能在排名上逼近27B的BF16满血版本，从参数效率的角度看是相当出色的成绩。小鲸鱼落后两个身位排在第四，不过它仍是实验版，待DeepSeek放出全量权重后会重新测试。

需要提醒：该排名仅代表模型在特定本地测试环境下的表现，仅供参考，不能作为任何决策依据。

在价格层面，千问同样展现出明显的竞争力。

以输入100万Token、输出5万Token、缓存命中率99%为假设计算：千问的综合成本约为DeepSeek空闲时段的6成、高峰时段的3成。现代大模型API服务普遍采用"前缀缓存"（Prefix Caching）机制来降低重复计算的成本——当多次请求共享相同的prompt前缀时（例如系统提示、长文档上下文），服务端可以复用之前计算好的KV Cache，省去重复的prefill计算，因此缓存命中的价格远低于普通输入价格。这一机制在技术上依赖于对请求前缀的哈希匹配：服务端会对每个请求的token序列计算前缀哈希，如果与缓存中已有的KV Cache匹配，就直接复用，只需对新增的token部分进行增量计算。需要注意的是，前缀缓存的有效性取决于缓存的存活时间（TTL）和缓存容量——如果请求间隔过长或缓存被其他请求挤出，就需要重新计算，缓存命中率会大幅下降。不同厂商的缓存策略也有差异：有的采用LRU（最近最少使用）淘汰策略，有的则提供"固定缓存"选项允许用户付费锁定特定前缀的缓存。99%的缓存命中率是agent任务的典型场景：agent在执行多步任务时，每一步都会携带相同的系统提示和之前所有对话历史，只有最新的一小部分输入是新增的。例如一个agent在50步任务中，系统提示+历史对话可能占据95%以上的输入token，每步真正新增的指令和反馈只有几百个token。在这种场景下，缓存命中价格几乎决定了总成本。千问在缓存命中价格上的优势，使其在高频agent调用场景中的成本优势被进一步放大。

对于本地跑agent任务的场景，这类任务会反复读取大量上下文，缓存命中价格才是长期成本的大头——实际价格差距只会比表格计算的更夸张。

总结：多模态Flash赛道的格局变化

从性能到价格，千问和DeepSeek对多模态Flash模型的投入正在肉眼可见地加码。就在昨天，智谱也发布了自己首个多模态Flash模型，正式入局。可以预见，这条赛道未来只会越来越热闹。

所谓"Flash模型"，是近半年来行业中涌现的一个产品定位概念，指的是在保持接近旗舰模型能力的同时，大幅优化推理速度和成本的模型版本。Google的Gemini Flash系列率先定义了这一品类——2024年中发布的Gemini 1.5 Flash以远低于Gemini 1.5 Pro的价格提供了接近90%的Pro级性能，迅速证明了"够用且便宜"的市场需求是巨大的。随后各家厂商纷纷跟进，Flash模型已经从一个产品策略演变为一条独立的技术赛道。Flash模型的竞争本质上是效率的竞争——在给定的算力预算下，谁能提供更好的性能，谁就能在API定价和本地部署门槛上建立优势。从技术路线来看，各家实现"Flash"的方式各不相同：Google主要依靠蒸馏和架构搜索，DeepSeek通过极致的MoE稀疏化，而千问则走了MoE+Ngram的混合路线。这种技术路线的多样性正是这条赛道活力的体现。值得注意的是，Flash模型赛道的兴起也深刻改变了大模型的商业逻辑：此前行业的焦点是"谁的模型最强"，现在则转向"谁能用最少的算力达到足够好的效果"。这一转变的背后是大模型落地进入深水区——当模型能力已经足以应对大多数任务时，成本和速度成为决定商业可行性的关键因素。据估算，全球大模型API市场中超过70%的调用量集中在"轻量级"任务上（如简单问答、文本改写、格式转换），这些任务完全不需要旗舰模型的全部能力，Flash模型恰好填补了这一巨大的市场空白。

对于本地部署玩家来说，千问3.8 Flash Next凭借Ngram架构带来的高效推理、单卡可跑的部署友好性，以及扎实的多模态能力，确实具备成为DeepSeek V4 Flash平替的潜力——尤其是在你需要稳定权重、自主可控的本地环境时。

核心要点

• 架构创新：千问3.8 Flash Next采用1250亿参数MoE（仅激活60亿）+ 510亿参数Ngram模块的混合架构，以「用空间换计算」的思路实现了极致推理效率
• 部署门槛：单卡96G显存+系统内存即可跑通完整方案，比DeepSeek V4 Flash少用一张显卡，速度反而更快
• 性能表现：在8项基准测试中与DeepSeek V4 Flash互有胜负，在发票识别、高级识图等多模态任务上表现更优，长程Agentic Coding任务中以更少的Token消耗达到更高的功能完成度
• Token效率：完成全站应用任务仅消耗1900万Token，比DeepSeek V4 Flash少70%，这在长期高频调用场景中意味着显著的成本节约
• 价格优势：在99%缓存命中率的agent场景下，千问API的综合成本仅为DeepSeek空闲时段的6成、高峰时段的3成
• 赛道趋势：Flash模型已从单一产品策略演变为独立技术赛道，千问、DeepSeek、智谱等厂商正在加速布局