从 Ollama 转向 vLLM：寻求高通量 LLM 服务的稳定性

简介

在过去的一年里，我一直在大量使用 GraphRAG（微软版本和我自己开发的版本），我总是惊讶于文档复杂性的微小增加会造成多大的预算浪费。

当我使用gpt-4.1-miniOpenAI 时——仅一套文档就花费了我 200 多美元（！！）。

即使使用gpt-4.1-nano（目前最便宜的前沿模型），我的预算也是荒谬的。为几份（确实很大的）文件花费 2.15 亿个代币是荒谬的，而且需要几天的时间来处理，这太过分了。

当我第一次开始在我信赖的 NAS 上部署本地大型语言模型 (LLM) 时，Ollama 立刻脱颖而出，成为实现这一目标的最佳选择。它简单易用，使用 Docker 即可快速设置，并支持大型上下文窗口——非常适合 GraphRAG 的苛刻用例。使用谷歌最新的 Gemma3 开源模型，能够处理高达 128K 的 token 提示，这一点尤其吸引人。

然而，当我开始将 Ollama 推向极限时，问题很快就浮现出来。它的上下文窗口计算异常不一致，经常以随机大小（例如 35,567 个令牌）而不是配置的 128K 来结束。这经常导致模型在较重的工作负载下停滞或卡住。