小睿聊AI 08｜Qwen3.8 Flash 本地部署，我为什么最终选了它？

我是小睿。

这次选本地模型，我最终用了 Qwen3.8 Flash。公开评测中的代码 Agent 表现符合我的任务方向，原生视觉适合直接处理图纸、截图和现场照片；现有配置的 128K 首轮等待，也短于原来的 DeepSeek。不同任务的取舍，仍要逐项看。

封面｜独立封面，AI 生成概念插画，非实际部署照片或测量结果。

机器只是这次选择的部署条件。这里重点看模型：本地运行的是哪种发布物，能力证据如何，量化有哪些取舍，以及选好以后，怎样把这套能力交给员工使用。

一 先看清楚本地部署的是哪一个 Qwen

日常说的“Qwen3.8 Flash”，需要分成两种形态。公开权重是 Qwen3.8-Flash-Next，可以下载并自己运行；官方托管服务是 Qwen3.8-Flash，默认百万上下文和内置工具属于服务端提供的组合。两者有关联，但不能把托管端所有功能直接算成本地安装后的能力。[1]

Flash-Next 本身带视觉编码器，能把图像与文字一起理解。官方列出的模型规模是：125B 主体、每个 token 激活约 6B，另有 51B 的 n-gram 嵌入表和 4B 的 MTP 模块。B 表示十亿参数；token 是模型处理内容的单位，不等于一个汉字。[1]

部署时，要分别考虑这些模块的存储和计算开销。

它采用混合专家模型，也就是 MoE。模型保留一大组参数，每次计算只选择其中部分参与，因此计算量不必跟总参数一起增长。但“激活 6B”并不意味着只需装下一个 6B 模型，其他专家和附加模块仍然要存放在某处。

51B 的 n-gram 表，可以理解为按相邻词元组合查询的大容量表。它增加参数容量，所需计算方式与主体里的矩阵计算不同，却仍会占用存储和内存。MTP 是多 token 预测模块，用来提出后续输出的候选，再由主模型验证，以加快输出。[2]

图 1｜参数规模与部署组合分开看。结构按官方模型卡和技术报告 [1][2]。

长上下文方面，Flash-Next 原生支持 262,144 token，并可扩展到百万。其架构交替使用 Gated DeltaNet 和 Qwen Sparse Attention：前者把已经读过的内容压入持续更新的状态，后者从长序列中选择相关区域参与注意力计算。这套设计兼顾长资料的计算开销和远处内容检索。[1][2]

这里仍有三个长度要分开：模型原生长度、经过扩展配置的长度，以及当前机器实际设置并测过的长度。我现有记录里的 Qwen 配置窗口为 262K，DeepSeek 为 384K；这两个数描述部署配置，不能直接当成两款模型的理论上限。

与之对照，DeepSeek V4 Flash 0731 的官方主体规模是 284B、激活 13B，原始发布物本身也采用混合精度。由参数和量化名称，不能直接算出哪一个“更聪明”或“快几倍”。实际表现还取决于运行框架、缓存和任务内容。[3]

因此，本地选择要看这些模块能否在当前引擎里完整加载，给长资料留下多少运行余量。量化质量采用 NVIDIA 发布的受控评测；下文速度来自我的本地部署，两组测试分别看。

二 能力要分项看 代码题和代码 Agent 不是一回事

我关注本地模型，很大一部分是为了让 Agent 围绕同一批代码、文件和业务工具持续工作。这里的 Agent，指能分步骤读资料、调用工具、执行任务并根据结果继续的助手。

选型时，普通代码题和这种持续工作最好分别看。写出一个函数，与进入一个仓库、找到问题、修改文件、运行测试、再处理失败，要求并不相同。

Qwen 官方模型卡里，与 DeepSeek 0731 的同表结果已经能看出这种区别。

表 1 Qwen 发布方的同表能力对照

任务与指标	Qwen Flash-Next	DeepSeek 0731
科学问答 GPQA Diamond	91.7	90.8
仓库修改 DeepSWE 1.1	58.7	54.4
需求生成仓库 NL2Repo	48.1	54.2
工具任务 Toolathlon Verified	73.5	70.3

来源 [1]，各项得分以百分制列示。Qwen 发布方测试，非双 ATOM 复现；DeepSWE 取两种执行框架较高成绩。不跨表比较不同基准版本。

这组测试中，Qwen 的仓库修改和工具任务得分较高，DeepSeek 的“从需求生成整个仓库”得分较高。科学问答两者接近。选模型时，得先明确要它做哪一类代码工作。[1]

图 2｜AA 独立同页对照 [4]，模型服务评测，非作者本地 NVFP4；方法见 [5]。

再看独立评测。Artificial Analysis 当前同页比较中，Qwen Flash-Next 的 Intelligence Index 为 40，DeepSeek V4 Flash 0731（Max）为 34。指数用于观察综合位置，更有用的是图中的几项具体结果。[4]

终端任务中，模型需要在计算环境里把工作真正做完，Qwen 在这次测试中较高；自动化任务则只有小幅差异。长文档推理同为 80%，高难度知识与推理评测 HLE 分别为 38% 和 39%，也很接近。综合分数不能替代任务选择，也不能把几分的小差别直接解释成稳定领先。

AA 的终端测试使用 Terminal-Bench 4.0，长文档推理使用 AA-LCR v1.1；后者约有 100K 输入，需要跨多份文档推理。这些是评测机构对其模型服务的测量，底层精度与我的本地发布物没有对齐，不能标成本地 NVFP4 成绩。[4][5]

另一家独立榜单 LiveBench 也给出了一个值得保留的反差：普通 Coding，Qwen 为 72.6、DeepSeek 0731 为 75.0；Agentic Coding 则分别为 61.6 和 46.8。这是同一榜单的截面数据，不是本地复测，但它提醒我：如果主要工作是让助手调用工具、连续改代码，只看普通代码题就容易选错观察重点。[6]

视觉能力还可参考官方的另一组成绩：Qwen 官方 RealWorldQA 为 88.5；科学图表问答 CharXiv，不用代码解释器时为 84.6，使用后为 90.6。这支持把图像理解与工具计算结合起来测试，却不能替代对工程图小字、扫描件和现场照片的实际检查。[1]

这几组结果，让我更看重 Qwen 处理代码 Agent 和工具任务的潜力。若主要做独立代码题、从需求生成仓库，或者已有成熟的 DeepSeek 工作流，就应该保留对应维度的对照，而不是照着综合榜单直接替换。

三 长窗口有价值 也要看长资料中能找对多少

Agent 的上下文会随着工作增长。它先读任务和代码，再带上工具返回、测试日志、历史修改；文档工作则不断加入新版本和补充材料。能容纳长上下文，是持续工作的重要基础。

不过，模型接收得下，并不等于所有长度上的任务都做得一样好。前面的 AA-LCR v1.1 在约 100K 多文档推理中，Qwen 与 DeepSeek 0731 都是 80%。这说明我不能仅凭 Qwen 本地首包更快，就说它读长资料更准确。

Qwen 的技术报告还给出了更长输入的质量证据。在论文的 QSA 架构验证中，RULER 这类长上下文检索评测，512K–1M 区间得分仍为 93.00；换到更难的八针 MRCR，结果就明显不同。[2]

表 2 论文 QSA 架构验证中的八针 MRCR

上下文档位	八针 MRCR 得分（0–100）
128K	95.98
256K	93.00
512K	40.53
1M	26.44

来源 [2][7]。得分为指定回答的匹配表现，非真实任务通过率；不是本地 NVFP4 实测。

八针 MRCR 会在很长的合成对话中多次插入相似要求，再让模型找回指定次序的回答。它的得分基于字符串匹配，不能解释成真实企业任务通过率。表里 512K 和 1M 的下降说明：窗口很大时，区分相似线索、准确找回指定内容仍有难度。[7]

这些是论文里的架构测试，不是我把 NVFP4 放在 GB10 上重新测出的结果。但它给出了一个有数据支撑的使用原则：长窗口用来容纳必要关联，不必把所有历史材料都堆进同一轮。

例如比较两次测量，应保留工件标识、单位、配置版本、关键记录和已经排除的原因。详细原始数据可留在文件里，按需调用；长日志保留关键片段，完整日志仍能追溯。对长文档也是如此：检索相关章节、保留出处和适用条件，通常比单纯追求填满窗口更值得做。

我的速度记录目前覆盖到 128K；长资料质量另参考公开评测，并用自己的任务复核。更长的任务可以继续验证，不能仅由“可扩百万”跳到“百万内容同样可靠”。

四 量化让模型更容易装下 能力有没有保住

本地选型不能只看原始模型成绩。最终下载的往往是量化发布物：把部分参数用较低精度表示，以减少权重体积和运行负担。部署者关心的，是这个具体版本省下了什么，以及是否仍适合自己的任务。

以 NVIDIA 发布的 Flash-Next NVFP4 为例，它是采用混合精度的模型权重版本：主体里的路由专家使用 NVFP4，其他部分保留更高精度，n-gram 表与部分 MTP 权重使用 FP8。发布方给出的磁盘体积约为 BF16 源模型的 1/2.7。这里说的是权重文件体积，并非整机内存占用或速度都改善 2.7 倍。[8]

更重要的是，它提供了与 FP8 参考版本的受控评测，下面选三项与本地用途有关的结果。

图 3｜NVIDIA 发布方的 FP8 与 NVFP4 对照 [8]，B200/B300 测试；不能当成作者 GB10 成绩。

视觉推理、长上下文和终端任务中，分数有小幅上升，也有小幅下降。这三项成绩与 FP8 参考版本接近，值得纳入部署候选，但不能据此认定所有任务都无损。分数的小幅上升，也不等于量化本身提高了能力。

这组测试由 NVIDIA 在 B200/B300 上使用 vLLM 完成，使用最高推理力度（xhigh），输出上限为 131,072 token。它既不是我的 GB10 质量验收，也不能与前面的 AA-LCR v1.1 直接相减，因为该发布页没有标明使用同一 AA-LCR 版本。[8]

NVFP4 这个后缀还不足以唯一识别发布物。RadixArk 也有 Flash-Next NVFP4，但其 MTP 保留 BF16；NVIDIA 对应部分采用块量化 FP8。它们在推理引擎中的加载和分片条件不同，不能认为只要改个模型目录，就能沿用全部启动参数。[8][9]

放到双 Spark 平台，这些差别会影响加载和分片。SGLang 的项目文档专门说明了 n-gram 表的驻留、分片和 NVMe 文件化路径；GB10 使用统一内存，把表从 GPU 侧卸载到主机内存，仍可能占用同一池容量。选择哪种量化与引擎，应把模型主体、查表模块、MTP 和上下文状态一起考虑。[10]

MTP 也要按任务检查。它通过候选预测和验证争取更快输出，收益取决于候选能被接受多少、任务类型和引擎实现。判断是否开启时，应该看完整任务耗时及运行稳定性，而不是假设多预测几个 token 就一定更快。

准备交给企业使用，还要核对许可。Flash-Next 当前采用 Qwen Community License 1.0，部分模型服务和 AI 工作助手商业用途涉及额外授权，纯内部使用有相应例外。应核对实际下载版本及具体交付方式；模型能本地运行，与产品能按什么方式提供给客户，是两项不同检查。[11]

五 我的本地实测 解决的是等待问题

模型能力和量化质量之外，我还关心它在两台 ATOM 上要等多久。

我保留了短请求、32K 和 128K 的结果，这里只摘出直接影响选择的部分。首包时间是发出请求后开始收到输出的等待；输出速度用 tok/s 表示，即每秒生成多少 token。首次处理长材料与预热后再次处理，要分别看。

表 3 作者现有本地配置的关键等待

指标	Qwen3.8 Flash	DeepSeek V4 Flash 0731
短请求首包	0.13–0.17 秒	0.25 秒
128K 首次首包	42.87 秒	69–73 秒
128K 热首包	0.69 秒	0.63 秒
128K 热输出	61.8 tok/s	60 tok/s

作者部署记录；两组配置不同。同一套代码题、2048 token 输出口径，长输入一冷两热，热值取第二次。

128K 首次进入时，Qwen 等待较短；进入热请求后，两者首包和输出速度已经接近。这让“先读入一批长材料，随后持续推进”的使用方式更有吸引力。公开评测让我判断它适合哪些任务，这组实测则让我知道实际要等多久。

DeepSeek 仍有值得保留的表现：32K 热请求首包为 0.37–0.45 秒、输出为 66–73 tok/s；Qwen 对应为 0.58 秒和 63.8 tok/s。短请求两边输出区间也有重叠，不能只摘 Qwen 的一个高值就宣布全面更快。

这些是两套实际部署配置的记录，不是控制所有变量后的架构比较。NVIDIA发布方的量化质量评测与我的本地等待记录要分别看，这组速度不能用来判断哪一种NVFP4发布物更快或质量更好。它说明的是手头配置的等待体验，不能替代代码正确率或多人吞吐测试。测试方法见表3说明。

六 模型留在企业 员工在现场怎样用

选好 Qwen，还要让员工用得上。MEASIX 自托管方案要做的，是把企业已有的模型、资料、工具和工作方法组织成可用助手。下发到现场的是助手及其能力配置：使用哪个模型、参考哪些资料、可以调用什么工具、遇到什么情况需要确认。模型权重留在企业推理服务中，移动端通过内网或企业允许的连接调用。

枢策 Orchelm 负责接入模型、组织受管助手并向员工分发。围绕具体岗位，企业还需要准备相应资料、工具连接和权限。例如，测量工程师需要图纸规范和结果查询，维护人员需要说明书和维修记录；员工打开助手，就可以从与岗位相符的资料和工具开始处理问题。这些资料的版本、工具权限和适用范围，由企业统一维护。

图 4｜企业组织可用能力，员工在移动端处理现场任务。虚线表示配置分发，实线表示调用和结果；模型权重留在企业推理服务中。

现场使用的是领航 Pilot，一款内置完整 Agent 能力的移动端应用；小睿是贯穿 MEASIX 的统一助手形象与交互角色。员工拍照、发图纸，再说明眼前的问题，受管模型请求经企业的运行转发服务（Runtime Relay）送往本地 Qwen，移动端继续组织多轮讨论和工具调用。

需要查实际情况时，助手按授权访问业务工具，具体数据权限仍由业务系统执行；例如从衡准 Metrivon 读取配置和测量记录。需要整理文件、运行分析脚本或检查代码时，可使用工舱 Runcove 的独立工作空间。资料和计算结果返回当前任务，模型据此修正建议，员工能看到依据、结果与待确认项。工具报错或返回未完成状态时，也要把问题交代清楚。移动端组织交互与任务执行，企业服务完成推理和相应的数据处理。

有效方法经过验证后，可以更新到相应助手，供同岗位继续使用；项目专用数据仍按原权限管理。

七 本地模型怎样接住图文混合的现场任务

前面的能力与速度证据，让我愿意把 Qwen 用到图纸、文档和业务工具混合的任务里。本地模型“够用”，先看它能否读懂输入、给出可审阅的建议，并在可以接受的等待时间内继续工作，不必一开始就承担全部专业判断。

例如，工程师把一张图纸和现场夹具照片交进来。模型先读尺寸、公差、基准与部件关系，指出看不清或相互矛盾的地方。多模态的价值正在这里：员工不必先把每一条引线、每个局部位置都转述成文字，原图关系可以直接参与讨论。若原件是 PDF，要确认相关页以图像进入视觉模型，单纯提取文字会丢失这些关系。

图 5｜原创教学应用示意：从图纸提取要求，提出指标候选，再由工程师与真实数据核验。非已完成的生产验证。

接着结合说明书、检验规程与历史程序，模型可以整理待测项目，提出测量建议，并列出依据。比如把 Φ67（+0.076/0）整理为 67.000–67.076 mm 的范围，把端面要求与指定基准对应起来；至于装夹方式、检测位置和方法是否适合，由工程师确认。长上下文在此用于保留图纸版本、条件和已确认事项，避免每轮重新解释。

需要实际数据时，再调用业务工具查询现有配置和历史记录，让建议对上当前条件。工具返回后，模型应核对单位、引用和执行结果，交回要求清单、候选方案与待确认项。真实数据和独立复核负责检验计算；模型的作用是把资料、问题与结果接起来，减少转录和来回查找。详细工艺核对另放补充材料。

这里展示的是可继续验证的应用设计，本文没有新增生产测试成绩。

我原有的 DeepSeek V4 Flash 0731 是文本组合，图像需另做识别、转述或接入视觉；Flash-Next 可以直接接收图像，这是本次选择的一项实用差异。DeepSeek V4.1 已有原生图文能力，应另作评估。[12]

八 哪些任务值得选 Qwen 哪些仍保留对照

维修记录、财务报表和内部代码，也有类似的核对问题：图像里的字段和位置关系有没有读对，多份资料的版本与适用条件有没有保留，工具真正执行后的结果有没有回到结论里。

因此，验收本地模型时，我会拿自己的材料设计几道有明确预期的题：一处容易看错的图像标注、一条藏在旧版本资料里的限制、一次需要读回或重新计算才能发现的错误。记录模型漏了什么、需要多少人工补充和修正，以及整项任务耗时。公开成绩用来筛选候选，这些记录才决定它在本地承担什么工作。

我的选择条件很明确：已有合适本地资源，任务经常混合图像、文档、代码与工具，并且要围绕同一批材料持续工作，我会优先考虑 Qwen。原生视觉让原始图像直接进入任务，公开评测给了代码 Agent 和工具使用的依据，当前 128K 实测则让我接受长资料的首轮等待。这三项合在一起，构成了我这次的选择。

若主要是约 32K 的重复文字请求，DeepSeek 0731 仍有值得保留的热表现；普通代码题和从需求生成仓库，也应保留它的对照结果。需要 DeepSeek V4.1 的新图文能力，则另作评估，不能拿旧配置替它下结论。

选定 Qwen 之后，接下来要做的是让这些具体任务通过检验：要求读得准，关联条件没有丢，工具结果有依据，缺项能明确交给人决定。模型的能力是否真正用上，就从这些可检查的结果里看。

简要说明与来源

公开能力成绩、量化发布者评测和作者本地速度分开呈现。动态榜单采用本次核验页面；分数仅在注明的同表口径内比较。作者性能记录沿用 Qwen3.8 Flash 与 DeepSeek V4 Flash 0731 标签，两组配置不同。本文没有新增本地质量测试。企业案例依据 MEASIX 当前配置结构、工具能力和盘类模板展开，应用图为教学示意，不代表已完成生产验证；封面为 AI 生成概念插画。

[1] Qwen Flash-Next 模型卡；[2] Qwen 团队技术报告；[3] DeepSeek 0731 模型卡

[4] Artificial Analysis 同页对照；[5] AA 评测方法；[6] LiveBench 榜单；[7] MRCR 数据集说明

[8] NVIDIA NVFP4 发布物；[9] RadixArk NVFP4 发布物；[10] SGLang 部署说明；[11] Qwen Community License；[12] DeepSeek V4.1 模型卡