密集架构与多模态能力的独特性

本次测试的核心对象是 Mistral Medium 3.5,这是一个拥有 1280亿参数 的模型。与近期同量级(约120B-122B)的主流模型如 Google Gemma 4、Qwen 3.5 或 GPT OSS 120B 不同,这些竞品大多采用 混合专家(MoE)架构,而 Mistral Medium 3.5 坚持使用 密集(Dense)架构。这种架构选择带来了显著的性能权衡:理论上密集模型能提供更深层的性能表现,但代价是本地运行时对计算资源的需求大幅增加。此外,该模型具备原生 多模态能力,能够直接接收图像输入并生成文本响应。这一特性使得我们可以进行更具挑战性的测试,例如向模型展示用户界面(UI)截图,并让其直接生成对应的 UI 代码,从而同时验证其视觉理解与编程能力。

"This is a dense model. So there are pros and cons to that. Pros being that hypothetically it should pack a deeper level of performance than an alternative."

值得注意的是,Mistral Medium 3.5 旨在取代其前代产品 Mistral Medium 3.1 以及专注于代码的 Devstral 2。这种替代关系暗示了该模型在 通用任务与代码生成 方面应具备均衡且强大的能力。模型还引入了 可切换的推理模式,用户可以根据需求开启或关闭思考过程,这在本地部署时能显著节省时间。虽然官方还推出了用于加速推理的 Eagle 模型以支持推测解码,但鉴于当前测试重点,我们将主要关注基础密集模型的表现。

基准测试对比与官方数据

在深入实际测试之前,我们需要明确 Mistral Medium 3.5 在官方基准测试中的定位。根据 Mistral 官方发布的基准数据(修正了此前误开的旧版博客对比),该模型主要与 Sonnet 4.5 进行竞争对比。尽管在特定的银行领域基准测试中表现略有差异,但在大多数通用基准中,Mistral Medium 3.5 展现出了与 Sonnet 4.5 相抗衡的实力。以下是官方提供的部分关键基准测试数据对比:

模型 基准测试项目 得分/表现 备注
Mistral Medium 3.5 通用基准 (General Benchmarks) 与 Sonnet 4.5 相当 主要竞争对手
Mistral Medium 3.5 银行领域特定基准 (Banking Specific) 略低于 Sonnet 4.5 特定领域表现
Mistral Medium 3.5 代码生成 (Coding) 取代 Devstral 2 继承代码能力

官方明确表示,该模型在多个维度上都是 Sonnet 4.5 的直接竞争者。这种定位意味着我们在后续的实际测试中,将以 Sonnet 4.5 的表现作为主要参照系。由于 Mistral Medium 3.5 是密集模型,其推理速度和本地部署难度远高于 MoE 模型,因此测试将分为 本地量化运行API 代理任务 两个部分,以全面评估其在不同环境下的实际效能。

本地量化运行性能与 BrowserOS 测试

为了评估本地部署的可行性,我们在 Mac Studio M3 Ultra (256GB) 系统上加载了 Mistral Medium 3.5。测试使用了 Q4KM 量化版本,并启用了思考模式(Thinking Enabled)。在采样参数正确配置后,我们首先运行了 BrowserOS Test v2.5,要求模型构建一个浏览器操作系统界面。在推理过程中,模型输出了 <think> 标签,但由于当前环境未进行美学解析,这些标签未以传统推理窗口的形式展示,而是直接以文本形式出现。

在速度方面,我们对比了不同量化版本的表现。虽然 Q8 量化版本在该系统上的运行速度约为 5.3 tokens/秒,但 Q4KM 版本并未带来显著的速度提升,考虑到时间成本和后续 API 测试的衔接,我们决定继续使用 Q4KM 进行本地测试。在 BrowserOS 测试中,模型在思考阶段花费了大量时间,导致最终代码生成的响应被延迟。这表明在本地资源受限的情况下,密集模型的推理延迟可能影响交互体验。

API 代理任务与 C++ 滑板游戏开发

鉴于本地运行的速度限制,我们同时通过 OpenRouter API 进行了代理任务测试。API 的定价为 $1.50/百万输入 token$7.50/百万输出 token,高昂的成本促使我们对性能提出更高要求。在 OpenRouter 的服务下,Mistral Medium 3.5 的推理速度达到了 81 tokens/秒,这为复杂的代理任务提供了流畅的体验。

我们执行了一个 自包含的 C++ 滑板游戏 开发测试。模型在 Plan Mode 下启动,成功编写了游戏代码。尽管在编译过程中出现了一些错误,且模型需要搜索特定依赖项以解决系统兼容性问题,但它能够识别工具使用问题并制定修复计划。例如,模型检测到写入工具的问题,并尝试通过搜索和规划来修正依赖关系。最终,模型成功输出了可运行的滑板游戏代码,证明了其在 复杂代理任务 中的有效性和鲁棒性。尽管 API 成本较高,但 81 tokens/秒 的速度和成功的代码生成结果,展示了该模型在云端部署时的强大能力。

"I am more inclined to judge it harshly as running through the API because of the associated costs being fairly steep."

总结而言,Mistral Medium 3.5 作为一个 128B 密集多模态模型,在代码生成和代理任务中表现出色,但本地部署面临速度和资源挑战,而 API 部署则提供了高性能但伴随较高成本。

本地模型修复滑板游戏的困境与上下文消耗

测试者首先尝试让本地运行的 Mistral Medium 3.5 模型修复一个滑板游戏的图形错误。尽管模型具备多模态能力,测试者提供了游戏截图以辅助其理解问题,但模型表示无法直接查看图像,只能依靠文字描述。测试者描述了“所有东西都乱套了”的严重图形问题,模型随即开始尝试修复。随着修复过程的进行,模型的上下文窗口使用率迅速攀升,达到了 140k tokens,占用了约 50% 的容量。这是一个显著的信号,表明在处理复杂的多轮调试任务时,长上下文长度对模型的性能和稳定性提出了巨大挑战。经过长时间的编译尝试,虽然最终没有报错,但生成的游戏画面依然存在问题,出现了奇怪的绿色旋转物体,且由于场景复杂度(如木板路美学)可能干扰了模型判断,导致结果不如简单的滑板公园测试理想。测试者认为,这一结果并不理想,部分原因也源于测试过程中的急躁情绪。

思维链代码生成的意外突破与功能验证

为了对比效率,测试者转而通过 OpenRouter 接口使用 Web 聊天界面进行“浏览器操作系统”测试,发现其推理速度显著更快。回到本地 LM Studio 环境,测试者观察到模型在 <thinking> 标签内生成了长达 874 行的完整脚本代码,这通常是思维链推理的一部分。测试者决定冒险直接复制这段包含在思维链中的代码并执行,结果令人惊讶:代码成功运行并生成了一个具备基本功能的浏览器操作系统界面。该界面包含了右下角的时间显示、简单的背景以及任务栏。测试者进一步验证了 Start Menu(开始菜单),其中列出了所有应用程序。尽管窗口大小存在缺陷,但核心功能如 GTA 克隆游戏、太空射击游戏、终端、文本编辑器和计算器均被生成。其中,GTA 克隆游戏虽然窗口过小,但包含了建筑、基本车辆模型,且车辆转向和移动机制具有一定趣味性,这在一定程度上满足了测试预期。

本地 Q4KM 与 OpenRouter 云端版本的横向对比

测试者将本地运行的 Q4KM 量化版本与通过 OpenRouter 提供的 Mistral 云端版本进行了详细的功能对比。两者在生成浏览器操作系统方面表现出高度相似的结果,这证明了本地量化模型在特定任务上的有效性。对比结果显示,两个版本的壁纸功能均出现故障,可能由于使用了失效的 Unsplash 图片链接。然而,OpenRouter 版本的文件管理器 UI 更为美观,呈现出类似 Windows XP 的风格。在核心应用测试中,GTA 克隆游戏在两个版本中表现几乎一致,进一步印证了本地模型的性能稳定性。此外,OpenRouter 版本还生成了一个 3D 迷宫游戏,测试者能看到绿色的迷宫元素,但视角控制存在严重缺陷,无法正确观察游戏内容。总体而言,尽管云端版本在 UI 细节上略胜一筹,但本地模型在核心逻辑生成和功能实现上并未落后,Q4KM 量化版本在保持较低资源占用的同时,展现了与云端服务相近的实用能力

关键数据与配置对比总结

在本次测试中,主要涉及了本地运行环境与云端服务的对比,以及模型在处理不同任务时的资源消耗情况。以下是关键配置与性能表现的详细数据记录:

测试项目 本地运行 (LM Studio) 云端运行 (OpenRouter) 备注/差异
模型版本 Mistral Medium 3.5 Mistral Medium 3.5 同一模型架构
量化格式 Q4_K_M 未指定 (云端原生) 本地为量化版本
上下文消耗 140k tokens (约 50% 容量) 未记录具体数值 本地滑板游戏修复任务中
代码生成行数 874 行 (思维链内) 未记录具体行数 本地浏览器 OS 脚本
GTA 克隆游戏 窗口过小,有建筑/车辆,移动有趣 表现类似 核心功能均实现
壁纸功能 失效 (可能链接问题) 失效 (可能链接问题) 两者均无法加载壁纸
文件管理器 UI 简单列表 美观,类 Windows XP 风格 云端版本 UI 更佳
3D 迷宫游戏 未生成/未测试 生成,但视角无法控制 云端版本有额外功能但体验差
推理速度 较慢 显著更快 云端接口响应更及时

“This was all remember contained from within the chain of thought, but it basically generated the entire script prior to finalizing its thought process.”

“Overall really a very similar result between the two which actually speaks well to the performance of the local Q4KM that we have running.”

视觉生成与前端设计能力测试

测试者首先向 Mistral Medium 3.5 提供了一张由 Nano Banana 生成的高端网站设计参考图,要求模型基于该图片创建一个高质量的网站。尽管模型正在推理中,但这一过程旨在检验其视觉理解能力前端设计审美的结合效果。最终生成的 Mockup 虽然包含了一些预期的视觉元素,如顶部的 "Get Started" 效果、悬停交互以及类似客户满意度评价的模块,但存在明显的功能缺陷。图片链接全部失效,导致本应展示的 Google、IBM、Microsoft 等示例公司 logo 无法加载。测试者指出,模型虽然捕捉到了参考图的某些美学特征,但未能完全复刻,这可能是因为参考图由三张独立图片组成,整合难度较大。

"Unfortunately the image links here are broken which definitely is going to let a result like this down regardless of what happens."

静态场景渲染与代码调试挑战

随后,测试者尝试让模型创建一个静态的地铁场景,以进一步评估其代码生成能力。初始生成的代码在浏览器中运行时出现了严重问题,包括指针移动延迟控制台报错。通过开发者工具,测试者发现错误主要源于非 Python 服务器环境下的 "nothing error" 以及后续代码行中的语法错误。在手动修复代码并刷新后,场景的美学表现尚可,背景具有类似夜间派对房间的发光效果,亮度滑块功能也正常。然而,当测试者尝试在 "Plan Mode" 下让模型进一步改进并添加 FPS 游戏机制时,情况急转直下。模型在编辑过程中导致文件损坏,生成的结果变得不可用且显著劣化,测试者因此放弃将其转化为 FPS 游戏的尝试,认为该模型在自主修复复杂代码逻辑方面存在明显短板。

本地量化模型性能与浏览器 OS 生成

在浏览器操作系统(Browser OS)的测试中,测试者对比了通过 OpenRouter 服务与本地运行 Q4K 量化版本的效果。本地运行的 Q4K 版本在生成速度上记录为 31,000 至 32,000 个 token,生成速度约为 7.23 tokens/秒。虽然这一速度被评价为 "passable"(可接受),但测试者主观感觉整个生成过程耗时接近或超过一小时。在视觉效果上,本地 Q4K 版本生成的 Browser OS 被认为优于 OpenRouter 版本,其背景采用了独特的管状风格,右下角的时钟显示正确时间,且开始菜单的美学设计更为出色。然而,测试者也指出,这种美学提升是以牺牲部分功能性为代价的,例如右键菜单功能缺失,且模型出现了重复打开窗口的逻辑错误,显示出其在功能完整性视觉美观之间的权衡问题。

创意写作与多模态文本生成

鉴于 Mistral 模型在创意写作领域的声誉,测试者禁用了推理模式以节省时间,并引入了一张历史照片作为输入,要求模型生成书籍标题及章节大纲。这一测试旨在结合多模态输入与创意文本生成能力。虽然字幕片段在此处中断,但测试逻辑表明,测试者希望验证模型在非推理模式下,能否有效利用视觉信息辅助文学创作。这一环节与之前的代码和视觉测试形成对比,侧重于评估模型在叙事结构创意构思方面的表现,而非技术实现或代码执行能力。

角色扮演与创意交互测试:信任考验的超预期表现

在针对 Mistral Medium 3.5 的首轮测试中,角色扮演(Roleplay)环节展现出了令人惊喜的创意深度与逻辑连贯性。测试者设定了一个充满张力的黑帮风格场景,要求模型扮演一名手持水枪的谈判者,对名为 Stevie 的目标进行“信任测试”。模型不仅精准地执行了动作指令(如从枪套中取出水枪、发射两股水柱),还通过细腻的心理描写和对话,构建了极具画面感的叙事。Stevie 的反应从愤怒到无奈苦笑,再到最后的调侃,整个交互过程流畅自然,角色的情感转变与语言风格高度统一

测试者对这一结果评价极高,认为其创意能力超出了预期。特别是在赋予模型“方向性选择”(即决定下一步剧情走向)的能力时,模型能够灵活应对,展现出极高的教育价值和娱乐性。这种在复杂情境下保持角色一致性并推动剧情发展的能力,证明了该模型在自然语言生成和情境模拟方面的强大潜力。正如测试者所言:

"I will say the roleplay capability here exceeded expectations to a rather high degree. It was incredibly creative, especially because we gave it the directional choice on where to go."

3D 打印机模拟测试:本地量化版优于云端服务

在技术模拟测试中,3D 打印机模拟环节暴露了云端服务与本地运行之间的显著差异。测试者原本计划通过 Open Router 运行该测试,但由于网页加载错误频发,转而同时在本地 LM Studio 环境中运行 Q4KM 量化版本(关闭思维链功能)进行对比。结果显示,本地运行的 Q4KM 版本产生了比云端服务更稳定、更直观的结果

尽管本地生成的 3D 模型存在视角固定、无法旋转查看的问题,但其核心功能——喷嘴逐层移动并构建倒金字塔形状的过程——清晰可见且运行正常。相比之下,云端版本因加载问题未能提供有效反馈。这一发现引发了测试者对模型量化后性能保持能力的关注。虽然测试样本有限,但数据显示,Q4KM 量化并未导致性能的大幅衰减,甚至在某些特定任务上优于未经充分优化的云端部署。这种本地与云端的性能倒挂现象,为后续模型部署策略提供了重要参考。

飞行战斗与鼓组模拟:功能可用但细节粗糙

飞行战斗模拟器测试在 Open Router 上首次尝试即成功运行,但视觉效果存在明显缺陷。测试者观察到,虽然云层渲染尚可,但飞机模型(包括战斗机螺旋桨和双翼机)均顺时针旋转了 90 度,导致姿态异常。此外,场景中缺乏敌机交互,功能完整性不足。尽管如此,模型仍能生成可工作的基础代码结构,体现了其一定的代码生成能力。

随后的鼓组模拟测试则展示了模型在多媒体交互上的局限性。测试要求模型实现自动播放功能,但初期结果中声音缺失。经过错误反馈修正后,模型自动回退至 2D 模式以兼容环境,虽然解决了加载问题,但键盘映射功能失效,用户需盲猜按键。自动播放功能仅部分工作,摇滚节拍未能完整呈现。测试者总结认为,代码生成并非该模型的强项,多数结果需要人工干预才能修复,且最终效果往往不如预期。例如,在切换至 Open Code 环境后,结果反而显著恶化,进一步印证了其在复杂编程任务上的不稳定性。

综合评估:量化鲁棒性与编程短板

综合各项测试结果,Mistral Medium 3.5 在创意写作和基础模拟任务上表现优异,但在精确的技术实现和代码优化方面存在明显短板。测试者指出,模型对量化处理的鲁棒性较好,Q4KM 版本在本地运行时的表现甚至优于部分云端服务,这表明其架构在压缩后仍能保持核心逻辑的完整性。然而,在需要高精度逻辑和复杂交互的场景中(如飞行模拟的姿态校正、鼓组的按键映射),模型往往需要多次迭代才能接近可用状态。

测试者最终结论是,不应将该模型视为编程专家,其优势更多体现在自然语言理解、创意生成和基础模拟上。对于开发者而言,若需使用此模型,建议结合人工审查与多轮调试,特别是在涉及具体功能实现的代码生成任务中。尽管存在不足,其在角色扮演和情境模拟上的卓越表现,仍使其成为创意写作和互动娱乐领域的有力候选者。

"I don't find that coding is probably going to be the strong suit for this model. A lot of the results we received had needed some help initially... the result ended up being significantly worse than what we see here, which was a little disappointing."

量化表现与本地运行体验

在本次对 Mistral Medium 3.5 128B 密集开源模型的初步测试中,本地量化版本的实际表现令人印象深刻。特别是在使用 Q4KM 量化格式时,模型在本地环境下的运行流畅度与云端托管版本相比,展现出了极高的兼容性,能够较好地处理各种软件相关的任务,甚至包括之前看似有潜力的 C++ 滑板游戏开发场景。这种本地部署的稳定性表明,量化技术有效降低了硬件门槛,使得大模型在个人设备上也能保持较高的可用性。

"it did seem to handle itself quite well with the Q4KM quant comparatively to what's hosted by the cloud."

尽管整体表现良好,但推理速度仍是受限于硬件架构的关键因素。在 M3 Ultra Max Studio 256GB 统一内存系统上,Q4KM 量化版本的生成速度约为每秒 7.5 个 token。这一速度对于某些复杂任务来说略显吃力,但对于日常交互而言尚可接受。值得注意的是,当切换到 Q8 量化版本时,速度进一步下降至每秒约 5 个 token。这证实了128B 密集模型在统一内存系统上的性能瓶颈,尤其是在追求更高精度时,速度损失较为明显。

创意写作与角色扮演能力评估

在功能测试方面,创意写作和角色扮演(Role-play)被确认为该模型的显著优势领域。测试中采用的“Stevie 电脑维修工”角色扮演案例极具代表性,展示了模型在开放-ended 指令下的高度创造性和幽默感。通过赋予模型大量的自由发挥空间,其生成的回复不仅逻辑自洽,而且充满了趣味性,甚至被评价为“非常搞笑”。这一案例有力地证明了 Mistral Medium 3.5 在非结构化、高自由度文本生成任务中的强大潜力,使其在娱乐性应用和创意辅助方面具有独特价值。

性能数据汇总与测试结论

综合来看,Mistral Medium 3.5 128B 是一款在创意领域表现优异但受限于本地推理速度的大模型。以下表格详细列出了在 M3 Ultra Max Studio 256GB 硬件上的关键性能数据,供读者参考:

量化格式 推理速度 (Tokens/秒) 性能评价 适用场景建议
Q4KM ~7.5 中等,略显吃力 创意写作、角色扮演、日常对话
Q8 ~5.0 较慢,精度更高 需要更高逻辑精度的复杂任务

"The Stevie the PC repair man roleplay was quite entertaining and um very fun to see where it took it... it was quite hilarious."

测试总结指出,虽然7.5 tokens/秒的速度在运行复杂任务时可能显得较为吃力,但考虑到其 128B 的参数量级以及在统一内存系统上的运行能力,这一性能表现符合预期。对于追求极致速度或处理极高复杂度任务的用户,云端部署或更高性能的硬件可能是更好的选择;但对于创意写作、角色扮演及一般性对话,本地运行的 Mistral Medium 3.5 提供了极具吸引力的性价比和趣味性体验。