340 lines
29 KiB
Markdown
340 lines
29 KiB
Markdown
## FunctionDef create_controller_app(dispatch_method, log_level)
|
||
**create_controller_app**: 此函数的功能是创建并配置一个FastAPI应用，用于作为控制器服务。
|
||
|
||
**参数**:
|
||
- `dispatch_method`: 字符串类型，指定消息分发的方法。
|
||
- `log_level`: 字符串类型，默认为"INFO"，用于设置日志级别。
|
||
|
||
**代码描述**:
|
||
此函数首先导入必要的模块和变量，包括`fastchat.constants`用于设置日志目录，以及从`fastchat.serve.controller`导入的`app`（FastAPI实例）、`Controller`类和`logger`对象。函数设置日志级别后，实例化`Controller`对象，并将其注册到`sys.modules`中，以便在整个应用中可以访问到这个控制器实例。
|
||
|
||
接下来，调用`MakeFastAPIOffline`函数，为FastAPI应用提供离线文档支持，这意味着Swagger UI和ReDoc文档页面不会依赖于外部CDN来加载，而是从本地提供所需的静态文件。这一步骤对于在没有外部网络连接的环境中运行应用尤其重要。
|
||
|
||
最后，函数设置FastAPI应用的标题为"FastChat Controller"，并将之前创建的`Controller`实例作为应用的一个属性，以便在应用的其他部分中可以直接访问控制器实例。函数返回配置好的FastAPI应用实例。
|
||
|
||
**注意**:
|
||
- 确保在调用此函数之前，`LOG_PATH`变量已被正确设置，以便日志文件能被存储在预期的位置。
|
||
- `MakeFastAPIOffline`函数需要确保`static_dir`参数指向的目录中包含了Swagger UI和ReDoc所需的所有静态文件，包括JavaScript、CSS文件和图标等。
|
||
|
||
**输出示例**:
|
||
由于此函数返回一个FastAPI应用实例，因此输出示例将是一个配置好的FastAPI对象，具有设置的日志级别、标题、控制器实例以及离线文档支持。这个FastAPI实例随后可以被用于启动Web服务，处理HTTP请求。
|
||
## FunctionDef create_model_worker_app(log_level)
|
||
**create_model_worker_app**: 此函数的功能是创建并配置一个FastAPI应用，用于作为模型工作节点，支持不同类型的模型服务。
|
||
|
||
**参数**:
|
||
- `log_level`: 字符串类型，默认为"INFO"，用于设置日志记录的级别。
|
||
- `**kwargs`: 关键字参数，用于传递额外的配置选项，包括模型名称、控制器地址、工作节点地址等。
|
||
|
||
**代码描述**:
|
||
函数首先导入必要的模块和设置日志目录。然后，通过解析`kwargs`参数，根据提供的配置选项动态地设置应用的行为。这包括支持Langchain模型、在线API模型以及离线模型的配置。
|
||
|
||
对于Langchain支持的模型，不需要进行额外的配置。对于在线API模型，需要指定`worker_class`来创建相应的工作节点实例。对于离线模型，根据模型的路径、设备等信息，创建相应的工作节点实例，并配置模型的各种参数，如并行大小、内存使用限制等。
|
||
|
||
此外，函数还调用了`MakeFastAPIOffline`函数，为创建的FastAPI应用添加离线文档支持，确保在没有外部网络连接的环境下，也能提供完整的API文档。
|
||
|
||
最后，函数设置应用的标题，并将工作节点实例绑定到应用上，然后返回这个配置好的FastAPI应用实例。
|
||
|
||
**注意**:
|
||
- 确保传递给函数的`kwargs`参数中包含了正确的配置信息，如模型名称、控制器地址等，以便正确地初始化模型工作节点。
|
||
- 使用此函数创建的FastAPI应用已经配置了离线文档支持，无需额外配置即可在离线环境下访问API文档。
|
||
|
||
**输出示例**:
|
||
由于此函数返回一个FastAPI应用实例，因此输出示例将取决于具体的配置和使用场景。一般来说，返回的FastAPI应用实例可以直接用于启动一个Web服务，提供模型推理等API接口。例如，如果配置了一个支持Langchain模型的工作节点，那么返回的应用将提供相应的API接口，允许客户端通过HTTP请求进行模型推理操作。
|
||
## FunctionDef create_openai_api_app(controller_address, api_keys, log_level)
|
||
**create_openai_api_app**: 此函数的功能是创建并配置一个FastAPI应用，用于提供OpenAI API服务。
|
||
|
||
**参数**:
|
||
- `controller_address`: 字符串类型，控制器的地址。
|
||
- `api_keys`: 字符串列表，默认为空列表，用于存放API密钥。
|
||
- `log_level`: 字符串类型，默认为"INFO"，用于设置日志级别。
|
||
|
||
**代码描述**:
|
||
首先，函数通过修改`fastchat.constants.LOGDIR`变量来设置日志目录。接着，导入`app`和`CORSMiddleware`以及`app_settings`对象，用于FastAPI应用的配置。使用`build_logger`函数创建一个日志记录器，设置其日志级别为传入的`log_level`参数。
|
||
|
||
函数为FastAPI应用添加了一个中间件`CORSMiddleware`，配置了跨源资源共享（CORS）策略，允许所有来源、方法和头部的请求。这是为了确保不同的客户端可以无障碍地与API进行交互。
|
||
|
||
通过修改`sys.modules`中的`logger`对象，将自定义的日志记录器应用于OpenAI API服务器模块。此外，将`controller_address`和`api_keys`参数分别赋值给`app_settings`对象的相应属性，用于配置API服务的控制器地址和API密钥。
|
||
|
||
调用`MakeFastAPIOffline`函数使得FastAPI应用支持离线文档，这意味着Swagger UI和ReDoc文档页面不依赖于外部CDN加载，而是从本地服务器提供。这对于在没有外部网络连接的环境中运行API服务尤为重要。
|
||
|
||
最后，设置FastAPI应用的标题为"FastChat OpenAI API Server"，并返回配置好的FastAPI应用对象。
|
||
|
||
**注意**:
|
||
- 确保传入的`controller_address`有效，因为它是API服务与控制器通信的关键。
|
||
- 在部署API服务时，考虑到安全性，应当仔细管理`api_keys`列表，避免泄露密钥。
|
||
- 调整`log_level`参数可以控制日志的详细程度，有助于调试和监控API服务的状态。
|
||
|
||
**输出示例**: 由于此函数返回一个FastAPI应用对象，因此输出示例取决于FastAPI框架的实现。通常，返回的对象可以用于启动一个Web服务器，提供RESTful API服务。
|
||
## FunctionDef _set_app_event(app, started_event)
|
||
**_set_app_event**: 该函数用于为FastAPI应用设置启动事件。
|
||
|
||
**参数**:
|
||
- **app**: FastAPI的实例，表示当前的FastAPI应用。
|
||
- **started_event**: 可选参数，默认为None。它是一个multiprocessing.Event的实例，用于跨进程通信，标记应用是否已启动。
|
||
|
||
**代码描述**:
|
||
此函数主要用于在FastAPI应用中注册一个启动事件。当FastAPI应用启动时，如果传入的`started_event`不为None，则会调用`started_event.set()`方法，这通常用于在多进程环境下通知其他进程应用已经准备就绪。
|
||
|
||
在项目中，`_set_app_event`函数被多个不同的启动函数调用，包括`run_controller`、`run_model_worker`、`run_openai_api`和`run_api_server`。这些启动函数分别用于启动不同的服务组件，如控制器服务、模型工作节点、OpenAI API接口和API服务器。在这些函数中，`_set_app_event`通过将FastAPI应用实例和一个可选的`started_event`作为参数传入，来确保在服务组件启动时，相关的启动事件能够被正确设置和触发。
|
||
|
||
通过这种方式，`_set_app_event`函数在项目中扮演了一个重要的角色，它确保了在多进程或分布式环境下，各个服务组件能够协调启动，从而提高了系统的稳定性和响应能力。
|
||
|
||
**注意**:
|
||
- 在使用`_set_app_event`函数时，需要确保传入的`app`参数是一个有效的FastAPI应用实例。
|
||
- 如果在多进程环境下使用，`started_event`参数应该是一个通过`multiprocessing.Event`创建的事件实例，这样可以确保跨进程的正确通信。
|
||
- 该函数通过装饰器`@app.on_event("startup")`注册启动事件，因此只有在FastAPI应用启动时，注册的事件处理函数`on_startup`才会被执行。
|
||
### FunctionDef on_startup
|
||
**on_startup**: 此函数的功能是在应用启动时设置一个事件标志。
|
||
|
||
**参数**: 此函数没有参数。
|
||
|
||
**代码描述**: `on_startup` 函数是一个异步函数，旨在应用启动时执行特定的操作。函数体内部首先检查全局变量 `started_event` 是否不为 `None`。如果该条件为真，即 `started_event` 已经被定义且不为 `None`，则调用 `started_event.set()` 方法。这个方法的调用将会设置一个事件标志，通常用于指示应用已经成功启动或某个初始化过程已经完成。在多线程或异步编程中，事件标志常用于同步不同部分的执行流程，确保在继续执行其他操作之前，某些关键的初始化步骤已经完成。
|
||
|
||
**注意**: 使用此函数时，需要确保 `started_event` 已经在某处被正确初始化为一个事件对象。此外，由于这是一个异步函数，调用它时需要使用 `await` 关键字或在其他异步上下文中调用。这确保了函数内的异步操作能够被正确处理。
|
||
***
|
||
## FunctionDef run_controller(log_level, started_event)
|
||
**run_controller**: 此函数的功能是启动一个FastAPI应用，用于控制和管理模型工作节点。
|
||
|
||
**参数**:
|
||
- `log_level`: 字符串类型，默认为"INFO"，用于设置日志级别。
|
||
- `started_event`: 可选参数，默认为None。它是一个multiprocessing.Event的实例，用于跨进程通信，标记应用是否已启动。
|
||
|
||
**代码描述**:
|
||
首先，函数导入了必要的模块，包括`uvicorn`用于运行ASGI应用，`httpx`用于HTTP客户端请求，`fastapi`中的`Body`用于请求体解析，以及`time`和`sys`模块。接着，调用`set_httpx_config`函数设置httpx库的默认超时时间和代理配置。
|
||
|
||
函数通过调用`create_controller_app`函数创建一个FastAPI应用实例，该实例配置了消息分发方法和日志级别。然后，使用`_set_app_event`函数为FastAPI应用设置启动事件，如果传入了`started_event`参数，则在应用启动时标记事件。
|
||
|
||
在FastAPI应用中添加了一个`/release_worker`的POST接口，用于释放和加载模型工作节点。此接口接收模型名称、新模型名称和是否保留原模型的参数，通过与模型工作节点通信来实现模型的切换或释放。
|
||
|
||
最后，根据配置的主机地址和端口号，以及日志级别，使用`uvicorn.run`函数启动FastAPI应用。如果日志级别设置为"ERROR"，则将标准输出和错误输出重定向到系统默认的输出和错误流。
|
||
|
||
**注意**:
|
||
- 在启动控制器服务之前，确保已经正确配置了`FSCHAT_CONTROLLER`字典中的`host`和`port`，以及其他相关设置。
|
||
- `set_httpx_config`函数的调用是为了确保在与模型工作节点通信时，请求的超时时间和代理设置符合项目需求。
|
||
- `/release_worker`接口的实现依赖于`app._controller`对象的`list_models`和`get_worker_address`方法，这些方法需要在`create_controller_app`函数中正确初始化。
|
||
|
||
**输出示例**:
|
||
由于此函数主要负责启动FastAPI应用并不直接返回数据，因此没有直接的输出示例。但是，一旦应用启动成功，它将开始监听指定的主机地址和端口号，等待接收HTTP请求。
|
||
### FunctionDef release_worker(model_name, new_model_name, keep_origin)
|
||
**release_worker**: 此函数的功能是释放当前正在使用的模型，并根据需要加载新模型。
|
||
|
||
**参数**:
|
||
- `model_name`: 字符串类型，默认值为`Body(...)`。此参数指定要释放的模型的名称。
|
||
- `new_model_name`: 字符串类型，默认值为`None`。此参数指定释放当前模型后要加载的新模型的名称。
|
||
- `keep_origin`: 布尔类型，默认值为`False`。此参数指定在加载新模型时是否保留原有模型。
|
||
|
||
**代码描述**:
|
||
首先，函数通过调用`app._controller.list_models()`获取当前可用的模型列表。如果指定的`new_model_name`已存在于可用模型列表中，则记录信息并返回错误代码500，表示模型切换失败。
|
||
|
||
如果`new_model_name`不为空，函数将记录开始切换模型的信息；如果为空，则记录即将停止模型的信息。接着，检查`model_name`是否在可用模型列表中，如果不在，则记录错误并返回错误代码500，表示指定的模型不可用。
|
||
|
||
函数通过`app._controller.get_worker_address(model_name)`获取要释放的模型的地址。如果地址获取失败，则记录错误并返回错误代码500。
|
||
|
||
使用`get_httpx_client()`函数获取httpx客户端实例，并向模型的地址发送POST请求，请求内容包括新模型的名称和是否保留原模型的标志。如果请求状态码不是200，表示模型释放失败，记录错误并返回错误代码500。
|
||
|
||
如果指定了`new_model_name`，函数将等待新模型注册完成。使用循环检查新模型是否已注册，如果在超时时间内注册成功，则记录成功信息并返回成功代码200；如果超时仍未注册成功，则记录错误并返回错误代码500。
|
||
|
||
如果没有指定`new_model_name`，则直接记录模型释放成功的信息并返回成功代码200。
|
||
|
||
**注意**:
|
||
- 在使用此函数时，确保提供的模型名称正确且模型确实存在于系统中。
|
||
- 当`new_model_name`不为空时，此函数不仅会释放指定的模型，还会尝试加载新模型。因此，需要确保新模型名称正确且模型文件已准备好。
|
||
- `keep_origin`参数允许在加载新模型时保留原模型，这在需要同时运行多个模型的场景中非常有用。
|
||
|
||
**输出示例**:
|
||
```json
|
||
{
|
||
"code": 200,
|
||
"msg": "sucess to release model: chatglm-6b"
|
||
}
|
||
```
|
||
或者在发生错误时：
|
||
```json
|
||
{
|
||
"code": 500,
|
||
"msg": "the model chatglm-6b is not available"
|
||
}
|
||
```
|
||
***
|
||
## FunctionDef run_model_worker(model_name, controller_address, log_level, q, started_event)
|
||
**run_model_worker**: 此函数的功能是启动模型工作节点，用于处理模型推理请求。
|
||
|
||
**参数**:
|
||
- `model_name`: 字符串类型，默认为`LLM_MODELS`列表中的第一个元素，指定要启动的模型名称。
|
||
- `controller_address`: 字符串类型，默认为空字符串，指定控制器的地址。
|
||
- `log_level`: 字符串类型，默认为"INFO"，指定日志记录的级别。
|
||
- `q`: `mp.Queue`类型，可选参数，默认为None，用于进程间通信的队列。
|
||
- `started_event`: `mp.Event`类型，可选参数，默认为None，用于标记模型工作节点启动完成的事件。
|
||
|
||
**代码描述**:
|
||
函数首先导入必要的模块，包括`uvicorn`、`fastapi`等，并设置httpx库的配置。然后，通过调用`get_model_worker_config`函数获取模型工作节点的配置信息，包括主机地址、端口号等，并根据`model_name`动态设置模型路径和其他相关配置。
|
||
|
||
接着，使用`create_model_worker_app`函数创建一个FastAPI应用实例，该实例根据提供的参数和配置信息进行初始化。如果`log_level`设置为"ERROR"，则将标准输出和错误输出重定向到系统默认的输出和错误流。
|
||
|
||
函数还定义了一个`release_model`接口，允许通过HTTP POST请求释放当前加载的模型并可选地加载新模型。该接口接收新模型名称和是否保留原模型的参数，并通过向`q`队列发送指令来控制模型的加载和释放。
|
||
|
||
最后，使用`uvicorn.run`函数启动FastAPI应用，监听指定的主机地址和端口号，提供模型推理服务。
|
||
|
||
**注意**:
|
||
- 确保传入的`model_name`在配置中正确定义，以便加载正确的模型和配置信息。
|
||
- 如果在多进程环境下使用，`q`和`started_event`参数应通过`multiprocessing`模块创建，以实现进程间的正确通信。
|
||
- `controller_address`参数允许指定控制器的地址，如果为空，则会尝试使用默认的控制器地址。
|
||
|
||
**输出示例**:
|
||
由于此函数主要负责启动FastAPI应用并不直接返回数据，因此没有直接的输出示例。但在成功启动后，FastAPI应用将在指定的主机地址和端口号上监听HTTP请求，提供模型推理服务。例如，如果配置的主机地址为`127.0.0.1`，端口号为`8000`，则可以通过`http://127.0.0.1:8000`访问该服务的API接口。
|
||
### FunctionDef release_model(new_model_name, keep_origin)
|
||
**release_model**: 该函数的功能是根据参数决定是否保留原模型并加载新模型或替换原模型。
|
||
|
||
**参数**:
|
||
- **new_model_name**: 字符串类型，默认值为None。该参数用于指定要加载的新模型名称。
|
||
- **keep_origin**: 布尔类型，默认值为False。该参数用于指定是否保留原模型。如果为True，则加载新模型时保留原模型；如果为False，则替换原模型或停止当前模型。
|
||
|
||
**代码描述**:
|
||
该函数接受两个参数：`new_model_name`和`keep_origin`。`new_model_name`用于指定要操作的模型名称，而`keep_origin`决定了是保留原有模型还是替换原有模型。函数内部逻辑如下：
|
||
- 如果`keep_origin`为True，并且提供了`new_model_name`，则将模型名称、"start"操作和新模型名称放入队列`q`中，表示启动新模型的同时保留原模型。
|
||
- 如果`keep_origin`为False，有两种情况：
|
||
- 如果提供了`new_model_name`，则将模型名称、"replace"操作和新模型名称放入队列`q`中，表示替换当前模型为新模型。
|
||
- 如果没有提供`new_model_name`，则将模型名称、"stop"操作和None放入队列`q`中，表示停止当前模型。
|
||
- 函数最后返回一个字典，包含操作结果的状态码和消息，状态码200表示操作成功。
|
||
|
||
**注意**:
|
||
- 确保在调用此函数时，队列`q`已经被正确初始化并且可以被访问。
|
||
- 在实际应用中，需要根据实际情况调整`new_model_name`和`keep_origin`的值以满足不同的模型管理需求。
|
||
- 函数返回的状态码和消息可以用于进一步的逻辑处理或用户反馈。
|
||
|
||
**输出示例**:
|
||
```json
|
||
{
|
||
"code": 200,
|
||
"msg": "done"
|
||
}
|
||
```
|
||
该输出示例表示操作已成功完成。
|
||
***
|
||
## FunctionDef run_openai_api(log_level, started_event)
|
||
**run_openai_api**: 此函数的功能是启动OpenAI API服务。
|
||
|
||
**参数**:
|
||
- `log_level`: 字符串类型，默认为"INFO"。用于设置日志级别。
|
||
- `started_event`: 可选参数，默认为None。它是一个multiprocessing.Event的实例，用于跨进程通信，标记服务是否已启动。
|
||
|
||
**代码描述**:
|
||
函数首先导入必要的模块，包括`uvicorn`用于运行ASGI应用，`sys`用于系统级操作，以及项目内部的`set_httpx_config`函数用于配置HTTP客户端。接着，调用`set_httpx_config`函数来设置HTTP客户端的配置。
|
||
|
||
通过调用`fschat_controller_address`函数获取控制器的地址，然后使用此地址和`log_level`参数调用`create_openai_api_app`函数创建一个FastAPI应用实例。如果存在`started_event`参数，则通过调用`_set_app_event`函数将此事件与应用实例关联，以便在应用启动时标记事件。
|
||
|
||
接下来，从配置中读取`FSCHAT_OPENAI_API`字典的`host`和`port`字段，用于指定服务的主机地址和端口号。如果`log_level`被设置为"ERROR"，则将标准输出和错误输出重定向回系统默认的输出和错误流，这主要用于减少日志输出的详细程度。
|
||
|
||
最后，使用`uvicorn.run`函数启动FastAPI应用，传入之前创建的应用实例、主机地址和端口号作为参数。
|
||
|
||
**注意**:
|
||
- 确保`FSCHAT_OPENAI_API`配置中的`host`和`port`字段已正确设置，因为它们决定了服务的网络地址和端口。
|
||
- 在多进程环境下使用`started_event`参数可以帮助其他进程了解OpenAI API服务是否已经准备就绪。
|
||
- 调整`log_level`参数可以控制日志输出的详细程度，有助于在不同的环境中调试和监控服务状态。
|
||
- 此函数在项目的启动流程中被`start_main_server`函数调用，作为启动OpenAI API服务的一部分。
|
||
## FunctionDef run_api_server(started_event, run_mode)
|
||
Doc is waiting to be generated...
|
||
## FunctionDef run_webui(started_event, run_mode)
|
||
**run_webui**: 此函数用于启动Web UI服务器。
|
||
|
||
**参数**:
|
||
- `started_event`: 一个`mp.Event`类型的参数，默认为None。用于在进程间同步，标识Web UI服务器启动完成。
|
||
- `run_mode`: 字符串类型的参数，默认为None。用于指定运行模式，特别是在“lite”模式下运行时的特殊配置。
|
||
|
||
**代码描述**:
|
||
此函数首先导入`server.utils`模块中的`set_httpx_config`函数，并调用它来设置httpx库的配置，包括默认超时时间和代理配置。接着，函数从全局配置中获取Web UI服务器的主机地址和端口号。然后，构建一个命令行命令列表，该列表包含了启动Streamlit服务器所需的所有参数，包括服务器地址、端口号以及主题相关的配置。如果`run_mode`参数被设置为"lite"，则会向命令行参数中添加额外的配置，以适应轻量级运行模式。最后，使用`subprocess.Popen`启动Streamlit进程，并通过`started_event.set()`通知其他进程Web UI服务器已启动，然后等待该进程结束。
|
||
|
||
**注意**:
|
||
- 在调用此函数之前，应确保`WEBUI_SERVER`字典中已正确配置了Web UI服务器的`host`和`port`。
|
||
- 此函数依赖于Streamlit库来启动Web UI，因此需要确保Streamlit已安装在环境中。
|
||
- 通过`run_mode`参数，可以灵活地控制Web UI的运行模式，例如在资源受限的环境下使用"lite"模式以减少资源消耗。
|
||
- 此函数在项目的启动流程中被调用，特别是在需要启动Web UI界面时。例如，在`start_main_server`函数中，根据命令行参数决定是否启动Web UI服务器，并通过进程间事件同步机制来确保Web UI服务器启动完成后再继续执行其他任务。
|
||
## FunctionDef parse_args
|
||
**parse_args**: 此函数的功能是解析命令行参数，并返回解析后的参数和解析器对象。
|
||
|
||
**参数**: 此函数不接受任何参数。
|
||
|
||
**代码描述**: `parse_args` 函数使用 `argparse` 库创建一个解析器对象，用于解析命令行参数。它定义了多个命令行参数，每个参数都有其对应的选项（如`-a`、`--all-webui`等），作用（如启动服务器、指定模型名称等），以及存储目的地（如`dest="all_webui"`）。这些参数支持不同的操作模式和配置，以适应不同的运行需求。例如，`--all-webui` 参数会启动包括 API 和 Web UI 在内的全部服务，而 `--model-name` 参数允许用户指定一个或多个模型名称。函数最后调用 `parser.parse_args()` 解析命令行输入的参数，并返回解析后的参数和解析器对象。
|
||
|
||
在项目中，`parse_args` 函数被 `start_main_server` 函数调用。`start_main_server` 函数根据 `parse_args` 返回的参数来决定启动哪些服务和模式。例如，如果指定了 `--all-webui` 参数，那么 `start_main_server` 将启动包括 OpenAI API、模型工作器、API 服务器和 Web UI 在内的所有服务。这种设计使得服务的启动和管理更加灵活和可配置。
|
||
|
||
**注意**: 使用此函数时，需要确保命令行参数的正确性和合理性，因为它们直接影响到服务的启动和运行模式。另外，考虑到 `argparse` 的使用，此函数的调用环境应为命令行界面或兼容命令行参数的环境。
|
||
|
||
**输出示例**: 假设命令行输入为 `python startup.py --all-webui`，则 `parse_args` 函数可能返回的 `args` 对象将包含属性 `all_webui=True`，而其他属性根据定义的默认值或命令行输入进行设置。同时，返回的 `parser` 对象可用于进一步的参数解析或帮助信息的显示。
|
||
## FunctionDef dump_server_info(after_start, args)
|
||
**dump_server_info**: 此函数的功能是打印服务器配置和状态信息。
|
||
|
||
**参数**:
|
||
- `after_start`: 布尔类型，用于指示是否在服务器启动后调用此函数。默认值为False。
|
||
- `args`: 一个可选参数，包含命令行参数对象。默认值为None。
|
||
|
||
**代码描述**:
|
||
`dump_server_info` 函数首先导入所需的模块和函数，包括平台信息、项目版本、以及服务器的API和WEBUI地址等。接着，函数打印出操作系统、Python版本、项目版本以及langchain和fastchat的版本信息。此外，函数还会根据传入的`args`参数（如果有的话），选择性地打印出当前使用的分词器、启动的LLM模型、以及嵌入模型的信息。
|
||
|
||
如果`args`参数中指定了模型名称，则只打印该模型的配置信息；否则，打印所有LLM模型的配置信息。此配置信息通过调用`get_model_worker_config`函数获取，该函数负责加载指定模型的工作配置。
|
||
|
||
在服务器启动后（即`after_start`为True时），函数会额外打印服务器运行信息，包括OpenAI API服务器、Chatchat API服务器和Chatchat WEBUI服务器的地址。这些地址信息通过`fschat_openai_api_address`、`api_address`和`webui_address`函数获取。
|
||
|
||
**注意**:
|
||
- 确保在调用此函数之前，所有相关的配置（如项目版本、模型配置等）已经正确设置。
|
||
- 此函数主要用于在服务器启动时或启动后，向终端打印配置和状态信息，以便于开发者和管理员了解当前服务器的运行状况。
|
||
- `args`参数中的模型名称、是否开启API或WEBUI等选项，将影响函数打印的信息内容。因此，在使用此函数时，应根据实际情况传递正确的参数。
|
||
## FunctionDef start_main_server
|
||
Doc is waiting to be generated...
|
||
### FunctionDef handler(signalname)
|
||
**handler**: handler函数的功能是创建并返回一个处理特定信号的闭包函数。
|
||
|
||
**参数**:
|
||
- signalname: 该参数指定了需要处理的信号名称。
|
||
|
||
**代码描述**:
|
||
handler函数接收一个参数signalname，该参数用于指定需要处理的信号名称。函数内部定义了一个闭包函数f，该闭包函数接收两个参数：signal_received和frame。当接收到指定的信号时，闭包函数会抛出一个KeyboardInterrupt异常，并附带一条消息，表明接收到了哪种信号。
|
||
|
||
值得注意的是，Python 3.9版本引入了`signal.strsignal(signalnum)`方法，因此在该版本及以后，本函数可能不再需要。同样，Python 3.8版本引入了`signal.valid_signals()`方法，可以用来创建相同目的的映射，进一步减少了对此类自定义处理函数的需求。
|
||
|
||
**注意**:
|
||
- 使用此函数时，需要确保传入的signalname是有效且可以被程序捕获的信号名称。
|
||
- 抛出的KeyboardInterrupt异常需要在程序的更高层级被捕获和处理，以实现优雅的信号处理逻辑。
|
||
- 由于Python版本的不同，开发者应当根据自己使用的Python版本决定是否需要使用此函数。
|
||
|
||
**输出示例**:
|
||
假设调用`handler("SIGINT")`并将返回的闭包函数注册为SIGINT信号的处理函数，当SIGINT信号被触发时，程序将抛出以下异常：
|
||
```
|
||
KeyboardInterrupt: SIGINT received
|
||
```
|
||
#### FunctionDef f(signal_received, frame)
|
||
**f**: 此函数的功能是在接收到特定信号时抛出一个`KeyboardInterrupt`异常。
|
||
|
||
**参数**:
|
||
- `signal_received`: 接收到的信号。
|
||
- `frame`: 当前栈帧的引用。
|
||
|
||
**代码描述**:
|
||
函数`f`设计用于处理操作系统发送的信号。当操作系统向Python程序发送一个信号时，该函数将被调用。函数接收两个参数：`signal_received`和`frame`。`signal_received`参数代表接收到的信号，而`frame`参数是对当前栈帧的引用，尽管在此函数体内未直接使用。
|
||
|
||
函数的主要行为是抛出一个`KeyboardInterrupt`异常。这是通过`raise`关键字实现的，它用于引发指定的异常。在这种情况下，异常是`KeyboardInterrupt`，这通常用于响应用户的中断操作，如按下Ctrl+C。异常消息中包含了一个字符串，该字符串应该是`signalname`加上"received"的形式，但在提供的代码中，`signalname`并未定义，这可能是一个错误或遗漏。正确的做法应该是在异常消息中明确指出接收到的是哪种信号，例如通过将`signal_received`参数的值转换为对应的信号名称。
|
||
|
||
**注意**:
|
||
- 在使用此函数时，需要确保`signal_received`参数能够正确表示接收到的信号类型。此外，考虑到`signalname`在代码中未定义，需要修正异常消息以正确反映接收到的信号。
|
||
- 该函数设计用于在接收到特定信号时优雅地中断程序。然而，抛出`KeyboardInterrupt`异常可能会被上层代码捕获和处理，因此应当在设计程序时考虑到这一点。
|
||
- 在多线程环境中使用信号处理函数时应当小心，因为Python的信号处理主要是在主线程中执行的。
|
||
***
|
||
***
|
||
### FunctionDef process_count
|
||
**process_count**: 此函数的功能是计算当前进程总数。
|
||
|
||
**参数**: 此函数不接受任何参数。
|
||
|
||
**代码描述**: `process_count` 函数旨在计算系统中当前的进程总数。它首先通过访问全局变量 `processes` 来获取进程信息。`processes` 是一个字典，其中包含不同类型的进程列表，例如 `online_api` 和 `model_worker`。函数通过计算 `processes` 字典的长度，加上 `online_api` 列表的长度和 `model_worker` 列表的长度，然后减去2，来得出总进程数。减去2的操作可能是为了调整某些预设的或者非动态计算的进程数。
|
||
|
||
**注意**: 使用此函数时，需要确保全局变量 `processes` 已经被正确初始化，并且包含了 `online_api` 和 `model_worker` 这两个键。此外，减去的数字2应根据实际情况进行调整，以确保进程计数的准确性。
|
||
|
||
**输出示例**: 假设 `processes` 字典包含3个主进程，`online_api` 列表包含2个进程，`model_worker` 列表包含3个进程，那么 `process_count` 函数的返回值将是：
|
||
|
||
```
|
||
3 + 2 + 3 - 2 = 6
|
||
```
|
||
|
||
这意味着系统当前总共有6个进程在运行。
|
||
***
|