本地大模型日志生成的Python实战

在调用本地大模型的时候，你有没有被海量的原始输出折磨过？直接把模型返回的原始文本扔进日志，不仅后期无法检索，连token成本都算不清楚。我从去年开始系统整理本地大模型的日志生成流程，踩过不少坑，今天把这些经验完整分享出来。

为什么要重视日志生成

很多人部署完大模型就完事了，但真正用过的人都知道：没有结构的日志，等模型出问题的时候你只能干瞪眼。

举一个真实的例子。我有个朋友本地跑了一个7B的模型做问答，某天突然发现响应变慢了，一排查才发现是上下文窗口越积越多导致内存泄漏。如果他的日志系统记录了每次请求的token数量和上下文长度，这个问题本来可以提前发现。

本地大模型的日志生成，本质上是在解决三个问题：可观测性、可追溯性、成本控制。没有日志，模型就是一个黑盒子。

Python环境下日志生成的核心思路

日志生成不是简单打印输出，而是一套完整的数据采集管道。我的方案分为三层：

• 请求层：记录每次API调用的输入prompt、模型名称、时间戳
• 响应层：记录模型输出的token数量、首Token延迟、总响应时间
• 会话层：记录多轮对话的上下文长度变化、累计token消耗

用Python实现这三层，最关键的一点是：不要依赖模型自带的输出。绝大多数本地模型框架（Ollama、LM Studio等）的原始日志都是给人类看的，对机器分析极不友好。

实战：基于Ollama的日志生成方案

Ollama是目前最流行的本地大模型部署工具，我的日志方案就是基于它设计的。

第一步：拦截HTTP请求

Ollama对外暴露REST API，Python里直接用requests调用即可。关键是给每次请求加一个唯一的trace_id，便于后续串联。

import requests
import uuid
import json
from datetime import datetime

def call_model_with_logging(model_name, prompt, log_file="llm_log.jsonl"):
    trace_id = str(uuid.uuid4())[:8]
    start_time = datetime.now()
    
    request_payload = {
        "model": model_name,
        "prompt": prompt,
        "stream": False
    }
    
    response = requests.post(
        "http://localhost:11434/api/generate",
        json=request_payload,
        timeout=120
    )
    
    end_time = datetime.now()
    response_data = response.json()
    
    log_entry = {
        "trace_id": trace_id,
        "timestamp": start_time.isoformat(),
        "model": model_name,
        "prompt_tokens": response_data.get("prompt_eval_count", 0),
        "response_tokens": response_data.get("eval_count", 0),
        "prompt_eval_duration_ms": response_data.get("prompt_eval_duration", 0) // 1000000,
        "eval_duration_ms": response_data.get("eval_duration", 0) // 1000000,
        "total_duration_ms": (end_time - start_time).total_seconds() * 1000,
        "prompt": prompt[:200],  # 截断避免日志过大
        "response_preview": response_data.get("response", "")[:200]
    }
    
    with open(log_file, "a", encoding="utf-8") as f:
        f.write(json.dumps(log_entry, ensure_ascii=False) + "
")
    
    return response_data["response"]

第二步：处理结构化日志

上面生成的JSONL日志，每行是一个完整的请求记录。但直接读JSONL文件不利于分析，我写了一个简单的日志聚合函数：

import json

def analyze_logs(log_file="llm_log.jsonl", days=7):
    stats = {
        "total_requests": 0,
        "total_prompt_tokens": 0,
        "total_response_tokens": 0,
        "avg_response_time_ms": 0,
        "model_usage": {}
    }
    
    with open(log_file, "r", encoding="utf-8") as f:
        logs = [json.loads(line) for line in f]
    
    for entry in logs:
        stats["total_requests"] += 1
        stats["total_prompt_tokens"] += entry["prompt_tokens"]
        stats["total_response_tokens"] += entry["response_tokens"]
        stats["avg_response_time_ms"] += entry["total_duration_ms"]
        
        model = entry["model"]
        if model not in stats["model_usage"]:
            stats["model_usage"][model] = 0
        stats["model_usage"][model] += 1
    
    if stats["total_requests"] > 0:
        stats["avg_response_time_ms"] /= stats["total_requests"]
    
    return stats

if __name__ == "__main__":
    stats = analyze_logs()
    print(f"总请求数：{stats['total_requests']}")
    print(f"平均响应时间：{stats['avg_response_time_ms']:.2f}ms")
    print(f"模型使用分布：{stats['model_usage']}")

日志生成的进阶技巧

多轮会话的上下文长度追踪

如果你用本地大模型做对话机器人，每次对话都在累积上下文。我遇到过的最棘手的问题是：上下文超过了模型的上下文窗口限制，但没有任何报错，只是响应越来越慢。

解决办法是记录每次对话后的累积token数：

def estimate_context_length(messages, model="qwen2.5"):
    """估算当前上下文的token数量"""
    # 不同模型对token的计算方式有差异，这里用估算
    total_chars = sum(len(m["content"]) for m in messages)
    # 粗略估算：1 token ≈ 1.5 个中文字符
    return int(total_chars / 1.5)

# 在日志中加入上下文长度字段
context_length = estimate_context_length(messages)
log_entry["context_tokens"] = context_length

异常请求的专项日志

本地大模型经常会遇到请求超时、内存不足等问题。这类异常日志需要单独存储并设置告警：

import logging

logging.basicConfig(
    filename="llm_exceptions.log",
    level=logging.ERROR,
    format="%(asctime)s - %(levelname)s - %(message)s"
)

try:
    response = requests.post(url, json=payload, timeout=60)
except requests.exceptions.Timeout:
    logging.error(f"请求超时 - 模型: {model_name}, TraceID: {trace_id}")
except requests.exceptions.ConnectionError:
    logging.error(f"连接失败 - 模型: {model_name}, TraceID: {trace_id}")

成本估算与日志分析

虽然本地部署大模型不需要按token付费，但理解token消耗对优化模型选择和prompt设计至关重要。

模型	参数量	推荐场景	典型Token消耗(次)
Qwen2.5-7B	7B	日常问答	500-1000
GLM-4-9B	9B	长文本处理	1000-2000
Yi-1.5-34B	34B	复杂推理	2000-5000

通过分析日志里的token消耗数据，你可以判断当前的模型选择是否合理。如果日常问答的平均token消耗只有300左右，但你在用34B的模型，那是明显的资源浪费。

写在最后

日志系统看起来是个"锦上添花"的东西，但它是大模型从玩具走向生产环境的必经之路。我的建议是：从第一天就开始记录，不要等到出了问题才想起来。

如果你的日志文件已经开始膨胀，说明大模型的利用率在上升，这时候更应该花时间做好日志分析，把数据变成优化决策的依据。

完整代码已整理到我的GitHub，有兴趣的朋友可以自行下载研究。如果你也有关于本地大模型日志生成的经验或问题，欢迎交流。