Langchain-Chatchat 模型服务治理 API 全解析llm_api 接口原理与 FastChat 协同实践【免费下载链接】Langchain-ChatchatLangchain-Chatchat原Langchain-ChatGLM基于 Langchain 与 ChatGLM, Qwen 与 Llama 等语言模型的 RAG 与 Agent 应用 | Langchain-Chatchat (formerly langchain-ChatGLM), local knowledge based LLM (like ChatGLM, Qwen and Llama) RAG and Agent app with langchain项目地址: https://gitcode.com/GitHub_Trending/la/Langchain-ChatchatLangchain-Chatchat 通过server/llm_api.py暴露一组模型服务治理接口负责在 Web 前端、后端 API 与底层 FastChat 组件controller / model_worker / openai_api_server之间建立统一、可编程的控制通道。本文以该模块的 6 个核心函数为主线深入讲解如何查询已加载模型、读取合并配置、切换与停止模型以及枚举搜索引擎并结合仓库中的启动脚本与前端调用链还原其底层原理帮助你彻底掌握多模型服务的运行时治理能力。1. 模块定位LLM 服务层的“调度中枢”在 Langchain-Chatchat 中本地与在线大模型服务由 FastChat 体系承载。后端把模型加载、卸载、切换等生命周期操作抽象为一组 HTTP 语义接口从而让上层WebUI、命令行、OpenAI 风格调用不再关心 FastChat 内部细节。从仓库结构看libs/chatchat-server/chatchat/server/目录下保留了 FastChat 相关的配套实现server/llm_api_stale.py多进程拉起 controller、model_worker、openai_api_server 的启动脚本server/llm_api_shutdown.py按进程关键字停止 FastChat 服务的脚本server/utils.py提供get_httpx_client、fschat_controller_address、get_model_worker_config等被 llm_api 复用的底层函数。llm_api.py中 6 个函数面向三类请求者请求者诉求对应接口WebUI 前端展示当前有哪些模型在线、默认选中哪个模型list_running_models/list_config_models运行时切换从 A 模型切换到 B 模型change_llm_model运维管理释放不再使用的模型stop_llm_model调试排查查看某个模型的合并后配置get_model_config搜索问答确认系统支持哪些搜索引擎list_search_engines2. list_running_models查询 FastChat 已加载模型2.1 函数签名与参数def list_running_models(controller_address, placeholder)参数类型说明controller_addressstrFastChat controller 服务器地址。未提供时调用fschat_controller_address()获取默认地址placeholderstr未使用仅作 API 设计占位符2.2 执行流程校验controller_address缺省时通过fschat_controller_address()补全该函数读取FSCHAT_CONTROLLER配置中的主机与端口并把0.0.0.0归一化为127.0.0.1用get_httpx_client()创建 HTTP 客户端libs/chatchat-server/chatchat/server/utils.py中该函数同时处理代理绕过与超时设置避免用户自建 FastChat 服务被系统代理拦截向 controller 发送 POST/list_models请求拿到已加载模型列表对列表中的每个模型调用get_model_config()拉取其合并配置最终以BaseResponse包装返回。成功返回示例{ code: 200, msg: success, data: { model1: { model_version: 1.0, language: English, # 其他配置项 }, model2: { model_version: 2.0, language: Chinese, # 其他配置项 } } }异常时返回code为 500 的BaseResponsemsg字段携带具体错误详情便于排障。2.3 前端如何消费它在 WebUI 侧ApiRequest.list_running_models会向后端/llm_model/list_running_models端点发 POST 请求详见 webui_pages/utils.md。而ret_sync/ret_async逻辑正是基于该接口返回的运行列表实现“自动选模”优先在LLM_MODELS配置中寻找已在运行的模型若local_first为真则跳过在线模型、坚持本地优先当配置中所有模型均未运行时退而选择运行列表中的第一个模型。这解释了为什么list_running_models的返回值直接决定对话页面能否正确选中默认模型。3. list_config_models读取本地配置中的模型3.1 函数签名与参数def list_config_models(types, placeholder)参数类型默认值说明typesList[str][local, online]需要筛选的模型配置类别例如local、online、workerplaceholderstrNone占位参数无实际效果仅用于 API 扩展3.2 执行流程定义空字典data调用list_config_llm_models()获取全部已配置 LLM 的分类字典由FSCHAT_MODEL_WORKERS派生包含local本地模型、online在线模型、worker工作模型三类仅当某类别出现在types中时对该类别下的每个模型调用get_model_config()获取合并配置并写入data返回BaseResponse。成功返回示例{ code: 200, msg: success, data: { local: { model1: {config1: value1, config2: value2}, model2: {config1: value1, config2: value2} }, online: { model3: {config1: value1, config2: value2}, model4: {config1: value1, config2: value2} } } }3.3 注意事项types中出现的类别必须在配置中真实存在否则拿不到对应数据该接口与“正在运行”状态无关它只回答“配置里声明了哪些模型”因此常与list_running_models配合使用如 WebUI 切换模型前的可用性校验。4. get_model_config返回脱敏后的合并配置4.1 函数签名与参数def get_model_config(model_name, placeholder)参数类型说明model_namestr配置中 LLM 模型的名称Body 传入placeholderstr占位用无实际效果4.2 脱敏过滤逻辑函数通过get_model_worker_config(model_name)取得该模型的“合并配置”随后做一轮安全过滤剔除如下键包含worker_class的键暴露模型工作类实现包含key、secret的键API 密钥等敏感凭据以id结尾的键。其余配置项写入config后随BaseResponse返回。成功返回示例{ code: 200, msg: success, data: { model_version: 1.0, language: English, # 其他非敏感配置项 } }4.3 背后的配置合并机制get_model_worker_config见 server/utils.md的合并顺序值得关注它先以FSCHAT_MODEL_WORKERS[default]作为基底配置再依次用ONLINE_LLM_MODEL[model_name]、FSCHAT_MODEL_WORKERS[model_name]覆盖同名项。也就是说一个模型的最终生效配置 默认配置 模型专属覆盖这正是“合并配置”的含义所在。get_model_config在此之上再叠加脱敏保证 API 层不会把密钥与类实现细节下发给前端。5. stop_llm_model停止指定 LLM 模型5.1 函数签名与参数def stop_llm_model(model_name, controller_address)参数类型说明model_namestr要停止的 LLM 模型名称必需controller_addressstrFastChat controller 地址缺省时由fschat_controller_address()补齐5.2 执行流程与底层语义解析 controller 地址通过get_httpx_client()获取客户端向 controller 发送 POST/release_worker请求体携带待停止的模型名称成功则返回 controller 响应内容异常则记录日志并返回code500 的BaseResponse。关键语义由于 FastChat 的实现方式停止一个 LLM 模型实际上等价于停止该模型所在的 model_worker 进程。理解这一点对 GPU 显存释放至关重要——只有真正停掉 worker显存才会归还。成功返回示例{ code: 200, msg: success, data: null }失败返回示例模型不存在或 controller 通信异常{ code: 500, msg: failed to stop LLM model example_model from controller: http://127.0.0.1:8080。错误信息是 ConnectionError, data: null }WebUI 侧对应的调用端点是/llm_model/stop见 webui_pages/utils.md前端也会先通过list_running_models校验模型确在运行再发起停止从而避免误操作。6. change_llm_model在线切换 LLM 模型6.1 函数签名与参数def change_llm_model(model_name, new_model_name, controller_address)参数类型说明model_namestr当前运行的模型名称new_model_namestr要切换到的目标模型名称controller_addressstrFastChat controller 地址缺省自动获取6.2 执行流程确定 controller 地址使用get_httpx_client()创建客户端向 controller 发送 POST/release_worker请求体含model_name与new_model_name两个字段超时时间由HTTPX_DEFAULT_TIMEOUT常量定义成功返回 controller 的响应 JSON异常时返回带错误信息的BaseResponse。成功返回示例{ code: 200, msg: Model switched successfully, data: { previous_model: old_model_name, current_model: new_model_name } }失败返回示例{ code: 500, msg: failed to switch LLM model from controller: http://127.0.0.1:8080。错误信息是ConnectionError }6.3 前端切换的前置校验链从 webui_pages/utils.md 可以看到ret_sync/ret_async在真正调用/llm_model/change前会做三层校验new_model_name model_name或目标模型已在运行列表 → 直接返回 200“无需切换”model_name不在运行列表 → 返回 500提示“指定模型未运行”new_model_name不在list_config_models结果中 → 返回 500提示“目标模型未在配置中设置”。这套前置校验把大量非法请求拦截在 controller 之外也体现了“配置态”与“运行态”两套列表需要交叉核对的工程经验。6.4 使用注意model_name与new_model_name都必须真实存在于服务器中否则 controller 无法完成 release 与 reload 动作切换本质是“释放旧 worker 加载新 worker”模型体积越大耗时越长调用方应设置合理超时并做好失败重试。7. list_search_engines枚举支持的搜索引擎def list_search_engines()该函数无参数。实现上从server.chat.search_engine_chat模块导入SEARCH_ENGINES变量将其放入BaseResponse.data返回。SEARCH_ENGINES定义了服务端已接入的搜索引擎集合是联网搜索类问答能力的基础配置。{ code: 200, msg: success, data: [Google, Bing, DuckDuckGo] }使用注意返回的是BaseResponse对象调用方需取data字段使用SEARCH_ENGINES来自独立模块常量扩容搜索引擎时需保证该变量在导入前完成定义与初始化该接口无参数、可直连调用适合作为系统能力探测入口。8. 统一响应规范与安全设计贯穿全部接口的是BaseResponse定义于 types/server/response/base.py三个字段语义固定字段含义code状态码200 表示成功500 表示服务器内部错误msg人类可读的状态消息 / 错误详情data业务数据载体可为 dict、list 或 null由此形成两层一致性返回结构一致调用方只看code/msg即可判读成功与否错误携带可排障信息异常时msg中明确写出 controller 地址与异常类型。加上get_model_config的脱敏策略整个 llm_api 层在“可用性”与“安全性”之间做了很好的平衡。9. 从启动到治理的完整链路为了让上述 API 有模型可管仓库提供了配套的 FastChat 启动方案。server/llm_api_stale.py支持用一条命令串联拉起 controller、多个 model_worker 与 openai_api_serverpython llm_api_stale.py --model-path-address THUDM/chatglm2-6blocalhost7650 THUDM/chatglm2-6b-32klocalhost7651--model-path-address按模型路径主机端口格式重复传入可一次加载多个模型并生成多份 worker 日志输出在./logs/文件按模型名自动清洗命名--dispatch-methodcontroller 的请求分发策略可选lottery与shortest_queue默认shortest_queueworker 侧还暴露--gpus、--num-gpus、--max-gpu-memory、--load-8bit、--gptq-wbits等资源控制参数便于在大模型场景下按显存精细调配脚本内部通过轮询日志中Uvicorn running on关键字确保各组件就绪后再启动下一环节避免竞态。与之对称的 server/llm_api_shutdown.py 则通过ps过滤fastchat.serve相关进程并执行清理供一键停机使用。把这两部分与 llm_api 治理函数串起来完整生命周期如下启动llm_api_stale.py 拉起 controller/worker/openai server │ ▼ list_config_models ──► 配置态模型清单local / online / worker │ ▼ list_running_models ──► 运行态模型清单/list_models每模型附带 get_model_config 配置 │ ├──► change_llm_model ──► controller /release_worker切换前经前端三层校验 │ └──► stop_llm_model ────► controller /release_worker释放模型所在 worker归还显存10. 实践建议与常见问题排查调用失败先看三处controller 是否存活get_httpx_client对本地 FastChat 做了NO_PROXY处理见 server/utils.py 中set_httpx_config相关实现若代理配置异常controller 请求会失败错误信息中会包含ConnectionError字样controller 地址是否规范fschat_controller_address会把0.0.0.0归一化为127.0.0.1手写地址时也应显式携带http://前缀否则会出现InvalidSchema: No connection adapters were found模型名是否精确匹配配置键无论是stop还是change模型名都必须与运行列表 / 配置列表中的键完全一致大小写与空格差异都会导致 500。显存不释放的排查停止模型走的是/release_worker即停掉整个 worker 进程若调用成功但显存仍被占用应回到llm_api_stale.py启动的 worker 进程确认是否有残留进程必要时结合llm_api_shutdown.py做兜底清理。配置信息“查不到”先用get_model_config返回的脱敏结果与本地FSCHAT_MODEL_WORKERS/ONLINE_LLM_MODEL配置对照确认模型分类local / online / worker是否正确再检查是否因脱敏规则worker_class、key、secret、*id被有意隐藏。以上所有能力均可通过仓库自带的测试与文档交叉验证接口行为与前端调用约定见 webui_pages/utils.md 与 utils.md模型配置结构见 server/model_workers/base.md服务状态类 API 的调用示例见 tests/api/test_server_state_api.py。掌握这 6 个接口就等于掌握了 Langchain-Chatchat 多模型运行时治理的控制面无论是 WebUI 上的模型切换、脚本化的批量启停还是二次开发新的模型管理能力都能做到有的放矢。【免费下载链接】Langchain-ChatchatLangchain-Chatchat原Langchain-ChatGLM基于 Langchain 与 ChatGLM, Qwen 与 Llama 等语言模型的 RAG 与 Agent 应用 | Langchain-Chatchat (formerly langchain-ChatGLM), local knowledge based LLM (like ChatGLM, Qwen and Llama) RAG and Agent app with langchain项目地址: https://gitcode.com/GitHub_Trending/la/Langchain-Chatchat创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Langchain-Chatchat 模型服务治理 API 全解析：llm_api 接口原理与 FastChat 协同实践
Langchain-Chatchat 模型服务治理 API 全解析llm_api 接口原理与 FastChat 协同实践【免费下载链接】Langchain-ChatchatLangchain-Chatchat原Langchain-ChatGLM基于 Langchain 与 ChatGLM, Qwen 与 Llama 等语言模型的 RAG 与 Agent 应用 | Langchain-Chatchat (formerly langchain-ChatGLM), local knowledge based LLM (like ChatGLM, Qwen and Llama) RAG and Agent app with langchain项目地址: https://gitcode.com/GitHub_Trending/la/Langchain-ChatchatLangchain-Chatchat 通过server/llm_api.py暴露一组模型服务治理接口负责在 Web 前端、后端 API 与底层 FastChat 组件controller / model_worker / openai_api_server之间建立统一、可编程的控制通道。本文以该模块的 6 个核心函数为主线深入讲解如何查询已加载模型、读取合并配置、切换与停止模型以及枚举搜索引擎并结合仓库中的启动脚本与前端调用链还原其底层原理帮助你彻底掌握多模型服务的运行时治理能力。1. 模块定位LLM 服务层的“调度中枢”在 Langchain-Chatchat 中本地与在线大模型服务由 FastChat 体系承载。后端把模型加载、卸载、切换等生命周期操作抽象为一组 HTTP 语义接口从而让上层WebUI、命令行、OpenAI 风格调用不再关心 FastChat 内部细节。从仓库结构看libs/chatchat-server/chatchat/server/目录下保留了 FastChat 相关的配套实现server/llm_api_stale.py多进程拉起 controller、model_worker、openai_api_server 的启动脚本server/llm_api_shutdown.py按进程关键字停止 FastChat 服务的脚本server/utils.py提供get_httpx_client、fschat_controller_address、get_model_worker_config等被 llm_api 复用的底层函数。llm_api.py中 6 个函数面向三类请求者请求者诉求对应接口WebUI 前端展示当前有哪些模型在线、默认选中哪个模型list_running_models/list_config_models运行时切换从 A 模型切换到 B 模型change_llm_model运维管理释放不再使用的模型stop_llm_model调试排查查看某个模型的合并后配置get_model_config搜索问答确认系统支持哪些搜索引擎list_search_engines2. list_running_models查询 FastChat 已加载模型2.1 函数签名与参数def list_running_models(controller_address, placeholder)参数类型说明controller_addressstrFastChat controller 服务器地址。未提供时调用fschat_controller_address()获取默认地址placeholderstr未使用仅作 API 设计占位符2.2 执行流程校验controller_address缺省时通过fschat_controller_address()补全该函数读取FSCHAT_CONTROLLER配置中的主机与端口并把0.0.0.0归一化为127.0.0.1用get_httpx_client()创建 HTTP 客户端libs/chatchat-server/chatchat/server/utils.py中该函数同时处理代理绕过与超时设置避免用户自建 FastChat 服务被系统代理拦截向 controller 发送 POST/list_models请求拿到已加载模型列表对列表中的每个模型调用get_model_config()拉取其合并配置最终以BaseResponse包装返回。成功返回示例{ code: 200, msg: success, data: { model1: { model_version: 1.0, language: English, # 其他配置项 }, model2: { model_version: 2.0, language: Chinese, # 其他配置项 } } }异常时返回code为 500 的BaseResponsemsg字段携带具体错误详情便于排障。2.3 前端如何消费它在 WebUI 侧ApiRequest.list_running_models会向后端/llm_model/list_running_models端点发 POST 请求详见 webui_pages/utils.md。而ret_sync/ret_async逻辑正是基于该接口返回的运行列表实现“自动选模”优先在LLM_MODELS配置中寻找已在运行的模型若local_first为真则跳过在线模型、坚持本地优先当配置中所有模型均未运行时退而选择运行列表中的第一个模型。这解释了为什么list_running_models的返回值直接决定对话页面能否正确选中默认模型。3. list_config_models读取本地配置中的模型3.1 函数签名与参数def list_config_models(types, placeholder)参数类型默认值说明typesList[str][local, online]需要筛选的模型配置类别例如local、online、workerplaceholderstrNone占位参数无实际效果仅用于 API 扩展3.2 执行流程定义空字典data调用list_config_llm_models()获取全部已配置 LLM 的分类字典由FSCHAT_MODEL_WORKERS派生包含local本地模型、online在线模型、worker工作模型三类仅当某类别出现在types中时对该类别下的每个模型调用get_model_config()获取合并配置并写入data返回BaseResponse。成功返回示例{ code: 200, msg: success, data: { local: { model1: {config1: value1, config2: value2}, model2: {config1: value1, config2: value2} }, online: { model3: {config1: value1, config2: value2}, model4: {config1: value1, config2: value2} } } }3.3 注意事项types中出现的类别必须在配置中真实存在否则拿不到对应数据该接口与“正在运行”状态无关它只回答“配置里声明了哪些模型”因此常与list_running_models配合使用如 WebUI 切换模型前的可用性校验。4. get_model_config返回脱敏后的合并配置4.1 函数签名与参数def get_model_config(model_name, placeholder)参数类型说明model_namestr配置中 LLM 模型的名称Body 传入placeholderstr占位用无实际效果4.2 脱敏过滤逻辑函数通过get_model_worker_config(model_name)取得该模型的“合并配置”随后做一轮安全过滤剔除如下键包含worker_class的键暴露模型工作类实现包含key、secret的键API 密钥等敏感凭据以id结尾的键。其余配置项写入config后随BaseResponse返回。成功返回示例{ code: 200, msg: success, data: { model_version: 1.0, language: English, # 其他非敏感配置项 } }4.3 背后的配置合并机制get_model_worker_config见 server/utils.md的合并顺序值得关注它先以FSCHAT_MODEL_WORKERS[default]作为基底配置再依次用ONLINE_LLM_MODEL[model_name]、FSCHAT_MODEL_WORKERS[model_name]覆盖同名项。也就是说一个模型的最终生效配置 默认配置 模型专属覆盖这正是“合并配置”的含义所在。get_model_config在此之上再叠加脱敏保证 API 层不会把密钥与类实现细节下发给前端。5. stop_llm_model停止指定 LLM 模型5.1 函数签名与参数def stop_llm_model(model_name, controller_address)参数类型说明model_namestr要停止的 LLM 模型名称必需controller_addressstrFastChat controller 地址缺省时由fschat_controller_address()补齐5.2 执行流程与底层语义解析 controller 地址通过get_httpx_client()获取客户端向 controller 发送 POST/release_worker请求体携带待停止的模型名称成功则返回 controller 响应内容异常则记录日志并返回code500 的BaseResponse。关键语义由于 FastChat 的实现方式停止一个 LLM 模型实际上等价于停止该模型所在的 model_worker 进程。理解这一点对 GPU 显存释放至关重要——只有真正停掉 worker显存才会归还。成功返回示例{ code: 200, msg: success, data: null }失败返回示例模型不存在或 controller 通信异常{ code: 500, msg: failed to stop LLM model example_model from controller: http://127.0.0.1:8080。错误信息是 ConnectionError, data: null }WebUI 侧对应的调用端点是/llm_model/stop见 webui_pages/utils.md前端也会先通过list_running_models校验模型确在运行再发起停止从而避免误操作。6. change_llm_model在线切换 LLM 模型6.1 函数签名与参数def change_llm_model(model_name, new_model_name, controller_address)参数类型说明model_namestr当前运行的模型名称new_model_namestr要切换到的目标模型名称controller_addressstrFastChat controller 地址缺省自动获取6.2 执行流程确定 controller 地址使用get_httpx_client()创建客户端向 controller 发送 POST/release_worker请求体含model_name与new_model_name两个字段超时时间由HTTPX_DEFAULT_TIMEOUT常量定义成功返回 controller 的响应 JSON异常时返回带错误信息的BaseResponse。成功返回示例{ code: 200, msg: Model switched successfully, data: { previous_model: old_model_name, current_model: new_model_name } }失败返回示例{ code: 500, msg: failed to switch LLM model from controller: http://127.0.0.1:8080。错误信息是ConnectionError }6.3 前端切换的前置校验链从 webui_pages/utils.md 可以看到ret_sync/ret_async在真正调用/llm_model/change前会做三层校验new_model_name model_name或目标模型已在运行列表 → 直接返回 200“无需切换”model_name不在运行列表 → 返回 500提示“指定模型未运行”new_model_name不在list_config_models结果中 → 返回 500提示“目标模型未在配置中设置”。这套前置校验把大量非法请求拦截在 controller 之外也体现了“配置态”与“运行态”两套列表需要交叉核对的工程经验。6.4 使用注意model_name与new_model_name都必须真实存在于服务器中否则 controller 无法完成 release 与 reload 动作切换本质是“释放旧 worker 加载新 worker”模型体积越大耗时越长调用方应设置合理超时并做好失败重试。7. list_search_engines枚举支持的搜索引擎def list_search_engines()该函数无参数。实现上从server.chat.search_engine_chat模块导入SEARCH_ENGINES变量将其放入BaseResponse.data返回。SEARCH_ENGINES定义了服务端已接入的搜索引擎集合是联网搜索类问答能力的基础配置。{ code: 200, msg: success, data: [Google, Bing, DuckDuckGo] }使用注意返回的是BaseResponse对象调用方需取data字段使用SEARCH_ENGINES来自独立模块常量扩容搜索引擎时需保证该变量在导入前完成定义与初始化该接口无参数、可直连调用适合作为系统能力探测入口。8. 统一响应规范与安全设计贯穿全部接口的是BaseResponse定义于 types/server/response/base.py三个字段语义固定字段含义code状态码200 表示成功500 表示服务器内部错误msg人类可读的状态消息 / 错误详情data业务数据载体可为 dict、list 或 null由此形成两层一致性返回结构一致调用方只看code/msg即可判读成功与否错误携带可排障信息异常时msg中明确写出 controller 地址与异常类型。加上get_model_config的脱敏策略整个 llm_api 层在“可用性”与“安全性”之间做了很好的平衡。9. 从启动到治理的完整链路为了让上述 API 有模型可管仓库提供了配套的 FastChat 启动方案。server/llm_api_stale.py支持用一条命令串联拉起 controller、多个 model_worker 与 openai_api_serverpython llm_api_stale.py --model-path-address THUDM/chatglm2-6blocalhost7650 THUDM/chatglm2-6b-32klocalhost7651--model-path-address按模型路径主机端口格式重复传入可一次加载多个模型并生成多份 worker 日志输出在./logs/文件按模型名自动清洗命名--dispatch-methodcontroller 的请求分发策略可选lottery与shortest_queue默认shortest_queueworker 侧还暴露--gpus、--num-gpus、--max-gpu-memory、--load-8bit、--gptq-wbits等资源控制参数便于在大模型场景下按显存精细调配脚本内部通过轮询日志中Uvicorn running on关键字确保各组件就绪后再启动下一环节避免竞态。与之对称的 server/llm_api_shutdown.py 则通过ps过滤fastchat.serve相关进程并执行清理供一键停机使用。把这两部分与 llm_api 治理函数串起来完整生命周期如下启动llm_api_stale.py 拉起 controller/worker/openai server │ ▼ list_config_models ──► 配置态模型清单local / online / worker │ ▼ list_running_models ──► 运行态模型清单/list_models每模型附带 get_model_config 配置 │ ├──► change_llm_model ──► controller /release_worker切换前经前端三层校验 │ └──► stop_llm_model ────► controller /release_worker释放模型所在 worker归还显存10. 实践建议与常见问题排查调用失败先看三处controller 是否存活get_httpx_client对本地 FastChat 做了NO_PROXY处理见 server/utils.py 中set_httpx_config相关实现若代理配置异常controller 请求会失败错误信息中会包含ConnectionError字样controller 地址是否规范fschat_controller_address会把0.0.0.0归一化为127.0.0.1手写地址时也应显式携带http://前缀否则会出现InvalidSchema: No connection adapters were found模型名是否精确匹配配置键无论是stop还是change模型名都必须与运行列表 / 配置列表中的键完全一致大小写与空格差异都会导致 500。显存不释放的排查停止模型走的是/release_worker即停掉整个 worker 进程若调用成功但显存仍被占用应回到llm_api_stale.py启动的 worker 进程确认是否有残留进程必要时结合llm_api_shutdown.py做兜底清理。配置信息“查不到”先用get_model_config返回的脱敏结果与本地FSCHAT_MODEL_WORKERS/ONLINE_LLM_MODEL配置对照确认模型分类local / online / worker是否正确再检查是否因脱敏规则worker_class、key、secret、*id被有意隐藏。以上所有能力均可通过仓库自带的测试与文档交叉验证接口行为与前端调用约定见 webui_pages/utils.md 与 utils.md模型配置结构见 server/model_workers/base.md服务状态类 API 的调用示例见 tests/api/test_server_state_api.py。掌握这 6 个接口就等于掌握了 Langchain-Chatchat 多模型运行时治理的控制面无论是 WebUI 上的模型切换、脚本化的批量启停还是二次开发新的模型管理能力都能做到有的放矢。【免费下载链接】Langchain-ChatchatLangchain-Chatchat原Langchain-ChatGLM基于 Langchain 与 ChatGLM, Qwen 与 Llama 等语言模型的 RAG 与 Agent 应用 | Langchain-Chatchat (formerly langchain-ChatGLM), local knowledge based LLM (like ChatGLM, Qwen and Llama) RAG and Agent app with langchain项目地址: https://gitcode.com/GitHub_Trending/la/Langchain-Chatchat创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考