binary-husky/gpt_academic · error · RuntimeError

程序终止。

Error message

程序终止。

What it means

This RuntimeError ('程序终止。') is raised by a watchdog inside predict_no_ui_long_connection for the local ChatGLM-ft model. While streaming tokens from glmft_handle.stream_chat, the loop checks observe_window[1], a timestamp that the UI thread is expected to keep refreshing. If more than watch_dog_patience (5 seconds) elapse without the timestamp being fed, the stream is aborted under the assumption the user cancelled or the UI died. It is a cooperative-cancellation mechanism, not a model error.

Source

Thrown at request_llms/bridge_chatglmft.py:168

        if len(observe_window) >= 1: observe_window[0] = load_message + "\n\n" + glmft_handle.info
        if not glmft_handle.success:
            error = glmft_handle.info
            glmft_handle = None
            raise RuntimeError(error)

    # chatglmft 没有 sys_prompt 接口，因此把prompt加入 history
    history_feedin = []
    history_feedin.append(["What can I do?", sys_prompt])
    for i in range(len(history)//2):
        history_feedin.append([history[2*i], history[2*i+1]] )

    watch_dog_patience = 5 # 看门狗 (watchdog) 的耐心, 设置5秒即可
    response = ""
    for response in glmft_handle.stream_chat(query=inputs, history=history_feedin, max_length=llm_kwargs['max_length'], top_p=llm_kwargs['top_p'], temperature=llm_kwargs['temperature']):
        if len(observe_window) >= 1:  observe_window[0] = response
        if len(observe_window) >= 2:
            if (time.time()-observe_window[1]) > watch_dog_patience:
                raise RuntimeError("程序终止。")
    return response



def predict(inputs, llm_kwargs, plugin_kwargs, chatbot, history=[], system_prompt='', stream = True, additional_fn=None):
    """
        单线程方法
        函数的说明请见 request_llms/bridge_all.py
    """
    chatbot.append((inputs, ""))

    global glmft_handle
    if glmft_handle is None:
        glmft_handle = GetGLMFTHandle()
        chatbot[-1] = (inputs, load_message + "\n\n" + glmft_handle.info)
        yield from update_ui(chatbot=chatbot, history=[])
        if not glmft_handle.success:
            glmft_handle = None

View on GitHub (pinned to d6bde0fa54)

Solutions

1. If you cancelled intentionally, this is expected behavior — just start a new request.
2. If generation is being killed spuriously on slow hardware, increase watch_dog_patience in request_llms/bridge_chatglmft.py (e.g. to 30) to tolerate slow local inference.
3. If you call this function from custom code, keep updating observe_window[1] = time.time() from your monitoring thread at least once per patience interval.
4. Check GPU utilization / model loading: a stalled ChatGLM-ft process (OOM swapping to CPU) can freeze the stream and trip the watchdog.

Example fix

// before
watch_dog_patience = 5

// after (slow local GPU/CPU inference)
watch_dog_patience = 30

try:
    result = predict_no_ui_long_connection(inputs, llm_kwargs, history, sys_prompt, observe_window=mutable_target)
except RuntimeError as e:
    if e.args[0] == '程序终止。':
        handle_user_cancel_or_watchdog()  # distinguish via your own cancel flag
    else:
        raise

When it happens

Trigger: Calling predict_no_ui_long_connection with an observe_window list whose second element is a stale timestamp: the user pressed stop in the Gradio UI, the UI thread stopped calling time.time() into observe_window[1], or the caller passed a window but never updates element [1]. Also triggers when the local ChatGLM-ft process stalls so long that the UI watchdog timestamp expires (>5s).

Common situations: Running gpt_academic with a locally fine-tuned ChatGLM model on slow GPU/CPU hardware where stream_chat blocks for more than 5 seconds without yielding; user clicks the stop/cancel button mid-generation; a plugin passes observe_window but does not run the feeding loop.

Related errors

• 用户取消了程序。
• 用户取消了程序。
• 用户取消了程序。
• 用户取消了程序。
• 用户取消了程序。

AI-assisted analysis of binary-husky/gpt_academic@d6bde0fa54 (2026-08-14). Data as JSON: /api/errors/35abc75be9e6d0ea. Report an issue: GitHub.