Ollama 能不能上生产：本地好用不等于扛得住线上
我见过不止一次这样的场景：某个同事周末在自己笔记本上装了 Ollama，ollama run 一敲，模型跑起来了，对话框里字一个个往外蹦，整个过程不到十分钟。周一站会上他很兴奋地说：“这玩意儿太简单了，咱们那个内部问答直接用它上线得了，省下一大笔 API 钱。”
这个念头本身没错，甚至值得认真评估。但”跑起来”和”能扛住线上流量”之间，隔着一整套完全不同的要求。这篇不打算劝你别用 Ollama——恰恰相反，它在自己的主场是我见过最省事的工具。我想做的是把两个场景的要求差在哪儿讲清楚，让你自己判断你的场景落在哪一边。
先把两个场景的要求摆在一起看
本地开发跑模型，你在意的是：装起来快不快、换模型方不方便、能不能离线、会不会污染系统环境。这几件事满足了，工具就是好工具。至于它同时能接几个请求、崩了怎么自动拉起、显存不够时排队还是报错——你根本不会问，因为屋里就你一个用户，慢了就等一会儿，挂了就重启。
生产推理服务在意的是另一批事：多人同时打进来会不会互相拖垮、峰值时排队策略是什么、模型驻留在显存里还是被换出去、监控指标从哪儿读、谁能调用谁不能调用、进程挂了几秒内恢复、升级版本时怎么不断流。这些问题一个都绕不开，因为用户不是你自己，出问题的成本也不由你一个人承担。
同一个二进制，放在两套要求下，得分可能天差地别。这不是软件好坏的问题，是设计目标的问题。
它擅长的那一半，是真的擅长
先说 Ollama 的强项，这部分我认为没什么可争议的。它的命令行几乎不需要文档：
| 命令 | 做什么 |
|---|---|
ollama pull <model> | 拉一个模型到本地 |
ollama run <model> | 跑起来并直接进对话 |
ollama list | 看本地已经装了哪些模型 |
ollama ps | 看当前有哪些实例在跑 |
ollama serve | 起后端服务 |
ollama launch <integration> | 初始化集成（官方 README 举的例子是 claude、openclaw） |
服务起来之后，REST API 的默认地址是 http://localhost:11434，聊天走 /api/chat 端点。其余端点官方 README 指向 /api 参考文档，具体清单以官方文档当次为准。
就这么几条，覆盖了本地开发九成的需求。落到具体场景，我认为下面这几类它基本是最优解：
本地开发和调试。 你在写一个要调模型的功能，逻辑还没定型，提示词还在改。这时候每改一版就打一次云端 API，钱倒不见得多，但你会被网络抖动、限速、账号额度这些跟你的功能毫无关系的东西打断。本地跑一个够用的模型，把逻辑跑通、把提示词磨顺，再切到线上模型做效果验证，这个顺序省时间也省心。
离线演示。 去客户现场做 demo，会议室的网络是什么状况你事先不知道。我见过 Wi-Fi 要门户认证、见过出口封了境外域名、见过网线插上但 DNS 解析不了。带一台装好 Ollama 的笔记本，拔了网线也能演，这个确定性值很多钱。
数据不能出机器的原型。 有些内部文档、有些客户资料，合规上就是不允许发到外部服务。要验证”用大模型处理这类文本到底靠不靠谱”这个问题，本地跑是唯一能立刻动手的路径。等验证完了，再去走数据出境或者私有化部署的流程也不迟。
新人上手。 团队来了个没碰过大模型的同学，让他先在自己机器上跑起来、感受一下模型是怎么回事、上下文长度是什么意思、温度参数改了会怎样。这个学习成本用 Ollama 压到了最低。
这四类场景有个共同点：单人、低并发、可容忍中断、不承诺 SLA。只要你的需求还在这个圈里，别折腾，用它就好。
上线前必须问自己的六个问题
如果你的需求已经跨出那个圈了，下面这六个问题就得逐个回答。我不打算替你给结论——每个人的负载、硬件、团队都不一样，结论应该是你实测出来的，不是从文章里抄来的。我能给的是该问什么、怎么问。
一、并发能力：这是上线前必须实测的第一项
单人用的时候，你永远只有一个请求在跑。生产上不一样：五个人同时提问，第六个人的请求是排队等着，还是跟前面的一起批处理，还是直接被拒？这三种行为对用户体验的影响完全不同。
Ollama 具体怎么配并发，本文不写任何配置项名称——官方 README 里没有列出相关的环境变量名，我不会凭印象给你一个可能是错的变量名，那比不写更糟。正确的做法是执行 ollama serve --help 看当前版本实际支持哪些选项，并对照官方文档确认语义。
但不管配置怎么写，实测这一步跳不过去。方法很朴素：写个脚本，用你真实的提示词长度和期望的输出长度，起 N 个并发打过去，从 N=2 开始翻倍，记录每一档的首字延迟、完整响应时间、以及有没有请求失败。你会看到一个明显的拐点——过了那个点，延迟不是线性上升而是陡增，或者开始出现失败。那个拐点前一档，就是你这套硬件配这个模型的安全并发数。
拿到这个数，再对照你的真实峰值。峰值是多少？别拍脑袋，去看现有系统的日志，或者按”活跃用户数 × 人均每分钟请求数”估一个，然后乘个安全系数。如果安全并发数明显低于峰值，剩下的选择只有三条：加机器、换框架、或者接受排队并在前端把等待表达清楚。
二、显存占用与冷启动
模型加载进显存要时间，这个时间取决于模型大小和磁盘速度，短则数秒，长则更久。问题是：请求间隔一段时间没来，模型会不会被卸载？下一个请求来的时候要不要重新加载？如果会，那第一个用户体验到的延迟就是”加载时间 + 推理时间”，而这个人可能正是你的老板。
这个行为怎么控制，同样以 ollama serve --help 和官方文档为准。你要做的是先把行为观测出来：起服务，跑一次请求，用 ollama ps 看实例状态；然后放着不动一段时间，再看 ollama ps 还在不在；再打一次请求，掐表量首字延迟。做几轮，你就知道你的实例会不会被换出、换出后重新加载要多久。
顺带一提，显存够不够用本身也是个要提前算的问题。模型权重占多少、KV cache 要留多少、还得给激活和碎片留余量——这套估算方法我在显存怎么估里单独讲过，那是方法而不是结论，具体数字必须以你自己的硬件实测为准。
三、可观测性：出问题时你能看到什么
这是我认为最容易被低估的一项。线上服务半夜变慢了，你手上有什么？
对比一下就很清楚。vLLM 的 OpenAI 兼容服务在官方 API 清单里明确列出了一组基础设施端点：/health（健康检查）、/metrics（Prometheus 格式指标）、/v1/models（当前提供哪些模型）、/version、/load。这几个端点的存在意味着什么？意味着它能直接接进你现有的健康检查探针和监控体系——负载均衡器拿 /health 判断要不要摘节点，Prometheus 拉 /metrics 出图表和告警，/v1/models 用来确认服务端暴露的模型名跟客户端调用的对不对得上。这套东西不需要你写任何胶水代码。
Ollama 这边提供哪些运维用途的端点，README 只说了聊天端点是 /api/chat，其余指向 /api 参考文档——所以我不在这里列清单，你需要自己去官方文档核对当前版本有什么。核对时重点看三件事：有没有一个不消耗推理资源就能返回的健康检查路径；有没有结构化的指标输出；出错时的响应体里有没有足够定位问题的信息。
如果这三项都没有现成的，也不是不能上，但你得自己补：写个探针脚本定期打一个极短的请求当健康检查，从日志里 grep 出耗时做粗粒度统计。补得出来就能上，补不出来就别上——没有可观测性的线上服务，等于开着没有仪表盘的车。
四、鉴权与网络边界
Ollama 的 REST API 默认地址是 http://localhost:11434。注意 localhost 这个前缀，它说明默认的设计假设就是”服务和调用方在同一台机器上”。这个假设在本地开发时非常合理，也很安全——外面的机器根本连不上。
一旦你要让别的机器调用它，这个假设就被打破了。改监听地址的方式以官方文档为准，但打破之后的问题是确定的：谁都能调，而且默认没有身份概念。没有 key、没有配额、没有按人计费，任何能路由到这个端口的人都可以让你的 GPU 免费干活。
这不是危言耸听。公网上扫描常见端口的机器人一直在跑，你把一个推理端口裸奔在公网上，被人白嫖算力只是时间问题。稳妥的做法是：永远不要把推理服务直接暴露给不可信网络。让它只监听内网地址，前面放一个网关或反向代理，鉴权、限流、审计日志都在网关那层做。这样推理引擎只管推理，安全边界统一在一个地方管，换引擎的时候安全策略不用重写。
五、单机单进程的失效域
问自己一个很简单的问题：这个进程挂了，会发生什么？
如果答案是”所有请求全挂，直到有人手动重启”，那你的失效域就是整个服务。这在内部工具上可能可以接受，在对外服务上通常不行。
要降低失效域，路径无非几条：进程级别用 systemd 之类的守护，挂了自动拉起，这能把恢复时间从”人发现并处理”压到秒级；再往上是多副本，两台机器各跑一份，前面负载均衡，一台挂了另一台顶着——但这要求你有第二块 GPU，成本直接翻倍，同时也带来新问题：两个副本的模型版本怎么保证一致、请求怎么分配才不会一台闲一台爆。
这里没有便宜的答案。我想强调的是：在决定用什么之前先想清楚你能接受多长的故障时间，这个数决定了你该花多少钱。如果业务方说”停半小时也没事”，那单机加自动重启就够了；如果说”不能停”，那预算得按双份准备，而且要提前把切换逻辑测过。
六、版本与升级管理
本地开发时升级是好事，新版本有新特性、修了 bug，升就完了。生产上升级是风险动作：新版本可能改了行为、可能改了默认值、可能对某些模型的支持方式变了。
上线前你得回答：**当前跑的是哪个版本？这个版本的构件能不能重现？**如果你的部署方式是”在机器上敲个安装命令”，那半年后这台机器坏了，你重新装一遍拿到的是最新版，跟原来那个未必一样。用容器镜像并锁定 tag、或者至少把版本号记录在部署文档里，是把”能重现”这件事变成可能的最低成本做法。
还有升级窗口。单副本的服务，升级必然意味着中断——旧进程停、新进程起、模型重新加载。这段时间有多长，要提前量出来，并且选在低峰期做。别在周一上午升级，这是血泪教训。
和 vLLM 的差异：在定位，不在跑分
我要特别澄清一件事：这篇文章不会说”Ollama 性能差”。我没有可靠的对比数据，凭印象说性能是不负责任的，而且不同模型、不同硬件、不同请求形态下的结论很可能是反的。
真正可以摆出来说的差异，是两者暴露给运维的接口不一样，而这反映的是设计目标。
vLLM 的官方优化文档里，围绕显存和吞吐给出了一整套面向服务的参数：gpu_memory_utilization 控制给 KV cache 留多少空间（官方说法是提高它可以给 KV cache 更多空间）、max_num_seqs 限制一批里的并发请求数、max_num_batched_tokens 控制单批次最大 token 数并影响 prefill 与 decode 的平衡、max_model_len 限制单序列最大长度、tensor_parallel_size 把权重切到多张卡上、pipeline_parallel_size 把层分布到多张卡上、kv_cache_memory 直接指定 KV cache 大小。官方甚至给出了遇到 OOM 或者「not enough KV cache space」时的处理顺序：先提高 gpu_memory_utilization，再降低 max_num_seqs 或 max_num_batched_tokens，再提高 tensor_parallel_size（代价是同步开销），最后提高 pipeline_parallel_size（代价是延迟）。
这些参数的默认值官方页面没有明确给出，所以我一个都不写——要用的时候去官方文档查当次版本的取值。但参数体系本身说明了问题：一个工具会把哪些旋钮暴露出来，反映了作者预期它会被谁、在什么场景下使用。当一个工具同时提供了并发上限、显存占比、多卡切分策略、以及 /health 和 /metrics，它显然预期自己会被一个运维团队接管。启动方式也很直白，vllm serve <model>，官方示例是 vllm serve NousResearch/Meta-Llama-3-8B-Instruct，具体启动参数我在 vLLM serve 怎么用里另讲。
Ollama 的旋钮暴露得少，是因为它的预期用户是开发者本人而不是运维团队。少旋钮在本地是优点——不用配置就能跑，谁不喜欢。但在生产上，你需要的恰恰是那些旋钮。
关于两条路线更完整的对比，可以看自建还是买 API和 vLLM 是什么。
我推荐的务实路线
讲了这么多，落到实操上，我会这么安排：
开发环境用 Ollama，生产环境用面向服务的推理框架，中间用统一网关抹平差异。
这个组合的好处是每一层都在做自己擅长的事。开发同学在自己机器上装 Ollama，改代码不用等网络、不烧额度、不怕把线上配额打爆。生产上跑一套有并发控制、有健康检查、有指标输出的推理服务，运维团队能用他们熟悉的方式接管。
关键在中间那层网关。网关对上游暴露一套统一的调用协议，对下游把请求转发到实际的推理后端。这样带来三个直接收益：
第一，应用代码只写一次。开发环境和生产环境的差异被网关吃掉了，应用只知道”我往这个地址发请求”，不知道背后是谁在跑。切换后端不用改一行业务代码。
第二，鉴权和限流有地方放。前面说过推理引擎本身可能没有身份概念，那就在网关做——每个应用一个 key，key 上挂配额和模型白名单，超了就拒。这套东西做一次，所有后端都受保护。
第三，留出了灰度和回退的余地。想试新框架，网关上把 5% 流量切过去看看，有问题切回来，业务无感。没有网关的话，这种试验要么不敢做，要么做起来就是一次全量赌博。
代价是多一跳网络和一套要维护的组件。如果你只有一个应用、一个模型、一台机器，这个代价可能不划算，直连就好。但只要应用数超过两个，或者你预期半年内会换后端，网关基本一定回本。
什么情况下 Ollama 上生产是合理的
现在回到最初那个问题。我的答案是：在下面这几个条件同时成立时，Ollama 上生产完全合理，而且是明智选择。
- 内部工具，不对外。 用户是同事，出问题能在群里说一声，不会上社交媒体。
- 并发确实低。 不是”我觉得低”，是你按前面的方法实测过、并且对照过真实峰值之后确认低。
- 单机能扛，且你接受它的失效域。 挂了重启、重启期间没人干活，这个后果业务方明确点过头。
- 有人值守。 不是说要 7×24 盯着，是说工作时间内有个明确的人负责，出问题有人处理，不是”上线了就没人管了”。
- 数据必须留在本地。 如果这条成立，它甚至能反过来抵消掉前面几条的不足——因为你根本没得选。
满足这些条件的场景比想象中多：部门内部的文档问答、给几个人用的代码辅助、跑批处理的离线任务（这类甚至不在乎延迟）、非核心链路的内容打标。这些场景上，为了”生产级”三个字去搭一套复杂的推理服务，投入产出比是负的。
用简单方案解决简单问题，不是妥协，是场景匹配。 我更反感的是另一种情况：明明只有五个人用，非要上一套多副本高可用架构，花三周搭完，然后半年内没跑满过一次。那不叫专业，那叫不看需求。
判断的关键从来不是”这个工具够不够高级”，而是”我的场景到底要什么”。把要求列清楚，工具自己就会浮出来。
上线前自查清单
真要把 Ollama 放到生产环境，走一遍这几条再上线：
- 实测并发：用真实的提示词长度和输出长度，从低到高压出拐点，确认安全并发数明显高于业务峰值；具体配置项以
ollama serve --help和官方文档为准。 - 量冷启动：观测实例在空闲一段时间后是否仍在（
ollama ps可看运行中的实例），并掐表量重新加载后的首字延迟，确认最坏情况能接受。 - 锁死网络边界：确认服务不监听公网地址，对外访问一律经网关或反向代理，鉴权与限流在网关层落地。
- 补齐可观测性：明确健康检查怎么做、耗时和失败率从哪儿读；官方端点清单以文档为准，缺的部分用探针脚本和日志统计自己补上。
- 配好自动拉起：进程挂掉能自动重启，并且重启后有告警通知到人，不要靠用户来报障。
- 固定版本：记录当前版本、锁定镜像 tag 或安装方式，保证半年后能重现同一套环境；升级选低峰期并提前量出中断时长。
- 写下失效预案：服务不可用时业务侧降级成什么样（提示”服务维护中”还是走规则兜底），这个页面提前做好，别等出事再写。
- 定期回看假设：每季度对一次真实并发和用户数，一旦超出当初实测的安全线，就该重新评估是加机器还是换框架。
以上命令与端点均以官方 README 和官方文档当次为准，版本更新会变；本文没写的配置项名称，是因为没有可靠来源，请自行以 --help 和官方文档核对，别照抄任何来路不明的变量名。