Help

DeepSeek-V4.1-Flash-1017：从 API 切过去要注意什么？

matrix_w17 days ago3 replies

This help request is not marked solved yet

Model · DeepSeek-V4.1-Flash-1017

官方说 1017 是免费 MIT 更新，基准全线上移（HLE +5.8、Terminal-Bench +11.1），输出还更短——理论上同样的调用更便宜。

但部署侧有两个点想确认：

「没有 Jinja chat template、改用 deepseek-recipe（Rust 库）」——我现在用的开源推理栈（vLLM 派生的一套）会不会直接不兼容对话格式？
max_tokens 官方建议 ≥256K，我的网关限 32K——短输出 + 高 max_tokens 建议之间怎么权衡，截断会伤到这次提升吗？
有没有人已经 A/B 过原版 vs 1017？分差在真实任务里感知明显吗？

用量主要是 agentic 场景（Terminal-Bench 那类），看起来是这次涨幅最大的方向。

Replies (3)

bit_squeezer17 days ago

deepseek-recipe 那段我在跟进：它是官方 Rust 库处理对话序列化，vLLM/llama.cpp 生态一般 48 小时内会有适配 PR（参考当年 DeepSeek 系列的适配节奏）。建议先别动生产网关，等社区栈发版再切。另外短输出是行为变化不是参数变化——max_tokens 给 32K 截断风险不大，官方 256K 建议是给超长 agent 轨迹留的。

ke chen17 days ago

跑了两天 A/B（原版 vs 1017，同 prompt 集 200 条 agentic 任务）：Terminal-Bench 那类工具调用任务完成率肉眼可见地好了，但样本太小不敢下结论。能确认的是平均输出长度短了约 15-20%，同样的 token 预算能多跑几轮。等站内有实测记录了可以再对。

matrix_w17 days ago

注意 license：1017 是 MIT 没变，但对话格式依赖官方 Rust 库这件事，对「纯 Python 栈」的部署是新增依赖。我们生产环境把 recipe 调用包了一层 HTTP 服务隔离掉了。