网硕互联帮助中心摘要
Ollama 封装 llama.cpp 带来易用性，但代价藏在架构里。本文通过实测进程扒出真相：Ollama 请求需经两次 HTTP + 两次 JSON 序列化（client → ollama serve:11434 → llama-server:62037），与 llama.cpp 单次直连形成对比。128K 上下文 prefill 实测 720 vs 1405 tok/s，差距近 2 倍。附 8 个迁移避坑 + 黄金配置。
一、实测环境与数据条件声明
| 引擎 | 0.33.0 | b10822 (CUDA 12.4) |
| 权重 | Q8_0 | UD-Q6_K |
| KV 缓存 | q8_0 | q4_0 |
| 硬件 | 双 RTX 3090 (48GB) | |
| 任务 | NIAH 10/50/90% + Recall + Reason @128K | |
数据条件声明：两组非严格同配置（量化档不同），但硬件/模型/任务一致，且各自为引擎典型用法。差距归因：引擎转发层为主，量化差异为次。
二、机制拆解：两次 HTTP 转发的真相
实测进程树扒出的请求路径：
client → ollama serve(:11434) → llama-server(:62037) → model
关键发现：Ollama 的 runner 是独立 HTTP 服务（实测端口 62037），主进程收到请求后二次转发。这意味着：
- JSON 序列化/反序列化 2 次（长上下文时数据量成倍）
- HTTP 传输 2 趟（网络栈开销翻倍）
- 中间多一层调度排队（并发时锁竞争）
llama-server 直连：序列化 1 次、HTTP 1 趟、无中间调度层。短上下文（毫秒级）无感；128K prefill 时请求体 10 万字级，开销被放大到近 2 倍。
三、实测性能
| 128K | 1159~1405 tok/s | ~720 tok/s |
decode 阶段差距收窄（受模型本身限制），差距集中在 prefill（长文本首字）——这正是"长文等得久"感知的来源。
四、上下文上限：硬编码 vs 显存边界
Ollama：num_ctx 上限 262144 源码硬编码，突破需改源码重编译。llama.cpp：无硬上限，YaRN 外推实测 524K 全绿（37G 显存，余量 11G）。
五、迁移避坑（8 坑实测）
| 1 | -fa 参数 | 启动失败 | –flash-attn on |
| 2 | 忘配 YaRN | n_ctx 静默回落 262K | –rope-scaling yarn –rope-scale 2.0 –yarn-orig-ctx 262144 |
| 3 | thinking 未关 | 输出被思考吞掉 | –reasoning off |
| 4 | prompt cache | 重复请求秒回 | 测试 cache_prompt: false |
| 5 | 中文 token | 按 0.6 低估 | 中文约 1.45 字/token |
| 6 | 僵尸进程 | RAM 24G→4.5G | Get-Process llama-server | Stop-Process -Force |
| 7 | taskkill //F | MSYS 静默失败 | PowerShell Stop-Process |
| 8 | GGUF 版本 | 精度/大小差异 | 认准 Unsloth UD 版 |
六、配置速查
# 128K 起手
./llama-server -m Qwen3.8-27B-UD-Q6_K.gguf -c 131072 -ngl 99 \\
–flash-attn on –cache-type-k q4_0 –cache-type-v q4_0 \\
–reasoning off –mlock –no-mmap
# 524K 全量（+YaRN 三件套）
# -c 524288 –rope-scaling yarn –rope-scale 2.0 –yarn-orig-ctx 262144
七、结论
Ollama 的易用性有价值，但其两次 HTTP 转发的架构在长文本场景付出显著性能代价，262K 硬上限更是架构级限制。长上下文/极致性能场景推荐 llama.cpp（可配 llama-swap 补全模型管理）。欢迎评论区交流。
评论前必须登录！
注册