open-code-review 如何为响应慢的本地模型调大 LLM 请求超时时间？-迪斯科星球

open-code-review 如何为响应慢的本地模型调大 LLM 请求超时时间？

【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibaba's 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-review（OCR）接到本地模型（例如 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 provider：

ocr 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 ollama

Ollama 会忽略 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_TIMEOUT=900 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>参数（默认15，0表示禁用），它描述的是每个文件分组的整体截止时间，并随 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。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析