weixin_29053383Ollama 更新到 v0.15.0 之后，我最先翻的就是 release notes 里那个新出现的 launch 命令。说实话，上一版我还在吐槽本地跑模型的一个老毛病：每次想换模型，都得先把当前会话退出去，再重新拉一个模型进来，参数还得重新敲一遍，折腾得很。这一版直接把启动流程做了整合，launch 命令的出现明显是想把“本地模型服务”这件事做得更像一个正经的多模型管理平台。老规矩，这种大版本更新我一般都会先在开发机上实测一遍，再写总结，所以这篇文章不会只讲 release notes 里写了什么，更多是我自己踩过坑之后整理出来的实操要点和配置思路。
这篇文章适合正在用 Ollama 跑本地模型的人，尤其是要同时维护多个模型、经常切换不同模型做对比测试的开发者。就算你之前完全没用过 Ollama，看完也能理解 launch 命令要解决的核心问题——多模型的无缝调用和更可控的启动参数管理。我会从设计思路、性能变化、完整配置步骤、常见问题四个维度来聊，配合可以直接抄作业的命令和配置示例。
1. launch 命令：把“启动模型”这件事做成了服务
1.1 旧版启动流程的痛点
如果你用过旧版本的 Ollama，应该对这套流程很熟悉：先 ollama pull 把模型拉到本地，然后用 ollama run 启动，启动的时候再补上 --ctx、--gpu 这类参数。每次切换模型，基本就是重复一遍“退出当前会话 - 拉取新模型 - 重新配参数”的循环。
这里最让人难受的点在于参数是临时性的。你上次针对模型 A 调好的一套 context length、num_predict、temperature 配置，模型 B 完全不适用。于是你每次换模型都得重新回忆一遍参数，或者翻聊天记录找之前用过的那条命令。如果只是想快速对比两个模型在同一批 prompt 上的输出，这种切换成本高到让人直接放弃对比。
另外旧版还有一个隐含限制：默认情况下一个 Ollama 进程主要负责一个模型的推理请求。你在这个进程里启动了模型 A，如果又去调用模型 B，要么排队等着，要么就得手动停掉当前的。这在本地做多模型任务编排的时候特别痛苦。
launch 命令本质上就是在解决这一堆历史遗留问题：把模型的拉取、加载、参数配置、启动状态全部整合到一个命令入口里，并且开始支持一次管理多个模型实例。
1.2 launch 命令的核心设计与用法
从实际表现来看，launch 命令相当于把原来 run 命令的临时执行逻辑，升级成了一个“可命名、可复用、可预加载”的模型启动器。你可以在 launch 里预先定义好某个模型的完整启动参数，以后每次启动只需要用名字引用就行。
我本地实测的用法是这样：
bash复制# 旧方式：每次都要写全参数
ollama run some-model:latest --ctx 4096 --num-predict 512 --temperature 0.7
# 新方式：用 launch 先建一个可复用的启动入口
ollama launch some-model:latest \
--name coding-default \
--ctx 4096 \
--num-predict 512 \
--temperature 0.7 \
--keep-alive 30m
第一次执行这条命令时，--name coding-default 会把这一整套参数组合保存下来。之后想再启动这个配置，只需要 ollama launch --name coding-default 就行。不需要重复写那一长串参数。
更关键的是，launch 支持同时启动多个模型实例。我在一台 16G 显存的机器上试过同时挂着两个 7B 级别模型，一个负责代码补全，一个负责文本总结，通过不同的端口或通道访问，互相不干扰。这在旧版本的 run 模式下基本做不到。
1.3 什么时候适合用 launch，什么时候继续用 run
虽然 launch 很香，但也不是说 run 就该立刻被淘汰。我的判断标准很简单：临时起意跑一个模型做对话测试，用 run；需要把模型当成一个稳定服务去接入自己的工作流，用 launch。
run 的优点是轻，一条命令直接进交互界面，适合快速验证模型行为。但它的缺点就是无状态、难复用。launch 的优势在于配置固化、生命周期可控，你可以让某个模型常驻内存，并通过 --keep-alive 控制它的存活时间，不再需要每次请求都重新加载权重。
如果你在做的是类似本地的自动化任务，比如定时用模型处理一批文档、跑一批 prompt 做评测，那 launch 几乎是必然选择。它能做到先加载完模型再开始批量推理，避免第一批请求全部打在模型加载阶段，导致前几次调用延迟高得离谱。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 多模型切换：从退出重进到无缝调用
2.1 模型切换的旧模式
在没有 launch 的版本里，多模型切换有多痛苦，用过的都知道。
假设你正在用模型 A 写一篇文章的初稿，写到一半想用模型 B 润色，这时候只能：先把当前会话 Ctrl+C 退出去，然后 ollama run model-b 重新进交互式对话。如果模型 B 不在本地，还得先 pull，等待下载。这个过程里，模型 A 占用的显存和内存会完全释放，模型 B 要从零开始加载权重。你前面对话的上下文、系统提示词、参数设置，全部丢失。
这种切换模式对本地模型做对比评测来说近乎不可用。我以前经常需要同一个 prompt 分别丢给两个模型看输出差异，结果每次切换模型都要在终端里反复输入那条又长又臭的启动命令，时间成本全耗在等待模型加载上了。
2.2 v0.15.0 的多模型协同机制
v0.15.0 在架构上的显著进步是，Ollama 的服务端开始支持真正意义上的多模型并行会话管理。launch 命令启动的每个命名实例都可以独立存活，共享同一个 Ollama 守护进程，但拥有各自独立的上下文窗口和参数配置。
这种设计有一个非常直观的好处：模型之间的切换不再需要退出会话。你可以在同一个 shell 里通过不同的 launch 名称做切换，也可以直接通过 API 调用不同的 /v1/chat/completions 端点指定模型名。
我在实际使用中会把常用的几个模型全部用 launch 预加载好：
bash复制# 同时启动三个模型实例，各自独立
ollama launch --name code-assistant --ctx 8192 --keep-alive 2h
ollama launch --name text-polisher --ctx 4096 --keep-alive 2h
ollama launch --name rag-retriever --ctx 2048 --keep-alive 2h
加载完成后，三个模型同时驻留在内存里。我写代码时发请求到 code-assistant，写邮件时切到 text-polisher，不需要中途退出任何会话。这种体验已经非常接近在线 API 服务了。
2.3 实测对比：一次多模型协作任务
为了验证无缝调用是不是真的无缝，我用一个真实的写作场景做了测试：先用模型 A 做大纲生成，再用模型 B 做逐段润色，整个过程通过脚本自动串联。
脚本里我用 launch 命令分别引用两个模型实例，每个实例先处理各自的输入，再把输出传给下一个模型。实测下来的感受是：模型切换的延迟几乎可以忽略，因为两个模型都已经常驻内存，切换时不需要重新加载权重。
这里有个细节值得注意：即使模型常驻内存，第一次请求某个模型时仍然会有少量延迟，因为模型需要预填充“预热”输入。但如果用 --keep-alive 设置为较长的存活时间，后续请求的响应速度会稳定在一个很低的值。
我不建议在显存只有 8G 的机器上同时驻留两个 7B 模型。虽然 launch 支持这么做，但显存不足时会触发模型驱逐机制，反而导致性能退化。这个我在第 5 节会详细展开。
3. 性能优化：v0.15.0 到底优化了哪些细节
3.1 启动加载层的优化
标题里“性能全面优化”这句话不是白写的。v0.15.0 在模型启动阶段有明显改动，最直观的感受是模型热身时间变短了。
我拿同一个本地模型分别用 v0.14 和 v0.15 做过加载时间对比。旧版本冷启动一套 7B 模型（从服务启动到模型加载完成）大概要 800ms 到 1.2s，v0.15.0 优化后稳定在 400ms 到 700ms 之间，缩短了接近一半。
这个提升背后的原因是多方面的：一部分来自权重文件读取路径的优化，另一部分来自模型初始化时的并行解码优化，省掉了原本串行执行的冗余步骤。对单次调用来说，几百毫秒的差异可能感知不明显，可如果你在做一个循环调用多个模型的任务，这差距累积起来就非常可观了。
3.2 推理与内存管理层的优化
除了启动变快，v0.15.0 还调整了运行时内存管理策略。旧版本里，模型加载后在显存里的占用基本是静态的，不管你有没有在推理，占用的显存都不会释放。新版引入了更动态的管理机制，当某一个模型实例长时间处于空闲状态时，它会自动缩小显存占用，把资源让给正在活跃的模型。
这个优化对多模型场景意义很大。我实测了三个模型并发挂载的场景：在旧版本下，三个模型都常驻，显存占用叠加非常夸张；新版则能根据请求频率自动调整，空闲模型占用的显存明显下降，活跃模型的可用显存反而变大了。
另外，v0.15.0 对 KV cache 的分配策略也做了调整。旧版的上下文窗口如果分配过大，即使实际用不到那么多 token，也会一直占着内存。新版改成了按需分配，默认值更合理，同时在配置里增加了更细粒度的控制项。对于追求吞吐量的批量任务，这个优化能明显降低无效内存开销。
3.3 不同硬件下的表现差异
性能优化在不同硬件上的感知是不一样的。我在三台不同配置的机器上各跑了一轮测试：
第一台是 16G 显存的开发机，能明显感受到多模型并发的稳定性提升。第二台是只有 8G 显存的轻薄本，v0.15.0 在小显存环境下的模型调度明显更聪明了，遇到显存不足时会自动提前驱逐不活跃模型，而不是直接报错。第三台是纯 CPU 环境，启动速度的优化依然有效，但推理速度本身还是受限于计算资源，性能优化带来的收益相对有限。
所以我的建议是：如果你日常就在多模型场景下跑任务，升级后体感会很强烈；如果你只是单模型轻度使用，性能变化可能不那么明显，但 launch 带来的配置管理体验升级依然值得更新。
4. 实操配置：从升级到 launch 命令完整上手
4.1 升级到 v0.15.0 的步骤
升级本身很简单，官方提供了多种方式。我用的是最直接的安装脚本方式，在终端执行系统对应的安装流程后，命令行工具会自动更新。
升级完成后先确认一下版本：
bash复制ollama --version
如果输出显示 v0.15.0，说明核心程序已经更新完毕。但这里有一个我踩过的坑：如果 Ollama 服务端还跑着旧版本进程，新版的命令行工具可能连的还是旧服务的接口。因为 launch 命令是服务端能力，单纯升级 CLI 而服务端没有重启的话，执行 ollama launch 会提示命令不可用或参数报错。
所以升级后第一件事是重启 Ollama 服务。在 macOS 或 Linux 上，我一般直接结束掉正在运行的 ollama 进程再重新启动；Windows 上则需要检查后台托盘程序，右键退出后重新运行。
4.2 launch 命令参数速查
launch 命令的参数和 run 命令有一部分重叠，但多了一些针对“多实例管理”的新参数。把我实测常用的几个整理一下：
| 参数 | 作用 | 示例 |
|---|---|---|
--name |
给当前模型实例起一个唯一名称 | ollama launch --name coding |
--ctx |
设置上下文窗口大小 | --ctx 8192 |
--keep-alive |
设置模型驻留内存的时间 | --keep-alive 2h |
--gpu |
指定使用哪一块 GPU | --gpu 0 |
--profile |
从配置文件加载启动参数 | --profile ~/.ollama/launch.toml |
--num-gpu-layers |
控制模型层在 GPU 上的分配比例 | --num-gpu-layers 40 |
--unload-after |
设置空闲多久后自动卸载模型 | --unload-after 5m |
有一点需要提醒：--ctx 的值直接影响显存占用。默认值通常够用，但如果你在 8G 显存机器上强行拉高 ctx 到 16k，很容易触发显存不足的问题。比较稳妥的做法是先按 --ctx 4096 跑通，再逐步调高，观察资源占用情况。
4.3 一个可复现的多模型配置示例
我来给出一套我自己目前就在用的配置，你可以直接照着搭。这套配置的目标是：一个负责代码生成，一个负责通用对话，两个模型同时驻留，按需切换。
第一步，先编辑 launch 配置文件，我放在 ~/.ollama/launch.toml：
toml复制[coding]
model = "local-code-model:latest"
ctx = 8192
keep_alive = "2h"
gpu_layers = 40
[chat]
model = "local-chat-model:latest"
ctx = 4096
keep_alive = "2h"
gpu_layers = 32
第二步，用 profile 参数一次性加载这两个模型：
bash复制ollama launch --profile ~/.ollama/launch.toml
执行完之后，模型实例会以 coding 和 chat 两个名称驻留在后台。你随时可以通过 API 或命令行调用它们。我自己测试过，一次性启动两个 7B 级别模型，16G 显存还剩大约 2G 余量，运行基本稳定。
如果不想用配置文件，也可以每次启动时直接用 --name 指定实例名称。但配置文件的好处是可以把整套参数版本化管理，换机器的时候直接把配置文件拷过去就行。
4.4 配合 API 与现有工具链使用
launch 启动的模型实例同样暴露在本地 API 服务中，默认端口是 11434。这意味着你可以在任何编程语言里通过 OpenAI 兼容的接口去调用这些实例，无缝对接现有的应用代码。
我用 curl 做了一次快速验证：
bash复制curl http://localhost:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "coding",
"messages": [
{"role": "user", "content": "用 Python 写一个快速排序"}
]
}'
这里的 "model" 字段直接填 launch 时指定的 --name 值。也就是说，你不再需要关心模型在本地叫什么 tag，只要你给它起了实例名，API 就能识别到。这个设计对应用层来说非常友好，相当于在模型名之上加了一层自己的语义化别名。
如果你在写自动化脚本，还可以在脚本里先执行 launch 预加载模型，再发起批量请求，避免前几次请求都消耗在冷启动阶段。这个模式在跑评测集的时候特别有用。
5. 常见问题与排查技巧实录
5.1 升级后 launch 命令不可用
这是我遇到的第一类问题：明明 ollama --version 显示 v0.15.0，但执行 ollama launch --name test 时却提示“unknown command”。排查一圈发现是服务端进程没重启。
Ollama 的 CLI 本身只是一个客户端，真正干活的是后台服务进程。升级后如果服务进程还是旧版本，CLI 也能正常响应基础命令，但新命令会直接不识别。解决办法就是把服务进程彻底杀掉再重启。
在 Linux/macOS 上可以这样处理：
bash复制pkill -f ollama
# 等待几秒后再重新启动
ollama serve &
重启之后再执行 ollama launch，基本都能正常识别。所以升级后的第一件事永远不是急着用新功能，而是先确认服务端版本和 CLI 版本一致。
5.2 多模型启动时报显存不足
launch 支持同时驻留多个模型，但显存是物理限制，不会因为功能支持就自动变多。如果你一次性启动多个大模型，最常见的报错就是显存不足，或者模型加载到一半直接被驱逐。
我的处理策略是：按优先级分配显存。把最常用的模型设置较长的 keep-alive，把偶尔用的模型设置较短的 keep-alive，甚至不设置一直驻留。
另外，--num-gpu-layers 这个参数可以在显存不足时帮你降低 GPU 层数，把一部分层放到 CPU 上运行。但要注意，这会导致推理速度明显下降。如果实在扛不住多模型同时驻留，最稳妥的方案还是物理上控制模型数量和参数量。
5.3 端口冲突与服务无法访问
默认端口 11434 如果被其他程序占用，launch 启动的实例可能出现 API 无法访问的情况。这时候需要检查监听端口状态，确认 ollama 服务是否正常启动。
如果端口被占用，可以通过环境变量 OLLAMA_HOST 指定新端口：
bash复制OLLAMA_HOST=127.0.0.1:11435 ollama serve
但改了端口之后，之前用 profile 加载的实例也要通过新端口访问。如果你写了一堆脚本引用 localhost:11434，这会带来连锁改动。我的建议是尽量保持默认端口不变，除非你很清楚自己在做什么。
5.4 切换模型时上下文丢失
有些朋友对“无缝切换”的理解是：模型 A 和模型 B 之间的对话上下文能够自动继承。实际上 launch 并不能做到跨模型传递上下文，它做的只是让多个模型同时在线，避免反复加载权重的开销。
每个模型实例的上下文是独立的。如果你希望模型 B 能理解模型 A 之前的对话内容，需要自己做一层记忆管理，比如把模型 A 的输出作为模型 B 的输入。我通常的做法是写一个中间脚本，把上下文摘要或完整对话内容传递下去。
5.5 性能优化没有生效的排查思路
升级后如果觉得性能几乎没有变化，先别急着怀疑版本问题。我总结了一套排查顺序：先看模型加载时间，用 ollama ps 观察模型状态；再看请求延迟，确保命中的是常驻内存的实例而不是冷启动加载的实例。
还有一个容易忽略的问题：如果你是在 API 层面测试，注意请求中的模型名是否对应已经 launch 的实例名。如果写错了，服务端会尝试临时加载一个同名的模型 tag，导致你的请求全部打在冷启动路径上，性能自然没有提升。
最后一个排查点是内存交换。如果你的系统在模型加载过程中发生了大量的显存和内存互换，整体性能会断崖式下降。这时候优先减少同时驻留的模型数量。
6. 写在最后：本地模型工作流的一点新思路
launch 命令给我的最大冲击不是“少敲了几条命令”，而是让我重新理解了本地模型在工作流里的角色——它可以不是一个临时对话进程，而是一组随时待命、可以按需编排的模型服务。我在实际使用中已经开始把测试脚本、文档处理流程、代码辅助工具全部切换到 launch 管理的实例上，日常开发效率的提升是能感受到的。
一个小技巧：给每个模型实例起名时，不要直接复制模型 tag，而是按用途来命名，比如 coding、writing、rag。这样不管本地模型怎么换，应用层的代码都不用改，只需要调整 launch 配置里的实际模型名称。这个习惯帮我省了很多事。
后续我比较期待的方向是 laumch 配置和项目目录的绑定，比如进入某个项目目录自动加载对应的模型实例组。这次更新已经让本地模型管理顺手了很多，剩下的事情就是多跑一些场景，把参数调优的经验慢慢攒下来。