8.0
热点
AI SCORE
模型发布2026-08-13 16:27
DeepSeek V4 Pro 0813发布：1M上下文+工具调用+Thinking模式
dev.to · AI#DeepSeek#长上下文#Coding Agent
Editor brief · 编辑速览
API模型ID不变自动调度新版本，支持100万token上下文、38.4万token输出、JSON输出、Tool Calling和Anthropic兼容接口，特别适合Coding Agent和长上下文应用。
DeepSeek 将其旗舰模型 DeepSeek V4 Pro 更新为 DeepSeek-V4-Pro-0813。
如果你已经接入了 deepseek-v4-pro，有一个重要细节需要注意：
你不需要修改模型名称。
API 模型 ID 保持不变：
deepseek-v4-pro
使用此模型 ID 的请求现在会自动访问最新的 DeepSeek-V4-Pro-0813 版本。
对于从事编码 Agent、复杂推理、长上下文应用或多模型 AI 系统的开发者来说，这次更新值得关注测试。
让我们来看看目前已知的信息。
当前 V4-Pro API 具备一些令人印象深刻的技术规格：
这一组合使得 V4-Pro 对于超越简单聊天机器人场景的工作负载尤其有意思。
V4 家族最大的特性之一是其 100 万 token 上下文窗口。
对于一个典型的聊天应用，你可能根本不需要那么多上下文。
但对于 Agent 而言，这改变了可能性的边界。
编码 Agent 可能需要同时处理：
System instructions
+
Repository structure
+
Source files
+
Documentation
+
Tool outputs
+
Terminal logs
+
Previous actions
+
Current task
长上下文并不会自动让 Agent 变得更好，但它为开发者提供了更大的空间，去构建需要在大规模信息上进行推理的系统。
文档分析领域同样适用。
开发者不再需要将一切激进地拆分成细小的块，理论上可以向模型提供大得多的上下文片段。
DeepSeek V4 Pro 同时支持思考模式和非思考模式。
这很有用，因为并非每个请求都需要同等程度的推理。
简单信息提取
↓
非思考模式
复杂编码问题
↓
思考模式
困难的 Agent 任务
↓
思考模式 + 更高推理投入
对于复杂任务，DeepSeek 还支持控制推理投入程度。
这为开发者提供了除简单切换模型之外的另一个优化维度：
质量 vs. 延迟 vs. 成本。
对于 Agent 尤其有价值，因为同一个工作流中可能同时包含 trivial 和极具挑战性的步骤。
现代 AI 应用正越来越多地从：
提问 → 获取回答
转向：
给模型一个目标 → 让它使用工具 → 完成任务
例如，编码 Agent 可能需要：
搜索相关代码
决定要修改什么
此时，原始的基准测试智能只是模型质量的其中一个维度。
同样重要的还有：
指令遵循能力
长时一致性
每个完成任务的成本
这就是为什么我特别有兴趣在真实的 Agent 工作负载中测试 V4-Pro-0813，而不是只看基准测试截图。
V4-Pro 现在也支持 Responses API。
这对于构建新一代面向 Agent 应用的开发者来说意义重大。
不同开发者已经在使用不同的 AI API 约定：
OpenAI-style Chat Completions
Responses API
Anthropic / Messages-style APIs
支持这些格式可以减少将同一个模型连接到不同框架和开发者工具所需的工作量。
这也与我们目前在 ApiHub 上做的事情密切相关。
截至发稿，DeepSeek 公布的 V4-Pro API 定价为：
作为对比，V4-Flash 仍然便宜得多，因此两个模型服务于不同目的。
一种实用的架构可能长这样：
Incoming request
↓
Is this a difficult task?
↓
Yes No
↓ ↓
V4-Pro V4-Flash
当然，真实的路由可以更加精细。
你还可以考虑：
所需能力
一个重要注意事项：DeepSeek 目前表示计划在未来大幅提高整体 API 定价。
所以当前价格可能不会保持不变。
我们也将 DeepSeek V4 Pro 添加到了 ApiHub。
如果你想在不重建现有 AI 集成的条件下试验新模型，可以使用你的 ApiHub 免费额度来体验。
ApiHub 支持多种集成方式，包括：
OpenAI 兼容 API
所以你可以使用最适合当前应用或开发工具的格式。
例如，使用 OpenAI SDK：
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["APIHUB_API_KEY"],
base_url="https://api.apihub.ink/v1"
)
response = client.chat.completions.create(
model="deepseek-v4-pro",
messages=[
{
"role": "user",
"content": "Analyze this architecture and suggest potential scaling bottlenecks."
}
]
)
print(response.choices[0].message.content)
如果你的应用已经围绕某个兼容 API 构建，测试另一个模型可能只需要修改模型 ID 这么简单。
我觉得有趣的不只是又一个更强的模型诞生了。
而是模型格局变化的速度实在太快。
不久前我们刚经历了 V4-Flash 重大更新。
现在 V4-Pro 也更新了。
明天，DeepSeek、Qwen、GLM、MiniMax 或其他提供商推出的另一个模型可能就会成为特定工作负载的更优选择。
这使得多模型策略越来越有吸引力。
开发者可能会越来越多地问：
这个特定任务我应该用哪个模型？
也许是 V4-Pro 处理最困难的推理任务。
也许是 V4-Flash 处理高容量任务。
也许是另一个模型在视觉方面更强。
也许是另一个模型提供更好的延迟。
模型进步得越快，保持模型层的灵活性就越有价值。
这是我们构建 ApiHub 的原因之一。
并不是假装每个模型都相同，而是让开发者更容易地访问、测试、比较和切换模型，而无需每次都重建应用。
我特别想看看 DeepSeek V4 Pro 0813 在以下场景中的表现：
长上下文分析
多步自动化
如果你想测试，DeepSeek V4 Pro 现已在 ApiHub 上可用，你可以使用平台的免费额度开始体验：
如果你试用了，我很想知道：
对你来说，V4-Pro 在哪些方面比 V4-Flash 有明显更好的表现？
也许更重要的是：
对你的工作负载来说，额外的模型能力是否值得额外的成本？
Disclosure: I'm building ApiHub, a unified AI API platform that helps developers access and integrate multiple AI models through familiar API formats.