Update main. #6
+9
-5
@@ -129,16 +129,20 @@ def maybe_summarize_async(session_id: str, backend: Backend | None = None) -> No
|
||||
|
||||
|
||||
def summarize_all(
|
||||
backend: Backend | None = None, limit: int | None = None, workers: int = 8
|
||||
backend: Backend | None = None, limit: int | None = None, workers: int | None = None
|
||||
) -> dict:
|
||||
"""Summarize every session that needs it. Idempotent and resumable.
|
||||
|
||||
LLM summarization runs concurrently across `workers` threads (great for a
|
||||
cloud backend). DB reads (loading transcripts) and writes (store_summary,
|
||||
which also embeds) happen on the main thread, so the single SQLite
|
||||
connection is never touched from multiple threads.
|
||||
Concurrency is backend-aware: the cloud API parallelizes happily, but the
|
||||
local/MI50 GPU servers run a single slot (llama.cpp --parallel 1) — firing N
|
||||
requests at them just queues, blows the client timeout, and thrashes the KV
|
||||
cache (wasted compute + heat). So GPU backends run serially unless overridden.
|
||||
DB reads/writes (store_summary embeds) stay on the main thread, so the single
|
||||
SQLite connection is never touched from multiple threads.
|
||||
"""
|
||||
backend = backend or config.load().summary_backend
|
||||
if workers is None:
|
||||
workers = 8 if backend == "cloud" else 1
|
||||
|
||||
# Main thread: collect the work (transcripts) for sessions needing a summary.
|
||||
todo: list[tuple[str, str, int]] = []
|
||||
|
||||
Reference in New Issue
Block a user