#5331 TaskCfgSTS(uuid='6ee8005d0f', name='D:/asmr/RJ01582505.srt', dirname='D:/asmr', noextname='RJ01582505', basename='RJ0158

112.224* Posted at: 13 hours ago

翻译字幕阶段出错 [DeepSeek] 内容太长超出最大允许Token,请减小内容或增大max_token,或者降低每次发送字幕行数
Could not parse response content as the length limit was reached - CompletionUsage(completion_tokens=8192, prompt_tokens=2162, total_tokens=10354, completion_tokens_details=None, prompt_tokens_details=PromptTokensDetails(audio_tokens=None, cached_tokens=2048), prompt_cache_hit_tokens=2048, prompt_cache_miss_tokens=114)
Traceback (most recent call last):

File "videotrans\task\job.py", line 35, in run

File "videotrans\task\job.py", line 135, in process_task

File "videotrans\task\translate_srt.py", line 48, in trans

File "videotrans\translator\__init__.py", line 858, in run

File "videotrans\translator\_base.py", line 72, in run

File "videotrans\translator\_base.py", line 142, in _run_srt

File "tenacity\__init__.py", line 338, in wrapped_f

File "tenacity\__init__.py", line 477, in call

File "tenacity\__init__.py", line 378, in iter

File "tenacity\__init__.py", line 400, in

File "concurrent\futures\_base.py", line 451, in result

File "concurrent\futures\_base.py", line 403, in __get_result

File "tenacity\__init__.py", line 480, in call

File "videotrans\translator\_openaicompat.py", line 84, in _item_task

openai.LengthFinishReasonError: Could not parse response content as the length limit was reached - CompletionUsage(completion_tokens=8192, prompt_tokens=2162, total_tokens=10354, completion_tokens_details=None, prompt_tokens_details=PromptTokensDetails(audio_tokens=None, cached_tokens=2048), prompt_cache_hit_tokens=2048, prompt_cache_miss_tokens=114)
TaskCfgSTS(uuid='6ee8005d0f', name='D:/asmr/RJ01582505.srt', dirname='D:/asmr', noextname='RJ01582505', basename='RJ01582505.srt', ext='srt', target_dir='D:/movie/cn/translate', cache_folder=None, is_cuda=False, source_language=None, source_language_code='Japanese', source_sub='D:/asmr/RJ01582505.srt', source_wav=None, source_wav_output=None, target_language=None, target_language_code='Simplified Chinese', target_sub='D:/movie/cn/translate/RJ01582505.Simplified Chinese.srt', target_wav=None, target_wav_output=None, translate_type=4)


=
system:Windows-10-10.0.26100-SP0
version:v4.01
frozen:True
language:zh
root_dir:D:/download/12

31 Replies

该错误是由于每次发送给 DeepSeek 进行翻译的字幕行数过多,导致模型返回的翻译结果超过了其最大输出 token 限制(8192 tokens)。

解决方案:

  1. 降低每批字幕行数:进入软件顶部菜单 工具/选项 → 高级选项 → 字幕翻译调整,将 AI翻译渠道每批字幕行数 降低至 10~20 行(数值越小,每次请求内容越短,输出越安全)。
  2. 调整 DeepSeek 模型 max_token 设置:在 菜单 → 翻译设置 → DeepSeek 渠道设置面板中,将 max_token 值适当增加(如设为 16384 或更高,取决于你的 DeepSeek 模型是否支持更大输出。若不确定,优先执行第1点)。
  3. 取消“发送完整字幕”:在高级选项中取消勾选 发送完整字幕(若已开启),改为逐行文本翻译,可减少输出内容长度。

请查阅相关文档:

token设置了1000000还是不行运行六次就提醒

根据你的描述,max_token 设为 1000000 仍然失败,原因在于 DeepSeek 模型本身对单次输出的 token 数有硬性限制(例如 8192 tokens),不是你客户端设置可以随意突破的。你设置的值远超模型实际支持的上限,所以设置无效。

核心解决办法:减少每次发送给 DeepSeek 的字幕行数,让单次输出的内容不超过模型限制。

  • 进入 菜单 → 工具/选项 → 高级选项 → 字幕翻译调整,将 AI翻译渠道每批字幕行数 从默认值降低到 10~15 行(如果仍然失败,继续降低至 5~10 行)。
  • 如果启用了 “发送完整字幕”,建议先取消勾选,改用纯文本逐行翻译模式,减少输出体积。

此外,检查 DeepSeek 渠道设置中使用的模型名称:如果选择的是 deepseek-v4-flashdeepseek-v4-pro,它们的输出限制通常在 8K 左右。若必须翻译大量行,可尝试更换为支持更长上下文的模型(如 deepseek-v4 的某些版本),但效果有限,最可靠的仍然是减小每批数量。

若问题仍然存在,请提供 logs/ 目录下最新的日志文件(底部约30行),以便进一步分析。

deepseek-v4-flash 我的是这个换成chat是吧是不是太频繁·的·原因·

错误提示明确是“内容太长超出最大允许Token”,而不是频率限制。你使用的 deepseek-v4-flash 模型自身有输出长度上限(通常 8K 左右),客户端设置的 max_token 超出模型实际支持范围时无效。换成 chat 模型并不能解决问题,因为 DeepSeek 官方提供的模型只有 deepseek-v4-prodeepseek-v4-flash,没有单独的 deepseek-chat。解决方案:

  1. 进一步减小每批字幕行数:进入 高级选项 → 字幕翻译调整,将 AI翻译渠道每批字幕行数 降低到 5~8 行,甚至更低,确保单次输出不超过模型限制。
  2. 更换支持更长输出的 AI 渠道:例如 OpenAI ChatGPT(gpt-4o 等)或 Gemini,它们支持更大的输出 token(如 16K 或更多),但需自行配置 API Key。
  3. 取消“发送完整字幕”:在高级选项中取消勾选,改为纯文本逐行翻译,也能减少输出量。

频率问题并非主因,但若仍想控制请求间隔,可在高级选项中设置 翻译后暂停秒(如 2~3 秒)。

那我token最大可以设置多少

你使用的 deepseek-v4-flash 模型,其实际输出 token 上限由 DeepSeek 官方规定,一般最大为 8192 tokens(部分旧版可能只有 4096)。即使你在客户端将 max_token 设为 1000000,模型也会在达到自身限制时截断或报错。

因此,可设置的 max_token 最大不要超过 8192。但即使设置为 8192,如果每批字幕行数过多,输出仍可能触发长度限制,导致同样的错误。

最佳做法

  1. max_token 设为 8192 或更小(如 4096)。
  2. 高级选项 → 字幕翻译调整 中将 AI翻译渠道每批字幕行数 大幅降低至 5~8 行,确保单次请求输出量在 8K 以内。
  3. 如果必须一次翻译较多行,建议更换为支持更大输出的模型,如 deepseek-v4-pro(可能有更大上下文,但输出仍有限制),或改用 OpenAI ChatGPT、Gemini 等支持超长输出的 AI 渠道。

若要查看 DeepSeek 各模型的具体参数,请参考其官方文档。

默认我记得是4w多吧

你说得没错,某些 AI 模型(如 OpenAI GPT-4 系列或 Gemini)的默认 max_token 确实可以设到 4 万甚至更高。但 DeepSeek-v4-flash 是 DeepSeek 官方专为快速推理优化的轻量级模型,其单次输出上限被固定为 8192 tokens(部分旧版可能更低),这是模型自身架构的限制,不能通过客户端参数突破。

即使你在设置中填了 1000000,模型也只会最多输出 8192 tokens,超出部分会被截断并报错。所以建议你:

  1. 将 max_token 设为 8192(或更低,如 4096),不要设超。
  2. 降低每批字幕行数:进入 高级选项 → 字幕翻译调整,将 AI翻译渠道每批字幕行数 降至 5~8 行,确保每次输出的译文不超过 8K tokens。

如果仍需处理大量字幕,可以考虑换成支持更大上下文的模型,例如:

  • DeepSeek-v4-pro(可能支持更长输出,但仍有上限)
  • OpenAI ChatGPT(如 gpt-4o,可设 max_token 至 16K+)
  • Gemini(默认支持更长的输出)

设置100000无效是吗代表什么

设置 100000 无效,且报错“内容太长超出最大允许Token”,这意味着你使用的 DeepSeek-v4-flash 模型本身的单次输出 token 上限被限制在 8192 左右。你在客户端填写的 100000 只是告诉客户端“我希望模型输出那么多”,但模型到达自己的硬性限制后就会截断并抛出错误。简单来说:模型不支持超过 8192 的输出,填再大也没用。正确的做法:将 max_token 改为 8192(或更低,如 4096)。进入 高级选项 → 字幕翻译调整,将 AI翻译渠道每批字幕行数 降低到 5~8 行,确保每次输出不会超过模型的限制。如果需要一次处理更多行,请更换支持更长输出的 AI 渠道(如 OpenAI ChatGPT 或 Gemini)。

大概就是100kb带时间戳日语srt文件受限

你看到的错误是 DeepSeek-v4-flash 输出上限 8192 tokens 导致的。对于 100KB 带时间戳的日语 SRT 文件:按经验,每批行数建议控制在 150~250 行 以内(如果日语文本较长,则降至 100 行)。进入 高级选项 → 字幕翻译调整,将 AI翻译渠道每批字幕行数 设为 150 左右试运行。若仍报错,继续降低到 80~100。如果想彻底解决大文件问题,推荐以下两种方案之一:1. 更换模型:使用支持更长上下文的 AI 渠道,例如 OpenAI ChatGPT(gpt-4o 输出可达 16K+)或 Gemini(默认支持更长的输出)。2. 使用 DeepSeek-v4-pro:虽然仍有限制,但比 flash 版本上限更高(需自行测试)。如果你的文件内容特别重要且较长,也可以手动将 SRT 拆分为多个小文件分别处理。

还有别的方法吗或者其他软件·

你可以改用 pyVideoTrans 中其他不受 token 限制的翻译渠道,无需更换软件:

  1. 免费传统翻译:选择 Google 翻译(需代理)或 Microsoft 翻译(无需代理),它们没有输出长度限制,可一次性处理大量字幕。
  2. 本地模型翻译:选择 M2M100 本地模型,离线运行,无 token 限制,适合大文件。
  3. 其他 AI 渠道:如果仍希望用大模型,可换成 Gemini 翻译OpenAI ChatGPT(选择 gpt-4o 等支持长上下文的模型,并适当调高 max_token 和每批行数)。

具体操作:在主界面 → 翻译渠道下拉框中选择上述任一项即可,无需额外设置 token。

另外,你也可以将原 SRT 文件手动拆分为多个小文件(每个 100~200 行),分批次翻译后合并,这也是一种稳妥的方法。

5行每次还是卡在180行暂停显示token问题·deepseek

即使每批只发 5 行,仍卡在 180 行提示 token 问题,说明你的 DeepSeek-v4-flash 模型可能在处理较长的日语字符时,5 行的输出仍然接近或超过了模型的实际输出上限。另一个可能是你的设置没有生效(例如修改后未重启,或当前任务使用的是旧参数)。我强烈建议换用以下完全不受 token 限制的免费渠道,彻底解决大文件翻译问题:在主界面顶部 翻译渠道 下拉框中选择:Microsoft 翻译 或 Google 翻译。这两者没有输出长度限制,可以一次性翻译完整字幕文件,不需要拆分。设置方法:进入 菜单 → 翻译设置 中确认对应渠道已启用(Microsoft 翻译一般无需额外配置,Google 翻译需要代理)。然后回到主界面,将“AI翻译渠道每批字幕行数”改回默认值(如 100 或更大),开始执行即可。如果你想坚持使用 AI 大模型,则手动将 SRT 文件拆分为每 50 行一个小文件,分多次翻译后再合并。但更省心的是直接用传统翻译渠道,速度更快且无限制。

翻译区别

Microsoft 翻译 和 Google 翻译 是传统机器翻译引擎,无输出长度限制,速度快,免费,翻译质量稳定但偏直译。DeepSeek 等 AI 大模型翻译,质量更高、更自然,能理解上下文,但受输出 token 限制,处理大文件需拆分批次,速度较慢,且需自行配置 API Key。如果你的首要任务是完整、快速地翻译一个 100KB 的日语 SRT 文件,推荐使用 Microsoft 翻译(无需代理)或 Google 翻译(需代理)。如果追求更好的翻译流畅度,可以接受分批处理和速度较慢,则继续用 DeepSeek 并手动拆分文件。两者主要区别汇总:维度Microsoft / Google 翻译DeepSeek / AI 大模型
翻译质量直译,基本准确,但可能生硬更自然,能理解上下文,适合复杂表达
输出长度限制无限制有 token 上限(约 8K)
大文件处理一次性完成,无需拆分需拆分为小批次,分批处理
速度快(秒级)慢(需多次请求)
费用免费免费(需自备 API Key,按量计费部分渠道)
网络要求Google 需代理,Microsoft 无需无需代理(DeepSeek 国内可用)建议:先用 Microsoft 翻译试一次,如果质量可以接受,后续都用它,省时省力。

就是180行就停下报错,这是后面10行·181
00:14:25,540 --> 00:14:28,940
お兄さんが行くタイミングなんてわかってるんだから。

182
00:14:31,540 --> 00:14:37,020
じゃあ、雑魚お兄さんごと、好きなアレーしてあげる。

183
00:14:40,500 --> 00:14:45,180
5、4、ドクドクしてる。

184
00:14:45,960 --> 00:14:52,000
カウントダウンされたら強制的に射精しちゃう変態をちんちんだもんねー。

185
00:14:52,820 --> 00:15:00,160
3、うーん、出ちゃう出ちゃう。もう、我慢無理我慢無ーりー。

186
00:15:02,660 --> 00:15:08,120
2、我慢しなくちゃいけないのに出ちゃう。雑魚ちんちん負けちゃう。

187
00:15:11,200 --> 00:15:17,440
1、最後のしこしこだよー。じっくり味わいながらドピドピするんだよー。

188
00:15:19,020 --> 00:15:41,720
いけ、ぜーんろー。ぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅぴゅ�

189
00:15:41,720 --> 00:15:48,380
すっごい量、出しすぎ。お兄さんのおちんちん、やっぱりおもしろい。

190
00:15:49,700 --> 00:15:53,560
はっ、精子の匂いもすっごい。

你遇到的问题根源在于第 188 行包含一长串连续的拟声词(重复数十个“ぴゅ”),即使每批只发 5 行,这一行的内容本身就已经很长,翻译后仍然会超出 DeepSeek-v4-flash 的输出上限(8192 tokens)。因此继续用 DeepSeek 翻译这个文件会一直卡在这一行附近。解决方法(任选其一):1. 改用无输出限制的翻译渠道(推荐):在主界面翻译渠道中选择 Microsoft 翻译 或 Google 翻译(需代理)。它们可以一次性处理整个文件,无需拆分,再也不报 token 错误。2. 手动处理超长行后继续用 DeepSeek:用文本编辑器打开原 SRT,找到第 188 行,将“ぴゅ”重复序列删减到合理长度(例如保留 5~10 个),或将该行拆分为多行(如每行 10 个“ぴゅ”)。保存后重新执行翻译。3. 跳过该行或用其他 AI 渠道:如果坚持用 AI 渠道,可以换成 OpenAI ChatGPT 或 Gemini,它们支持更长的输出,但需自行配置 API Key。建议直接使用 Microsoft 翻译,最快最省心。

删除后解决了,那我再识别音频的·时候怎么避免这种长串

在语音识别阶段避免产生长串重复字符(如连续数十个“ぴゅ”),可以从以下方面调整:1. 启用 LLM 重新断句:在主界面语音识别区域选择“LLM 重新断句”,并在 菜单→工具→高级选项→通用设置 中将 LLM 断句所用 AI 渠道设为 DeepSeek 或 OpenAI。识别后的文本会自动修正、合并重复内容、合理断句,避免出现极长单行。
注意:如果后续配音使用 clone 音色则不建议启用,否则会影响克隆效果。2. 调整语音识别参数:进入 高级选项→语音识别参数,将“最长语音持续(秒)”设为 6~10,将“最短语音持续(毫秒)”设为 3000~4000,并勾选“Whisper预分割音频”和“合并过短字幕到邻近”。这样长串重复音节会被自动切分为多个短片段,不会合并为一行超长字幕。3. 更换语音识别模型:对于日语音频,如果使用 faster-whisper(本地) 仍出现长串,可换用 openai-whisper(本地) large-v3Huggingface_ASR 中的 reazon-research/japanese-wav2vec2-large-rs35kh,这些模型对重复内容的处理可能更优。4. 人工干预:如果只是偶尔出现,可在语音识别完成后的字幕编辑窗口中手动删除或缩短长串重复行。以上方案建议优先使用 LLM 重新断句,能最直接地避免类似问题。

如果我是外界的srt是没有办法是吧。我是用的lager3 tubor

是的,如果是外界直接提供的SRT文件,软件无法自动修正其中的长串重复字符。因为软件不修改外部字幕文件的内容,直接拿去翻译时,如果某一行过长(如连续几十个“ぴゅ”),DeepSeek 等有输出限制的模型仍然会报 token 错误。解决办法:手动编辑外部SRT文件:用记事本或字幕编辑器打开该SRT,找到超长行,删减重复内容到合理长度(如保留5~10个重复字),或拆分为多行。改用无限制翻译渠道:在主界面 翻译渠道 中选择 Microsoft 翻译 或 Google 翻译,它们不受输出长度限制,可以翻译任意字符数,无需手动修改SRT内容。如果你是用 large-v3-turbo 模型自己识别音频时出现的长串,则可以通过启用 LLM 重新断句 或调整识别参数来避免,但外部SRT只能走上述两条路。

外部语音识别把LARGE3TURBO换成3可以吗

更换为 large-v3(不带 turbo)可以尝试,它有更高的识别准确度,可能减少对重复音节的“过度忠实”转录,从而降低极长重复行的出现概率。但无法保证完全避免——如果音频本身确实包含大量重复拟声词(如“ぴゅ”重复几十次),模型仍可能如实转录。建议:更换为 large-v3 模型。同时配合启用 LLM 重新断句(识别完成后自动修正长串)。若问题仍存在,后续翻译阶段改用 Microsoft翻译Google翻译 等无限制渠道。

本地翻译推荐哪个

综合你的需求(处理大文件、避免 Token 限制、日语翻译),推荐使用 M2M100(本地模型)。这是 pyVideoTrans 内置的唯一离线翻译模型,没有任何输出长度限制,无需联网,完全免费。M2M100 本地模型特点:支持上百种语言互译(含日语 ↔ 中文)一次性处理整个 SRT 文件,无需分批,不再报 Token 错误离线运行,保护隐私第一次使用会自动下载模型(约 1.2GB,耐心等待)。操作步骤:1. 在主界面 翻译渠道 下拉框中选择 M2M100本地模型。2. 确保已正确选择“发音语言”为日语,“目标语言”为简体中文。3. 取消勾选“发送完整字幕”(M2M100 不支持该模式)。4. 直接点击开始执行即可。注意:M2M100 是传统机器翻译模型,翻译质量不如 DeepSeek 等大模型自然,但稳定性极佳,适合处理超长或特殊字符文件。如果你对翻译流畅度有更高要求,可先用 M2M100 完成粗翻,再用 AI 渠道精修关键段落。

跟微软比呢

从处理你当前这个包含超长重复字符(如连续几十个“ぴゅ”)的日语SRT文件的角度对比:Microsoft 翻译:质量稳定(传统机器翻译,上下文理解一般,但语法和用词通顺)。无输出长度限制。需联网(微软服务器无需代理,国内可直接使用)。速度快(秒级返回)。完全免费。M2M100 本地模型:质量一般(默认翻译较直译,可能生硬)。无输出长度限制。离线运行,无需联网。速度快(取决于CPU/GPU,一般也很快)。完全免费,模型约1.2GB。简单结论:两者都比 DeepSeek 稳定,都不会再报 token 错误。如果追求翻译流畅度和通用性,首选 Microsoft 翻译。如果需要离线运行或网络不稳,或更注重隐私,选 M2M100。建议你先用 Microsoft 翻译试一次,效果不满意再换 M2M100 试一下,对比后再决定。

Post Your Reply
Open source and free maintenance is not easy. If this project is helpful to you, please consider making a small donation to help the project continue to maintain and update. Dondate: ko-fi.com/jianchang512

Related resource

Similar issues already exist