Mac 上的本地模型我一直在终端里用，最近想换成 Ollama 官方桌面端：有聊天窗口，断网也能直接用。结果装好后碰到了两件怪事：一启动就“闪退”，聊天时随便问一句就“卡住不回答”。翻了日志才发现，两件事都不是程序坏了，日志里写得清清楚楚。这篇把排查过程记下来。
环境：MacBook Pro（M5 Pro，Ollama 识别到可用显存 17.8 GB），Ollama 桌面端 0.40.6，本机已有 qwen3.5:9b 和 gemma4:12b 两个模型。
先知道日志在哪
Mac 上 Ollama 的日志都在 ~/.ollama/logs/：
app.log：桌面程序本身，比如启动、退出、界面请求、自动更新。上一次运行的日志会滚动成app-1.log。server.log：真正跑模型的服务，比如加载了哪个模型、上下文多长、每次回答生成了多少 token、用了多久。
遇到问题先看这两个文件，比对着界面猜要快得多。
怪事一：启动就闪退
app-1.log 里，第一个进程启动一秒后收到了一个“交接”信号，然后自己退出了：
10:58:13 starting Ollama version=0.40.6
10:58:14 received app handoff signal, shutting down
10:58:14 shutting down desktop server而 app.log 里，紧接着启动的第二个进程先给第一个进程发了信号，然后正常跑起来，服务也在 127.0.0.1:11434 上开始监听了：
10:58:14 starting Ollama
10:58:14 signaling Ollama app process pid=33519 signal="user defined signal 1"
10:58:16 Listening on 127.0.0.1:11434 (version 0.40.6)原来是程序被打开了两次：可能是双击了两下，也可能是安装完自动打开了一次。Ollama 的设计是新进程接管、旧进程退出，旧的那个窗口一关，看起来就像闪退了。再加上 Ollama 在 Mac 上平时只在顶部菜单栏显示一个小羊驼图标，不常驻 Dock，窗口关了就以为程序没了。
解决办法：点菜单栏的小羊驼图标，选“Open Ollama”；或者在终端运行 open -a Ollama。要确认是不是真崩溃，可以看 ~/Library/Logs/DiagnosticReports/ 里有没有 Ollama 的崩溃报告。我这次一份都没有。
怪事二：随便问一句就卡住
这个更有意思。界面上一直转圈，最后没有回答。但 server.log 显示模型其实在正常工作，而且速度不慢：
vram-based default context total_vram="17.8 GiB" default_num_ctx=4096
new prompt, n_ctx_slot = 4096, task.n_tokens = 3381
n_gen = 704, tg = 38.55 t/s
eval time = 18747 ms / 715 tokens (38.09 tokens per second)
stop processing: n_tokens = 4095, truncated = 1把这几行连起来看，事情就清楚了：
- 上下文只有 4096。桌面端按显存大小自动选了一个默认值，17.8 GB 显存也只给了 4096。
- 输入已经占了 3381。我在同一个对话里问了好几轮，之前的问答，加上桌面端自带的系统提示，全都算在里面。
- 模型一边“思考”一边往下写，写到第 715 个 token 时，3381 + 715 正好撞上 4096 的上限。
- 日志里记了
truncated = 1：被截断了。多半是思考还没结束就被截掉，正文根本没来得及写出来，界面上看到的就是“卡住、没有回答”。
同一个对话聊得越久，输入越长，留给回答的空间越少，这个问题就越严重。
改法：把上下文调大
在菜单栏图标打开 Settings，把 Context length 从 4k 拉到 32k。改完以后，server.log 开头的配置变成了 OLLAMA_CONTEXT_LENGTH:32768，模型加载时也是 n_ctx_slot = 32768。
之后同一天晚上用 qwen3.5:9b 聊了一阵，日志里一次截断都没有。挑几条看：
| 输入 token | 生成 token | 生成速度 | 耗时 |
|---|---|---|---|
| 25 | 1396 | 47 t/s | 30 秒 |
| 1179 | 2250 | 47 t/s | 50 秒 |
| 1346 | 5958 | 45 t/s | 2 分 13 秒 |
| 6837 | 5202 | 44 t/s | 2 分 8 秒 |
| 11249 | 3751 | 43 t/s | 1 分 33 秒 |
一轮对话的总长度超过一万两千 token 也能正常回答，生成速度一直稳定在每秒 43–47 个 token，32k 上下文对这块芯片的显存完全没有压力。
但表格也暴露了另一件事：一个只有 25 个 token 的短问题，生成了将近 1400 个 token；有一次生成了将近 6000 个。这些大部分是模型的“思考过程”。上下文调大解决的是“答不出来”，解决不了“答得慢”。日常问答如果嫌慢，就需要关掉思考模式，或者换用不带思考的调用方式。我在《4GB 显卡跑本地模型》里专门写过思考模式的代价。
几条经验
- “闪退”“卡死”先看日志再下结论。这两次都不是程序坏了，日志里一个写着“交接退出”，一个写着“截断”。
- 桌面端的默认上下文偏保守。显存够用就主动调大，16k 到 32k 对日常对话比较合适。
- 长对话会悄悄吃掉上下文。换话题时开个新对话，比在一个对话里一直聊更稳。
- 看
eval count和答案长度差多少。差得远，时间就是花在思考上了。