DeepSeek V4.1 Flash实测：不是模型拉了，是你没用对

DeepSeek V4.1 Flash发布后，网上到处都是"速度巨快""能力超过V4 Pro"的说法。一位B站UP主抱着极高的期待实测了5天，把自己所有工作流都接了进去，烧掉了好几亿token，最后却得出一个反直觉的结论：一开始觉得这模型"串稀玩意儿"，后来又觉得"夯得不得了"——问题不在模型，而在用法。

速度确实起飞了

UP主用API用量图开门见山地说明了态度：DeepSeek^广告 V4 Flash自涨价后基本被冷落，一天只有小几刀，主要用于配置本地模型和矩阵测试。而V4.1 Flash上线后，趁着OpenCode限时4倍用量的活动，他的用量又逐渐涨了回来。

用量是最真实的反馈——好用、性价比高，自然就用得多。

速度的提升是最先能感知到的。他用了个很形象的对比：以前形容本地模型慢是"便秘"，四五十token每秒，"拉也拉不出来"。V4 Flash在OpenCode上大约150 token/秒，已经算舒畅；而V4.1 Flash基本稳定在230-250 token/秒，有的session接近300 token/秒，"快得跟拉稀一样"，工具调用速度快到眼睛跟不上，一页还没反应过来就被刷满了。

快，但一开始并不好用

速度不代表好用。UP主把工作流迁到DeepSeek Harness后，立刻遇到了麻烦。

第一个任务是让模型理解他那套略微复杂的本地AI部署（Harness在云端、本地gateway在服务器、Llama等配置在本地主机）。他在一个此前用V4 Flash跑过多轮的session里"热切换"成V4.1，结果模型疯狂窜稀式输出，工具调用了几十次、思考了几十回，盯了三分钟一个字都没吐出来。

他停掉后新开会话，同样的指令切到本地千问，一分钟就搞定。回头再用V4.1新开会话重试，30秒完成，速度270 token/秒。

结论浮出水面：旧session的上下文被污染了。哪怕V4.1有100万上下文，硬切模型继承旧对话也可能翻车。这一点其实Codex也早有提醒——在会话中硬切模型，后续对话质量可能下降。

上下文污染（Context Pollution） 是指在一个已有对话历史的会话中切换模型时，新模型会继承旧模型留下的中间状态、工具调用记录和错误假设，导致推理路径从一开始就走偏。大语言模型在生成回复时会将整段上下文作为输入，旧会话中残留的模型特定格式、调用约定或错误信息，对新模型而言相当于"带着污染的先验"，即便新模型本身能力更强，也难以从错误前提中自我纠正。这也是为什么即使 V4.1 Flash 支持高达 100 万 token 的超长上下文，热切换后表现反而更差——更长的上下文意味着模型需要处理更多已污染的信息，反而放大了问题。解决方式通常是新开一个干净会话，让模型从零开始建立对任务的理解。

一个奇怪的"性格"

更让人费解的是模型的行为模式。UP主发现，即便是全新的干净会话，V4.1 Flash也经常"不听话"：下达任务后它不是先看skill再干活，而是扫一眼技能、读一个不正确的技能，然后开始暴力翻他过往的session历史记录，翻完DeepSeek Harness的还不甘心，跑去隔壁Hermes的聊天数据库里继续爬。

这不是偶发现象。有一次配置本地模型框架，它直接在接近2G、几十万条信息、上千轮对话的Hermes数据库里暴力搜索了10分钟，找到相关信息后还要反问"你是不是这个"，确认后才开干。

就连写稿这种简单任务也一样——一篇口述稿件，别的模型（V4或本地千问3.8）直接就能续写，V4.1却触发了32次工具调用，其中12次又在爬过往session。换成V4 Flash只需5次调用、30秒进入工作状态。

UP主的体感推测是：当上下文给得不够精确时，V4.1有一种内在动力，要先把事情调查清楚再动手。这可能是好事——它最终确实能把活干好，甚至比V4 Flash更快、更周到，改bug时连回归问题都能顺手处理。但每次都要人提醒"先看skill再干活"，用起来就很累，像退回到上一代agent的体验。

工具调用（Tool Calling / Function Calling） 是指大语言模型在推理过程中，主动调用外部工具（如搜索、数据库查询、代码执行、文件读取等）来获取信息或执行操作，而非仅依赖训练时的静态知识。在 Agent 框架中，工具调用次数往往直接影响任务完成的效率和成本——每次调用都消耗延迟和 token 预算。理想情况下，模型应该根据任务需求精准调用，避免冗余探索。V4.1 Flash 在上下文信息不够精确时触发大量"探索式"工具调用，本质上是模型在主动降低不确定性，这在复杂任务中是合理策略，但在简单任务中会造成明显的效率损耗，体感上像是"绕远路"。Harness 在此语境下指 AI 的任务编排与 Agent 运行框架，负责管理会话、技能（skill）、工具权限和上下文注入，不同 Harness 对模型行为的约束和引导方式不同，直接影响模型的"执行风格"。

换回Hermes，体验天翻地覆

UP主坚持一个理念：没有垃圾的模型，只有不会用的人。在V4 Flash和本地千问3.8这个档次之上，模型已经比99.9%的人更聪明、能干、快速，如果觉得不好用，大概率是用法的问题。

于是他把冷落多日的Hermes叫了回来。换回Hermes后，V4.1 Flash"呼风唤雨、指哪打哪"的感觉立刻回来了，而且体感比V4 Flash能力更强、速度更快。

他随后在Hermes上开了40多个会话、5000多条消息，完整跑了一遍日常工作：写稿、改稿、配图、矩阵测试千问3.8新框架及并发优化、改造Hermes Desktop、改各种网站前端和电商后台。最硬核的一项是把云端服务器从一个服务商整体搬到另一个服务商——这活儿他自己干至少要两三天甚至一周，这次除了开账号付款没动一根手指，全交给V4.1 Flash，从早上5点干到下午两三点，完美收工。

用对Harness，比换模型更重要

同一个模型，在DeepSeek Harness里像匹驾驭不住的"串天猴"，切回Hermes却成了他用过最好用的模型。UP主坦言自己还没有定论，但倾向于认为不是DeepSeek Harness不行，而是他现在的工作流和习惯更适合养了很久、"早就成精"的Hermes——两套Harness在技能兼容性上可能存在问题。

这个案例的价值恰恰在于诚实：一个模型的价格高低、能力好坏，每个人、每个时刻的感受都不同，会随时间和用法而变化。同一个人只是换了个Harness，对V4.1 Flash的评价就能从"串稀玩意儿"翻转到"夯得不得了"。

API用量是最诚实的指标——好用、性价比高就会用得多，前提是你用对了方式。没有法律规定所有人必须用同一个模型、同一个Harness，找到与自己工作流匹配的组合，比盲目追新更重要。