多轮对话第二轮500？llama-server进程137退出根因排查

前天有个朋友甩给我一张截图：多轮对话服务的请求打到第二轮，客户端直接报error: 500 internal server error: llama-server process has terminated: exit code 137。后台日志翻来覆去只有这一行，进程没了，第一轮明明还聊得好好的。他在群里下意识地问：是不是模型太笨、上下文太短，要不要换个模型？我把请求体、启动参数和网关配置逐项要过来验了一遍，最后给他的结论是：这锅真不该模型背。多轮对话第二轮就 500，是三个工程问题叠在一起的结果，任何一个单独拆开都像偶发，凑在一起就成了稳定复现的灾难。

这篇文章就把这次排查过程完整写出来。内容包括三个叠加的工程问题、从 500 到根因的定位思路、修复后如何防复发，以及一张可以直接抄作业的常见问题速查表。适合正在用 llama.cpp、Ollama 或类似方案搭本地对话服务的开发者看，也适合所有被“第二轮必挂”折磨过的朋友参考。

1. 现象与第一直觉：为什么大家都先怪模型

1.1 一个半夜两点出现的 500

先还原一下现场。业务层是一个简单的聊天接口，用户发消息后，后端把完整的messages数组转发给 llama-server。第一轮请求很顺利，llama-server 正常返回。第二轮用户继续追问，请求刚发出去，前端收到 500，后端日志里出现一行：

error: 500 internal server error: llama-server process has terminated: exit, code 137

注意两个关键信息：第一，错误被统一包装成了 500；第二，exit code 137不是模型“拒绝回答”的样子，而是进程被信号杀掉的典型表现。在 Linux 下，137 等于 128 + 9，也就是进程收到了 SIGKILL。最常见的触发原因是被操作系统的 OOM killer 干掉，或者被容器/系统强制杀掉。

对部署过本地模型的人来说，这个报错太有迷惑性了，因为错误文本里明晃晃写着“llama-server process has terminated”，看起来就像模型服务本身崩了。于是大家的第一反应都是：是不是模型权重有问题？是不是模型上下文太短？是不是该换个大模型？

实际查下来，llama-server 确实死了，但杀死它的不是模型推理逻辑，而是外面几层工程代码埋下的雷。多轮对话第二轮就 500，本质上不是因为模型“接不住话”，而是请求被放大、资源边界被撞穿、中间层把异常又吞了一道。三层问题叠加在一起，最后才在用户面前炸出一个简单的 500。

1.2 模型背锅的思维定式是怎么来的

这个思维定式很常见，我复盘了一下，大概有三层原因。

第一，多轮对话本身是上下文相关的，用户天然会觉得“第二轮出错”是模型记不住上下文。第二，报错信息里有 llama-server、模型进程这些字眼，大家容易把“进程异常退出”和“模型能力问题”划等号。第三，很多团队的监控只看了 HTTP 状态码和业务日志，没有记录系统层的内存、退出信号、上游耗时，定位时只能从现象猜原因。

但要拆穿这个定式，只需要一个意识：500 是 HTTP 状态码，是应用层返回给客户端的。它和服务端到底发生了什么没有直接对应关系。进程被杀、请求超时、网关断连、内存不足，这些原因都可以被包装成 500。所以看到 500 的正确姿势，是先把它当成一条普通的 HTTP 链路故障来排查，而不是直接归因到模型。

2. 三个工程问题叠加的完整拆解

2.1 第一层：上下文无脑拼接，第二轮请求体直接爆了

很多多轮对话实现有个偷懒写法：把用户和模型的历史消息全部存下来，每轮请求一次性把所有历史发过去。第一轮只有一条用户消息，第二轮会加上第一轮的user和assistant两条消息，第三轮再加两条。第二轮开始，请求体基本是翻倍增长。

如果模型上下文窗口是 2048 tokens，第一轮用户问 50 tokens，模型回 800 tokens，看起来还很宽裕。但第二轮请求会把第一轮的 850 tokens 整个带上，再加新问题，已经接近 900+ tokens。如果模型回答里有大段代码、日志分析、表格的话，第二轮直接就能冲到 1500 甚至 2000 tokens 以上。一旦超过--ctx-size的配置值，llama-server 的行为就会变得不稳定。

这里需要解释一下 llama-server 内部发生了什么。llama.cpp 在推理时需要为每个请求分配 KV cache 空间，这个空间由上下文窗口大小决定。请求的 token 总数一旦接近或超过配置的上下文长度，KV cache 的分配会非常大。如果显存或内存不足，C++ 内部可能直接抛出异常，进程报错退出；更常见的是操作系统发现内存占用失控，OOM killer 直接把进程杀掉。

用数字算一笔账：假设模型的 hidden size 是 4096，层数是 32，上下文窗口配置为 8192。KV cache 大致占用的字节数是2（K和V）× 32（层数）× 8192（上下文）× 4096（hidden size）× 2（fp16），算下来大约 4.3 GB。这还只是一个请求。如果同时有 2 个请求进来，这个数字直接翻倍。很多人的本地机器只有 8G 或 16G 内存，模型权重再占掉 4~6G，第二轮请求一到，内存瞬间见底，进程 137 退出是必然的。

所以第一层问题不是模型不行，而是业务层把上下文请求体越喂越大，服务端资源跟不上，进程被杀。

2.2 第二层：推理服务参数按单轮配置，资源边界一碰就死

第二个叠加的问题，出在 llama-server 的启动参数上。很多教程会让人直接跑一个默认命令，或者照抄某个大模型卡的推荐参数，完全没考虑当前机器的实际内存和显存。

比如有人用-c 8192把上下文窗口开得很大，看起来很爽，但 KV cache 的分配不是按“实际用多少”来的，而是按配置的上限来的。llama.cpp 在初始化阶段就会为这个上下文长度预留大量内存。如果你还顺手把--parallel设置为 4，那就要同时给 4 个请求预留 4 份 KV cache，内存占用直接爆炸。在低配机器上，服务启动可能没问题，因为模型只是加载到内存，真正推理时才去访问缓存；一旦第二轮请求到达，内存分配失败，系统开始换页，接着进程被杀。

还有一个隐蔽点：很多人只关注 GPU 显存，忽略了 CPU 内存。llama-server 默认会把部分权重放在内存里，如果同时加载 GPU 层数和上下文缓存，CPU 内存也会被大量消耗。--n-gpu-layers设太高，显存满了；设太低，内存压力大。两边都可能成为压死进程的那根稻草。

这里要说一句公道话：模型本身没有错，模型权重不负责管理内存，也不负责判断你的机器能不能扛住这么多并发。服务启动参数、上下文长度、并发数，这些全是工程决策。决策错了，换再好的模型也一样崩。

2.3 第三层：网关超时与错误处理把真实原因全吞了

第三个问题更隐蔽，它不在模型服务上，而在链路中间的网关上。

实际部署中，llama-server 很少直接被前端调用，前面通常还挂着一层 Nginx 或者 API 网关。Nginx 的默认proxy_read_timeout是 60 秒。第一轮请求小、生成快，可能 20 秒就返回了；第二轮请求大、历史长，模型要读取更多 token，生成时间很容易超过 60 秒。这时 Nginx 会主动断开连接，客户端拿到的就是一个 500 或者 504，而后端 llama-server 其实还在慢慢生成。

更麻烦的是，如果业务层做了统一异常处理，把上游所有异常都 catch 住，然后包装成一行500 Internal Server Error，真实原因就被彻底吞掉了。日志里既没有 llama-server 的 stderr，也没有每个阶段的耗时，只看得到一行“500”。排查的人只能对着现象猜。

这三个问题是怎么叠加成“第二轮必挂”的？

第一轮请求小，上下文没爆，生成快，网关也没超时，所以一切正常。第二轮请求变大，上下文拼接先触到资源上限，可能 OOM；即使没 OOM，生成时间也会变长，网关超时又正好在这个阈值附近；更糟糕的是，业务层把 OOM 和超时都归成同一个 500，导致你分不清到底是哪一个先发生的。三个问题相互掩盖，症状却完全一致：第二轮 500，进程终止。

3. 从 500 到根因，我的排查实录

3.1 先对齐时间线，再谈修复

拿到这个事故后，我做的第一步不是改代码，而是让朋友把四类信息拉出来：

• 客户端/网关的请求和响应时间戳；
• llama-server 的系统日志；
• 服务器的系统日志（特别是 OOM 记录）；
• 业务层每一轮请求的messages长度和字符数。

在 Linux 上，查看 OOM 记录非常直接：

dmesg -T | grep -i -E "killed process|out of memory" journalctl -u llama-server --since "10 minutes ago" --no-pager

如果系统日志里出现了类似Killed process 1234 (llama-server) total-vm的字段，基本可以确认进程是被 OOM killer 杀的。再加上退出码 137，第一层问题基本坐实：内存不够，进程被系统结束。

这里有个容易忽略的细节：时间线要对齐。客户端报 500 的时间，和系统日志里进程被杀的时间，必须几乎一致。如果不一致，说明中间还有网关或重试逻辑在误导你。我这次就是因为拿到的错误截图和实际日志时间差了好几分钟，一开始差点被带偏。

3.2 最小复现：用 curl 绕过网关直连后端

第二步是把做链路分离。先用 curl 直连 llama-server，不经过 Nginx，不发长历史。如果直连短请求正常，说明模型服务本身没问题。

curl -v http://127.0.0.1:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "messages": [ {"role": "user", "content": "你好"} ], "max_tokens": 100 }'

然后做第二步：在请求里带上第一轮的完整历史，模拟第二轮的请求体。注意把max_tokens先设小一点，避免生成时间过长，影响判断。

curl -v http://127.0.0.1:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "messages": [ {"role": "user", "content": "帮我总结这份日志"}, {"role": "assistant", "content": "日志中出现多次 ERROR..."}, {"role": "user", "content": "用中文再总结一遍"} ], "max_tokens": 50 }'

这一步非常关键。如果直连并且带完整历史时，llama-server 进程也死掉，说明问题不在 Nginx，而是“长请求 + 资源限制”的组合。如果直连长请求不挂，只是慢，那就重点查 Nginx 超时配置。

3.3 分端验证：把三个叠加问题拆开

为了把叠加的根因拆开，我建议做一个简单的控制变量实验，按下面的表格来测：

表格里的第三行特别重要。当时我用一个很短的请求手动把历史拼到很长，llama-server 直接返回错误并退出，这证明上下文拼接是“引爆点”。然后临时把--ctx-size调大，再把 Nginx 超时从 60 秒调到 180 秒，新请求虽然慢，但服务不再崩溃。这等于验证了三层问题都真实存在。

3.4 修复方案一次性落位

定位清楚之后，修复其实是三个动作并行。

第一，业务层必须做上下文截断。目标是在发送给 llama-server 之前，把历史消息压缩到 token 预算以内。我写了一个简单的 Python 函数，按字符数粗略估算 token，从旧消息开始裁剪，保留最新的对话：

def truncate_messages(messages, budget_tokens=1500): """按 token 预算裁剪历史消息，保留最新内容。""" result = [] used = 0 for msg in reversed(messages): # 粗略估算：1 个中文字符约 1.5 token，英文按字符/4 text = msg.get("content", "") estimated = len(text) * 1.5 + len(text.split()) * 0.5 if used + estimated > budget_tokens: # 如果单条消息就超预算，从这条内部截断 max_chars = int(budget_tokens / 1.5) truncated_text = text[:max_chars] result.append({"role": msg["role"], "content": truncated_text}) break result.append(msg) used += estimated return list(reversed(result))

注意这个函数只做兜底。更成熟的做法是按 tokenizer 精确计算，比如transformers的AutoTokenizer，或者 llama.cpp 自带的 tokenize 接口。预算建议留 20% 余量，比如模型上下文是 2048，业务层就按 1500 预算来截，不要把窗口填满。

第二，修正 llama-server 启动参数。不要盲目追求大上下文，要按机器的实际内存来定。以一台 16G 内存、6G 显存的机器为例，加载 7B 模型时我推荐这样启动：

llama-server \ -m /models/qwen2.5-7b-instruct-q4_k_m.gguf \ -c 4096 \ --parallel 1 \ --batch-size 512 \ -ngl 32 \ --host 127.0.0.1 \ --port 8080

-c 4096充当一个折中值，既不会让 KV cache 爆掉，也能覆盖大多数多轮对话场景。--parallel 1明确告诉服务端同一时间只处理一个请求，避免多份 KV cache 同时分配。-ngl 32表示前 32 层放 GPU，剩下层走 CPU，平衡显存和内存压力。具体参数不要照抄，上线前用htop或nvidia-smi观察峰值内存再微调。

第三，调整网关超时和错误日志。Nginx 这样配置：

location /v1/ { proxy_pass http://127.0.0.1:8080; proxy_connect_timeout 10s; proxy_read_timeout 180s; proxy_send_timeout 180s; proxy_buffering off; }

proxy_buffering off很关键，因为大模型接口通常需要流式输出，如果 Nginx 还做缓冲，首字延迟和超时问题都会被放大。同时把 access_log 里加上$upstream_response_time，这样后续能直接看到上游到底花了多久。

4. 修复之后，如何防止下次再背锅

4.1 健康检查与自动拉起，别让服务裸奔

模型服务进程被杀之后，如果没人自动拉起来，下一次请求仍然是 500。所以修复完参数和上下文之后，第一件事是给服务加健康检查和自动重启。

如果你用 systemd 托管 llama-server，可以这样配置：

[Service] ExecStart=/usr/local/bin/llama-server -m /models/model.gguf -c 4096 --parallel 1 Restart=always RestartSec=3 [Install] WantedBy=multi-user.target

如果你用 Docker Compose，可以加 healthcheck：

services: llama: image: ghcr.io/ggml-org/llama.cpp:server command: ["-m", "/models/model.gguf", "-c", "4096", "--parallel", "1"] restart: always healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8080/health"] interval: 10s timeout: 5s retries: 3

不过要提醒一句：自动重启只是止血，不是治本。如果请求体依然无脑拼接，进程还是会反复被杀。所以健康检查一定要配合告警，比如进程重启次数超过阈值就通知人；否则半夜里服务悄悄重启一百次，你也看不见。

4.2 错误分类返回，不要把所有异常都叫 500

这次排查过程中最让人头疼的，就是所有异常都被包装成了同一个 500。为了让下次能快速定位，我建议在业务层做异常分类。不同问题应该返回不同状态码，并且带上request_id、错误码和上下文信息。

比如用 FastAPI 写一个全局异常处理器：

class ContextOverflowError(Exception): """输入超过上下文预算。""" @app.exception_handler(ContextOverflowError) async def handle_context_overflow(request, exc): return JSONResponse( status_code=413, content={ "error": "context length exceeded", "request_id": request.headers.get("X-Request-ID"), "message": "please shorten the conversation history" } )

这里的思路是：输入太长就返回 413，上游超时就返回 504，服务正忙就返回 503，进程被杀了再返回 500。每一类错误对应不同的排查路径。用户看到 413 就不会骂模型，后端看到 504 第一反应是查 Nginx 超时而不是查模型。这个改动投入很小，但对排查效率的提升非常大。

4.3 多轮对话上下文管理的三种选择

上下文截断只是最基础的手段。如果你的产品需要长时间对话，建议从下面三种策略里选一个，或者组合使用。

第一种是最近窗口截断。只保留最近 N 轮对话，更早的丢弃。实现简单，适合客服、问答这类短对话场景。缺点是一旦客户长篇大论，老信息丢失，模型看不到前置条件。

第二种是摘要压缩。每次对话一定轮数后，用模型把当前历史总结成一段摘要，下次请求只带摘要和最近几轮原文。这种方法能在不丢失核心信息的前提下控制 token 数量，适合知识整理、报告生成类场景。缺点是摘要本身会消耗一次模型调用，还可能引入信息损失。

第三种是检索增强。把历史消息切段、向量化，根据当前用户问题做相似度检索，只取最相关的片段放到 prompt 里。这种方法适合系统性长对话，但工程复杂度高，需要引入向量数据库。

我的建议是：先用“最近窗口截断 + 摘要兜底”的组合，不要一上来就上 RAG。上线跑一段时间，如果确实发现用户会引用很早以前的内容，再考虑检索增强。工程上讲究循序渐进，别给自己挖坑。

4.4 常见问题速查表与避坑心得

把这次排查中遇到的问题，加上平时工作中常见的同类问题整理成了一张速查表：

除了这张表，再说几个我踩出来的细节。第一个是别只看 HTTP 状态码，退出码、信号、内存曲线这些信息比状态码有价值得多。第二个是压测的时候一定要压多轮，不能只压单轮。你只测一轮永远发现不了第二轮崩的问题。第三个是日志要结构化，每层都带上request_id、token 数、上游耗时。没有日志支撑，排查就像蒙眼走路。第四个是模型卡片的上下文长度是训练长度，不等于安全使用长度。上线前先实测峰值内存，再定业务层预算，永远给自己留余量。

这次排查给我的最大感受，不是技术多高深，而是“模型背锅”太常见了。我后来给自己立了个规矩：看到 500，先不要碰模型，把它当成一条普通 HTTP 链路故障来查。先问三个问题：请求长什么样？进程还活着吗？中间层说了什么？把这三个问题理清楚，绝大多数事故都会从“模型崩了”变成“工程修复”。再说个笨办法：搭好多轮对话服务后，第一件事就是写一个脚本连打五轮，每轮把历史报文大小打出来；第二件事是专门压一轮长回答。这两件事做完，能帮你躲掉我踩过的八成坑。