本地大模型跑长文本，换掉 Ollama 后我发现了两个隐藏差距
我玩本地大模型快半年，最耽误我的一个认知，就是总把 Ollama 当成本地 AI 的终点。装的时候确实爽，一条命令就能把模型拉起来，接口也现成，很多场景看起来不用再多折腾。但当我把同一个 Qwen3.8-27B 分别交给 Ollama 和 llama.cpp，在 128K 上下文下跑同一类任务时，结果让我停住了：Ollama 的 prefill 速度是 720 tok/s，llama.cpp 是 1405 tok/s。
差距不是小幅度提升，而是接近翻倍。它也不是玄学。我把进程、端口和请求链路都翻了一遍，能解释清楚差距来源。
为了避免误读，先说清楚测试条件。Ollama 那组用的是 Q8 权重和 q8 KV；llama.cpp 那组用的是 UD-Q6_K 和 q4 KV。量化方式并不完全一致。不过硬件、模型和任务都保持一致，双 3090 环境，两边也都按各自引擎的常见方式配置。
因此，这组对比想说明的不是谁绝对更强，而是换引擎后，长文本体验会有多大变化。结论很直接：差距不小，体感也很强。
真正拉开差距的有两点：上下文上限和请求链路。
先说上下文上限。Ollama 的 num_ctx 上限被固定在 262144，属于源码层面的限制。想读 30 万字级别的长文档，会直接超出门槛。要突破它，就得改源码、重新编译，还要长期维护自己的分支。多数人不愿意为这件事折腾一晚上。
llama.cpp 没有这种硬上限，上下文能开多大，更多取决于显存。配合 YaRN 外推，我实测跑到了 524K，接近 52 万字。一整本书一次性喂进去，也能正常回答。当时显存占用 37G，还剩 11G 余量。
一个把上限写死在代码里，一个把上限交给显存，产品取向完全不同。
再说速度。Ollama 的速度损耗，主要来自多了一级中间层。
实际看进程时，Ollama 的请求链路比想象中更长。应用端先通过 HTTP 和 JSON 把请求发给 ollama serve，这个进程监听 11434，承担鉴权、调度和排队；随后它再向 llama-server 子进程转发一次 HTTP 请求，并再次进行 JSON 序列化。真正执行推理的是监听 62037 的 llama-server。
换句话说，一次请求会经历两次 JSON 序列化、两次 HTTP 传输，中间还插了一层调度。
短对话时，这点毫秒级损耗几乎无感。但 128K 长文本进入 prefill 后，请求体里可能包含十几万字，序列化、传输和调度开销都会被放大，最终把原本无感的延迟放大成接近翻倍的速度差。
llama.cpp 的 llama-server 则直接承担推理职责。HTTP 请求进来后，直接进入推理引擎，不需要再经过一层转发，也没有第二次中间序列化，链路更短。
从 Ollama 迁移到 llama.cpp 的坑不少，我一共踩过 8 个，按影响大小说一下。
第一个坑是 Flash Attention 参数。新版中建议写完整参数：
--flash-attn on
如果只写短参数：
-fa
它可能把后面的参数吞掉当成自己的值，服务直接启动失败。
第二个坑更隐蔽：漏配 YaRN。你可能已经设置了：
-c 524288
但如果没有同时带上：
--rope-scaling yarn --rope-scale 2.0
服务不会报错，只是悄悄把上下文锁回 26 万字附近。直到长请求真正进来才暴露，排查很耗时。
第三个坑是 Qwen3.8 默认开启 thinking。如果不显式关闭：
--reasoning off
模型会把思考过程写进响应，你要的正文可能为空。
第四个是 prompt cache 造成的测速假象。同一个问题第二次 1 秒返回，看着像提速，实际可能只是命中缓存。测速时必须关闭：
cache_prompt
否则测出来的速度不可信。
第五个是中文 token 换算。中文不能按英文的 0.6 字/token 估算，更合理的经验是按 1.45 字/token 计算。26 万 token 实际可装约 38 万中文字。若按 0.6 估算，显存和成本都会被严重低估。
第六个坑出现在 Windows。直接执行：
kill ollama
不一定会杀掉 llama-server 子进程。我实测中，内存从 24G 掉到 4.5G 后触发 bad_alloc，父进程退出后，子进程仍可能残留，需要单独处理：
Get-Process llama-server | Stop-Process -Force
第七个坑是 MSYS 环境下：
taskkill //F
可能静默失败。更稳的做法是转到 PowerShell，使用：
Stop-Process
结束进程。
第八个是 GGUF 选择。建议认准 UD 版，即 Unsloth Dynamic。它的 Q6_K 相比常规量化，体积更小，精度也更好。
怎么选，主要看场景。
如果只是跑 7B/14B 小模型，做日常聊天和轻量任务，Ollama 足够，不必折腾。
如果经常读代码库、审长合同、跑 Agent 长对话，或者希望多模型切换更顺手，llama.cpp 搭配 llama-swap 更合适。
Ollama 解决的是本地模型能不能快速跑起来的问题，llama.cpp 更偏向解决长文本和复杂工作流里好不好用的问题。对长文档、代码库和 Agent 场景来说，早一点换到更合适的引擎，往往比一直在 Ollama 里和上下文上限较劲更划算。
如果你也被长上下文卡过，点个「在看」，让更多还在 Ollama 里碰壁的人看到。
页:
[1]