open-code-review 如何为响应慢的本地模型调大 LLM 请求超时时间【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review当你把 open-code-reviewOCR接到本地模型例如 Ollama 服务的 OpenAI 兼容端点后本地硬件推理速度往往跟不上OCR 对每个 LLM 请求都有一个 HTTP 超时默认300 秒慢模型在长对话或大 diff 上很容易超过这个时间导致审查无法完成。本文的目标是把这条单请求超时调大让本地模型的审查跑完。适用前提OCR 已安装并能执行ocr命令本地模型已经以自定义 provider 的方式配置好下节给出配置方式模型本身支持原生 tool calling——这一点文档明确要求先于超时问题排查。先确认端点可用、症状不是模型问题在动超时配置之前先用文档给出的两个检查区分连不上/工具调用不支持和只是慢ocr llm test该命令会以与ocr review相同的方式解析 LLM 端点发送一个固定的测试对话并打印Source、URL、Model和模型回复成功时输出✓ Connection test successful退出码非 0 表示端点未配置完整或请求失败网络/鉴权/模型错误报错信息会说明原因。如果审查中的症状是反复出现[ocr] No tool calls parsed for src/foo.go, retrying... [ocr] Max tool requests reached for src/foo.go.且最终零评论按 FAQ 的说法问题在模型而不在配置OCR 完全通过 tool calls 驱动审查模型必须支持原生 function calling只在文本里叙述工具调用的模型文档举的例子是deepseek-r1无论如何调超时都不可用文档指出如qwen3这类有原生工具支持的模型可以正常工作。FAQ 同时给出了不经 OCR、直接curl本地端点验证 tool 支持的方法可以照着执行只有确认模型支持 tools 之后响应慢才值得通过调大超时来解决。如果端点还没配置文档给出的本地模型Ollama配置方式是把 Ollama 作为一个指向本地 OpenAI 兼容端点的 custom providerocr config set provider ollama ocr config set custom_providers.ollama.url http://127.0.0.1:11434/v1 ocr config set custom_providers.ollama.protocol openai ocr config set custom_providers.ollama.model qwen3:32b ocr config set custom_providers.ollama.api_key ollamaOllama 会忽略 API key但 custom provider 要求api_key非空所以设置任意占位值即可。理解三个超时配置项及其范围Configuration 文档 的 Timeouts 一节说明每个 LLM 请求的 HTTP 超时默认为 300 秒慢本地模型或大文件可能需要更大值。有三个配置项作用范围依次递增providers.name.timeout_sec/custom_providers.name.timeout_sec—— 按 provider 生效单位秒llm.timeout_sec—— 用于旧版llm配置段单位秒OCR_LLM_TIMEOUT环境变量 —— 整数秒对每一条端点解析路径都覆盖配置文件中的值。一个关键限制timeout_sec这类 key 不被ocr config set支持必须直接编辑配置文件~/.opencodereview/config.json。文档也提示该文件不建议手动维护——下一次ocr config set写入时会重新格式化它所以改完后不要再依赖手工排好的格式。主路径为本地 provider 写入 timeout_sec以 Ollama 本地模型为例直接编辑~/.opencodereview/config.json在你的 custom provider 条目中加入timeout_sec。文档给出的示例片段900为文档示例值可按实际推理速度调整{ custom_providers: { ollama: { url: http://127.0.0.1:11434/v1, protocol: openai, timeout_sec: 900 } } }对于内置 provider位置同理写在providers.name条目下如果你的配置走的是旧版llm段则用llm.timeout_sec。可选分支用 OCR_LLM_TIMEOUT 临时覆盖如果只想对某一次运行临时调大超时、不想改配置文件用环境变量即可OCR_LLM_TIMEOUT接收整数秒且对每条解析路径都覆盖配置文件里的值。例如OCR_LLM_TIMEOUT900 ocr review确认合适数值后再按上一节写回config.json固化。验证结果先跑ocr llm test确认端点解析与连接正常输出以✓ Connection test successful结尾。在 Git 仓库中重新执行之前超时的审查工作区模式即ocr review无参数时审查当前仓库全部已暂存、未暂存与未跟踪的改动。正常结束时 stdout 末尾会出现运行汇总文档示例输出如下[ocr] Summary: 9 file(s) reviewed, 14 comment(s), ~21344 token(s) used (input: ~18012, output: ~3332), 1m12s elapsed以上为文档示例具体文件数、token 数与耗时以你的运行为准。若某个文件零评论、不确定是否真的被审查过可按 FAQ 的建议用ocr viewer打开会话查看器默认localhost:5483检查该文件所在分组的main_task通道。与 --timeout 的区别避免调错参数CLI Reference 中ocr review还有一个--timeout minutes参数默认150表示禁用它描述的是每个文件分组的整体截止时间并随 effort 轮数线性缩放如 low/medium/high 对应 15/30/45 分钟与本文调整的单个 LLM 请求的 HTTP 超时不是同一个东西。本文场景慢本地模型导致单次请求超 300 秒应改timeout_sec或OCR_LLM_TIMEOUT--timeout控制的是分组层面的总时长。边界与限制手动编辑config.json是文档标注的不推荐但可行方式Interactive TUI 和ocr config set是推荐路径且文件会在下一次ocr config set写入时被重新格式化。timeout_sec无法通过ocr config set写入这是文档明确说明的遇到写不进去的情况不要怀疑命令拼写。调大超时只解决慢的问题如果模型不支持原生 tool calling任何超时值都无法让本地模型工作需换用文档中提到的支持 tools 的模型如qwen3。OCR 会把 diff及可选的 read 工具片段发往你配置的 LLM 端点本地模型意味着这些内容只发送到本地端点其余状态session JSONL、规则文件留在本机。参考文档Configuration、FAQ、CLI Reference。【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 open-code-review 如何为响应慢的本地模型调大 LLM 请求超时时间？
open-code-review 如何为响应慢的本地模型调大 LLM 请求超时时间【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review当你把 open-code-reviewOCR接到本地模型例如 Ollama 服务的 OpenAI 兼容端点后本地硬件推理速度往往跟不上OCR 对每个 LLM 请求都有一个 HTTP 超时默认300 秒慢模型在长对话或大 diff 上很容易超过这个时间导致审查无法完成。本文的目标是把这条单请求超时调大让本地模型的审查跑完。适用前提OCR 已安装并能执行ocr命令本地模型已经以自定义 provider 的方式配置好下节给出配置方式模型本身支持原生 tool calling——这一点文档明确要求先于超时问题排查。先确认端点可用、症状不是模型问题在动超时配置之前先用文档给出的两个检查区分连不上/工具调用不支持和只是慢ocr llm test该命令会以与ocr review相同的方式解析 LLM 端点发送一个固定的测试对话并打印Source、URL、Model和模型回复成功时输出✓ Connection test successful退出码非 0 表示端点未配置完整或请求失败网络/鉴权/模型错误报错信息会说明原因。如果审查中的症状是反复出现[ocr] No tool calls parsed for src/foo.go, retrying... [ocr] Max tool requests reached for src/foo.go.且最终零评论按 FAQ 的说法问题在模型而不在配置OCR 完全通过 tool calls 驱动审查模型必须支持原生 function calling只在文本里叙述工具调用的模型文档举的例子是deepseek-r1无论如何调超时都不可用文档指出如qwen3这类有原生工具支持的模型可以正常工作。FAQ 同时给出了不经 OCR、直接curl本地端点验证 tool 支持的方法可以照着执行只有确认模型支持 tools 之后响应慢才值得通过调大超时来解决。如果端点还没配置文档给出的本地模型Ollama配置方式是把 Ollama 作为一个指向本地 OpenAI 兼容端点的 custom providerocr config set provider ollama ocr config set custom_providers.ollama.url http://127.0.0.1:11434/v1 ocr config set custom_providers.ollama.protocol openai ocr config set custom_providers.ollama.model qwen3:32b ocr config set custom_providers.ollama.api_key ollamaOllama 会忽略 API key但 custom provider 要求api_key非空所以设置任意占位值即可。理解三个超时配置项及其范围Configuration 文档 的 Timeouts 一节说明每个 LLM 请求的 HTTP 超时默认为 300 秒慢本地模型或大文件可能需要更大值。有三个配置项作用范围依次递增providers.name.timeout_sec/custom_providers.name.timeout_sec—— 按 provider 生效单位秒llm.timeout_sec—— 用于旧版llm配置段单位秒OCR_LLM_TIMEOUT环境变量 —— 整数秒对每一条端点解析路径都覆盖配置文件中的值。一个关键限制timeout_sec这类 key 不被ocr config set支持必须直接编辑配置文件~/.opencodereview/config.json。文档也提示该文件不建议手动维护——下一次ocr config set写入时会重新格式化它所以改完后不要再依赖手工排好的格式。主路径为本地 provider 写入 timeout_sec以 Ollama 本地模型为例直接编辑~/.opencodereview/config.json在你的 custom provider 条目中加入timeout_sec。文档给出的示例片段900为文档示例值可按实际推理速度调整{ custom_providers: { ollama: { url: http://127.0.0.1:11434/v1, protocol: openai, timeout_sec: 900 } } }对于内置 provider位置同理写在providers.name条目下如果你的配置走的是旧版llm段则用llm.timeout_sec。可选分支用 OCR_LLM_TIMEOUT 临时覆盖如果只想对某一次运行临时调大超时、不想改配置文件用环境变量即可OCR_LLM_TIMEOUT接收整数秒且对每条解析路径都覆盖配置文件里的值。例如OCR_LLM_TIMEOUT900 ocr review确认合适数值后再按上一节写回config.json固化。验证结果先跑ocr llm test确认端点解析与连接正常输出以✓ Connection test successful结尾。在 Git 仓库中重新执行之前超时的审查工作区模式即ocr review无参数时审查当前仓库全部已暂存、未暂存与未跟踪的改动。正常结束时 stdout 末尾会出现运行汇总文档示例输出如下[ocr] Summary: 9 file(s) reviewed, 14 comment(s), ~21344 token(s) used (input: ~18012, output: ~3332), 1m12s elapsed以上为文档示例具体文件数、token 数与耗时以你的运行为准。若某个文件零评论、不确定是否真的被审查过可按 FAQ 的建议用ocr viewer打开会话查看器默认localhost:5483检查该文件所在分组的main_task通道。与 --timeout 的区别避免调错参数CLI Reference 中ocr review还有一个--timeout minutes参数默认150表示禁用它描述的是每个文件分组的整体截止时间并随 effort 轮数线性缩放如 low/medium/high 对应 15/30/45 分钟与本文调整的单个 LLM 请求的 HTTP 超时不是同一个东西。本文场景慢本地模型导致单次请求超 300 秒应改timeout_sec或OCR_LLM_TIMEOUT--timeout控制的是分组层面的总时长。边界与限制手动编辑config.json是文档标注的不推荐但可行方式Interactive TUI 和ocr config set是推荐路径且文件会在下一次ocr config set写入时被重新格式化。timeout_sec无法通过ocr config set写入这是文档明确说明的遇到写不进去的情况不要怀疑命令拼写。调大超时只解决慢的问题如果模型不支持原生 tool calling任何超时值都无法让本地模型工作需换用文档中提到的支持 tools 的模型如qwen3。OCR 会把 diff及可选的 read 工具片段发往你配置的 LLM 端点本地模型意味着这些内容只发送到本地端点其余状态session JSONL、规则文件留在本机。参考文档Configuration、FAQ、CLI Reference。【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考