为什么要在本地跑 DeepSeek V4-Flash？
想在本地跑大模型的理由通常很朴素：Agent 场景下一个任务要拆成好几轮工具调用，API 账单跟着轮数往上翻，多跑几次就肉疼；再加上不想让公司文档或私人对话经过第三方服务器，离线也能用更踏实。手头正好有一台 8GB 显存的旧游戏本和一台纯 CPU 的 Mac mini，本来想拿它们做个本地部署的双环境对比。
但查完硬件门槛就发现这条路走不通。DeepSeek 官方模型卡与 Ollama 的模型库口径一致：V4-Flash 是 DeepSeek-V4 系列的一部分，284B 总参数、13B 激活参数的 MoE（Mixture-of-Experts，混合专家架构，即把一个大模型拆成许多小的“专家”模块，每次推理只激活其中一小部分参数，从而省显存、跑得快）模型，支持 1M token 上下文。这个体量意味着，光是加载 Q4_K_M 这种主流量化版本的权重，就需要约 95.2GB 显存，若要留出 KV 缓存和系统开销的余量，业内建议准备 124GB 以上；另一份独立核算给出的数字更保守，在 8K 上下文下 Q4_K_M 大约要占 174GB 显存，Q8 约 303GB，目前没有任何一张单卡消费级显卡能完整装下这个模型。
8GB 显存、16GB 统一内存，离这个门槛差着一个数量级，不是能不能流畅运行的问题，是权重文件根本装不进去。于是最初“找台旧设备验证本地 Agent”的计划，第一步就撞了墙。真正能测的问题变成了：这两台装不下模型的设备，还能不能用来验证 V4-Flash 号称的 Agent、Codex、Responses API 这套新能力？答案是可以，但跑的是官方云端 API，不是本地权重——这也是这篇文章接下来实际记录的内容。
两条技术路线：Ollama 一键党 vs llama.cpp 折腾派
原计划里，Ollama 负责纯 CPU 的 Mac mini，llama.cpp 负责 8GB 显存本做极限量化压榨。查完两边的现状，这个分工也得重写。
先看 Ollama。Ollama 官方模型库里 deepseek-v4-flash 目前只挂了一个标签：deepseek-v4-flash:cloud。这个 :cloud 后缀不是某种量化格式，而是 Ollama 自己的云端代理功能——命令行界面还是熟悉的 ollama run，但推理实际在 Ollama 的服务器上跑，本地设备只负责发请求、收结果。换句话说，连 Ollama 官方都没有为这个模型准备一个能在本地显卡上真正跑起来的版本。
llama.cpp 这边的进展更真实一些。主线仓库通过 编号 24162 的 Pull Request 合并了对 DeepSeek V4 架构的支持，这套架构里最特殊的部分是两种新的压缩注意力机制——CSA（压缩稀疏注意力，把每 4 个 token 压缩成 1 个来降低计算量）和 HCA（重压缩注意力，压缩粒度更大，用于处理超长上下文）。但社区实测的硬件门槛依旧吓人：有开发者在 96GB DDR5 内存、RTX 3090 Ti 24GB 显存、AMD 9950X 处理器的机器上，用 IQ2_XXS 这种 2-bit 极限量化，短上下文下跑出约 150 tokens/s 的提示词处理速度和 15 tokens/s 的生成速度；另一位在 128GB 内存加 A5500 显卡的 ThinkPad P16 上，生成速度是 6.5 tokens/s。这些配置本身就远超 8GB/16GB，用的还是官方并不推荐、损失较大的极限量化。
所以本文实际验证的两条路线，变成了另外两条：一是用官方 API 配合 OpenAI SDK 直连 Responses API；二是把 VS Code、Cursor 里原本指向 Codex 云端的 Endpoint，换成 DeepSeek 的官方地址，验证它能不能当 Codex 的平替。两条路线的共同点是——显卡和内存大小已经不重要了，重要的是网络和 API Key。
从安装到第一次 Agent 调用
环境 A（8GB 显存笔记本、Ubuntu）和环境 B（Mac mini、macOS）这次的角色变了：它们不再是用来装模型权重的容器，只是两台发 HTTP 请求的客户端，理论上任何能装 Python 或 Node.js 的设备都能替代。
具体步骤是：在 DeepSeek 开放平台申请 API Key，安装 openai 这个 Python 包（pip3 install openai），把 base_url 指向 https://api.deepseek.com，model 参数设为 deepseek-v4-flash。用 Responses API 的调用方式是 client.responses.create()，不是老式的 chat.completions.create()——DeepSeek 官方文档写明，Responses API 目前只支持 deepseek-v4-flash，deepseek-v4-pro 的支持要到 2026 年 8 月初才上线；流式返回也不再是 SSE（Server-Sent Events，服务器主动向客户端推送数据流的协议）里熟悉的 data: [DONE] 结束标记，而是换成了带序列号的 response.completed / response.incomplete / response.failed 几种事件，这是照搬 OpenAI 旧代码时最容易漏掉的一处改动。
VS Code、Cursor 那边的配置本质上就是换一个 Endpoint 地址。DeepSeek 从 7 月 31 日的 0731 版本开始，原生支持 Responses API 协议，并针对 Codex 风格的智能体做了适配，包括 Codex 依赖的 apply_patch 这个文件编辑专用工具。在这之前，想把 Codex 接到 DeepSeek 上得自己搭一层转发代理——社区流传的方案是在本地 127.0.0.1:38440 起一个转发服务，在 Codex 使用的 Responses 协议和 DeepSeek 当时只支持的 Chat Completions 协议之间做翻译，现在这层代理原则上可以省掉了。
核心能力实测：Agent / Codex / Responses API 三件套
先看 Agent 多工具调用。DeepSeek 公布的基准数据显示，0731 版本相比 4 月的预览版，在 DeepSWE 这项基准上从 7.3 分跳到 54.4 分，涨幅约 645%；Terminal-Bench 2.1 拿到 82.7 分，Toolathlon 拿到 70.3 分。要强调的是，这些都是 DeepSeek 自己公布的成绩，目前还没看到独立第三方复现的对照数据，阅读时应按“官方宣称”对待，而非行业公认结论。真正值得琢磨的不是分数本身，而是这次提分完全靠重新训练，模型架构和参数量与预览版一字不差。这对工程判断的启示是：同一个模型光靠调整后训练方法，Agent 能力就能翻好几倍，说明当前限制开源 Agent 模型表现的瓶颈更多在训练配方而不是参数规模——对算力有限的团队，这其实是个机会，因为它说明继续堆参数不是唯一出路。
再看 Codex 兼容性和 Responses API 的坑。原生 Responses API 支持目前只覆盖 deepseek-v4-flash 一个模型，deepseek-v4-pro 还没跟上，这个限制在选型阶段很容易被忽略——如果一个 Agent 框架里既要用 Flash 做高频调用又要用 Pro 做复杂推理，协议层就得两套逻辑并存，不是换个模型名就能无缝切换。字段层面的兼容问题也不只是假设：开源 Agent 框架 OpenHands 上有一条已提交的 Bug，指出 DeepSeek 模型在思考模式下进行多轮对话时，如果客户端没有把上一轮返回的 reasoning_content 字段原样传回去，API 会直接拒绝请求。这是那种“第一轮 demo 很正常，第二轮突然报错”的典型协议兼容性问题，接入任何 Agent 框架时都值得专门测一遍多轮场景，而不是只测单轮对话。
费用和并发是另一个容易被评测文章忽略、却更早在生产里踩坑的点。官方报价是输入每百万 token 0.15 美元、输出每百万 token 0.29 美元，大约是 V4-Pro 的三分之一；并发上限方面，Flash 支持 2500 个并发请求，是 Pro 的 500 个的 5 倍。对需要频繁多轮调用工具的 Agent workload 来说，并发上限往往比跑分表更早成为实际瓶颈，也是发布通稿里最容易被一笔带过、却最该被工程师盯紧的一行数字。测试过程中还应该记录每次请求的 TTFT（Time To First Token，从发出请求到模型吐出第一个字符的等待时间，是 API 调用体感速度的核心指标），这个数字受网络链路影响很大，同一份代码在国内和跨境网络下的表现可能完全不同。
到底值不值得折腾？适合谁、不适合谁
先说结论：如果诉求真的是数据不出内网、彻底离线，DeepSeek V4-Flash 目前对个人和小团队都不现实——它的下限是 95GB 以上显存或内存，这已经是工作站甚至服务器级别的配置，8GB 显卡、16GB 内存的设备连权重都装不下，根本谈不上体验好不好。这类硬件真正能做的，是通过官方云端 API 把 Agent、Codex、Responses API 这几项新能力摸一遍，本质上和调用 GPT 或 Claude 的 API 没有区别，只是多了一层“权重开源、MIT 协议”的心理安慰，数据依然要出本地机器。
适合谁：想低成本验证 Agent/Codex 兼容性、对云端调用没有心理负担、看重 0731 版本较低单价的开发者，尤其是已经在用 Codex 或类似工具、想换个更便宜后端试试的人。不适合谁：真正需要私有化部署、离线可用，或者需要在 Pro/Flash 之间无缝切换协议的团队——这两类需求分别对应“先凑够 128GB 以上内存的机器”和“等官方把 Responses API 覆盖到 V4-Pro”，短期内都绕不开。
长期看还有一层隐患：即使真凑齐了硬件把权重跑起来，本地版本也不会跟着 API 侧的后训练更新走——0731 这次的能力提升目前只发生在 API 里，Hugging Face 上摆着的开源权重一度还是 4 月的预览版，这个版本差会一直存在，直到官方把新权重放出来为止。对追求“本地部署等于永久可控”的用户来说，这恰恰是最反直觉的一点：开源权重给了你所有权，但没有给你和云端同步的能力。
我们来聊一聊
正方：本地权重装不下不重要，重点是官方 API 把 Agent、Codex、Responses API 这些新能力打包好了，普通开发者不用等硬件降价就能验证，MIT 协议至少保证了未来自建的自由。
反方：说好的“本地部署”变成了“换个 Endpoint 调 API”，跟直接充值 GPT 或 Claude 有什么本质区别？MIT 协议在 95GB 显存门槛面前，对大多数人只是一句空话。
你更看重哪一种“本地”——是权重真的握在自己手里，还是只要工具链（IDE、CLI）跑在本地、调用便宜就够了？如果是后者，你还会在意开源协议是 MIT 还是别的吗？
热门跟贴