作者： 在VPS上用Ollama运行Nemotron 3.5 Lightning
了解适合VPS的Ollama标签、准确拉取命令和内存需求，并判断CPU运行是否足够快。默认4-bit构建为{{q:tag_sizes:size_gb}} GB，支持1M上下文。
Nemotron 3.5 Lightning 的用途
Nemotron 3.5 Lightning 是 NVIDIA 发布的开源 30B 混合专家模型，于 2026 年 8 月发布。它面向需要连续运行数小时的代理，而不是只服务于一个聊天窗口。MoE（混合专家）表示，模型权重被拆分为多个专家子网络，每个 token 只经过其中少数几个。NVIDIA 的模型卡显示，该模型共有 30 billion 个参数，每个 token 激活 3 billion 个参数。内存占用取决于较大的总参数量，运行速度则受较小的激活参数量影响。
这项权衡正是租用服务器时值得考虑该模型的原因。代理执行实际任务时，一天内会发送数千个短请求，因此单位成本的吞吐量决定了它能否运行在自己的服务器上。每次回复需要 40 seconds 的模型适合作为助手，但不适合作为代理，因为一个任务可能发起 20 次调用，而每次调用都需要等待。
NVIDIA 将该架构描述为混合架构：交错使用 Mamba-2 层和 MoE 层，并加入部分 attention 层。模型卡显示，最大上下文长度最高可达 1M tokens，使用 OpenMDW-1.1 license，并标注为可用于商业用途。主要支持 English 和代码，同时也列出了 Spanish、French、German、Italian 和 Japanese。
Artificial Analysis 在 2026 年 8 月发布的测试数据显示，在提供 NVFP4 权重的预发布 DeepInfra endpoint 上，输出速度接近每秒 670 tokens。这是托管 GPU endpoint 的测试结果。应将其理解为该架构可能达到的性能，而不是 VPS 一定能够达到的性能。
哪个 Ollama 标签适合哪种 VPS
Ollama 库会为同一组权重发布多个构建版本。它们之间的差异在于量化方式，即每个权重使用多少位存储。这会显著改变下载大小。
The data behind this chart
[
{
"label": "30b-a3b-q4_K_M",
"size_gb": 25
},
{
"label": "30b-a3b-q8_0",
"size_gb": 35
},
{
"label": "30b-a3b-bf16",
"size_gb": 66
},
{
"label": "30b-a3b-mlx",
"size_gb": 23
}
]名为 latest、30b 和 30b-a3b 的标签都解析到与 30b-a3b-q4_K_M 相同的摘要，因此默认下载的是 25 GB 的 4-bit 构建，并启用完整的 1M 上下文。Q8_0 的大小为 35 GB，bf16 的大小为 66 GB，二者同样支持 1M 上下文。大小为 23 GB 的 MLX 构建适用于 Apple silicon，且上下文上限为 256K，因此不适合 Linux VPS。
这些是下载大小，不是内存需求。NVIDIA 没有公布 Ollama 构建所需的最低 VRAM（显存），因此只能将下载大小视为下限，不能据此得出更多结论。权重必须常驻于某处：显卡能够容纳时使用 GPU 内存，否则使用系统 RAM；此外还要加上 KV cache（键值缓存，即模型为对话中每个 token 保存的内存）。你的硬件实际需要多少内存，应通过命令获取，而不是进行算术估算；相关命令如下。如果你还没有确定量化级别，请参阅 Q4、Q8 和 FP16 各自需要放弃什么，了解每一步的取舍。
拉取精确标签，不要使用 latest
latest 是一个会变化的指针。库重新发布该标签后，代理的行为会在下次拉取时发生变化，而您的笔记中没有任何信息可以解释原因。请明确指定标签。
curl -fsSL https://ollama.com/install.sh | sh
ollama --version
ollama pull nemotron-3.5-lightning:30b-a3b-q4_K_M安装脚本会设置一个以 ollama 用户身份运行的 systemd 服务，并将模型存储在 /usr/share/ollama/.ollama/models 下。大多数 VPS 镜像会将此路径放在根文件系统中，因此在请求 25 GB 空间前，请先检查剩余空间。如果该文件系统空间不足，请在拉取前阅读Ollama 存储模型的位置以及如何迁移模型，不要等磁盘已被占满后再处理。
df -h /usr/share/ollama拉取中途停止并报告 no space left on device，就表示拉取确实在中途停止了。部分 blob 会一直留在磁盘上，直到您将其删除。然后确认已拉取的内容：
ollama show nemotron-3.5-lightning:30b-a3b-q4_K_Mollama show 会输出架构、参数数量、上下文长度以及文件实际携带的量化方式。如果其中任何一项与库页面不一致，说明您拉取的标签不是预期的标签。
启动服务，并检查它实际运行的位置
sudo systemctl enable --now ollama
ollama run nemotron-3.5-lightning:30b-a3b-q4_K_M "Reply with one word: ready"模型仍处于加载状态时，在第二个 shell 中执行：
ollama ps这条命令可直接回答本机的内存问题。ollama ps 会显示已加载的模型、其占用的内存大小，以及 PROCESSOR 列。100% GPU 表示模型全部位于 VRAM 中。100% CPU 表示模型完全不在 VRAM 中，所有 token 都由处理器使用系统 RAM 计算。类似 65%/35% CPU/GPU 的拆分表示所有层无法全部装入 VRAM，CPU 所占比例会决定处理速度。不要估算所需内存。直接加载模型并读取这一行。
如果模型完全无法加载，Ollama 会正常拒绝，而不是崩溃：
Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB)仅使用 CPU 的 VPS 够快吗？
通用型 VPS 没有 GPU，因此所有工作都由 CPU 完成，并从系统 RAM 中读取所需的每个权重。MoE 在这里有所帮助，因为每个 token 只会使用 30 billion 个参数中的约 3 billion 个，所以每个 token 所需的计算量远小于稠密 30B 模型。它完全无法减少内存需求。全部 30 billion 个参数都必须常驻内存，因为路由器可以为任何 token 选择任意专家。
因此，该模型仅使用 CPU 推理时，瓶颈在内存带宽，而不是核心数量。对于已经配备合理 vCPU 数量的方案，增加 vCPU 几乎不会带来变化。您需要足够的 RAM 来容纳权重和 KV cache，并应选择方案提供的最快内存。
在让 agent 使用该模型前，先按照 测量本地 LLM 的每秒 token 数中的方法进行测量：
ollama run --verbose nemotron-3.5-lightning:30b-a3b-q4_K_M "Write a 200 word summary of TCP slow start."末尾打印的 eval rate 行就是生成速度，单位为每秒 token 数。这个数值可以直接决定是否适用，因为 agent 的实际耗时主要由它决定。将它乘以您预期的回复长度。如果结果超过您愿意等待的时间，可以使用 使用 num_predict 限制输出。这是在不更换硬件的情况下限制单次调用耗时的唯一调节手段。
The data behind this chart
[
{
"label": "Nemotron 3.5 Lightning",
"sec_per_task": 30
},
{
"label": "gpt-oss-120b",
"sec_per_task": 204
},
{
"label": "Qwen3.6 35B",
"sec_per_task": 210
}
]这些是已发布的第三方数据。它们根据 Artificial Analysis 在发布时报告的每项任务耗时（分钟）换算而来，测量环境是托管 GPU 端点，而不是 VPS。Nemotron 3.5 Lightning 平均每项任务约需 30 秒，其中 gpt-oss-120b 约需 204 秒，Qwen3.6 35B 约需 210 秒。请将这些数据用于了解差距的大致情况，不要据此承诺您的硬件也能达到相同结果。
合理建议取决于谁在等待。如果有人在等待 agent，或者 agent 会连续执行很长的调用链，请租用 GPU 资源。如果它按计划在夜间运行，且没有人实时等待，大内存 CPU 方案是合理的选择。无论采用哪种方案，配置方式都相同；在 VPS 上运行 Ollama介绍了方案规格选择，以及 GPU 实例与按 token 向 API 提供商付费之间的比较。盈亏平衡取决于利用率：GPU 实例只要存在就会按小时计费，而 API token 仅在使用时计费。因此，全天大部分时间都处于忙碌状态的 agent 更适合使用自有实例；每小时仅运行两次的 agent 通常不适合。
1M 上下文窗口并不是免费的
1M tokens 是模型支持的上限，但 Ollama 默认不会提供这么大的窗口。Ollama 提供的默认窗口小得多；对话超过该窗口后，它会丢弃最早的 tokens。发生这种情况时不会记录任何日志，因此对 agent 来说，就像模型忘记了任务开头的内容。
请有意设置上下文窗口。若要对整个服务器设置，请编辑服务：
sudo systemctl edit ollama添加以下内容，然后运行 sudo systemctl restart ollama：
[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"如果只针对单个请求设置，请改为在 options 对象中发送 num_ctx：
curl http://localhost:11434/api/chat -d '{
"model": "nemotron-3.5-lightning:30b-a3b-q4_K_M",
"messages": [{"role": "user", "content": "Say ready"}],
"options": {"num_ctx": 32768},
"stream": false
}'每次增大窗口都会增加内存占用，因为 KV cache 会随允许的 tokens 数量增长。增大该值并重启，然后再次运行 ollama ps，观察报告的大小是否增加。如果更改后 PROCESSOR 列从 100% GPU 变为 split，说明 KV cache 将模型层从 VRAM 中挤出，速度会大幅下降。在 Ollama 中选择 num_ctx详细说明了这种权衡。不要因为模型卡允许 1000000 就直接设置为 1000000，因为内存会在加载时一次性分配，加载会直接失败。
将其接入常驻代理
Ollama 发布该模型时提供了一个快捷方式，可启动已经指向该模型的受支持代理：
ollama launch claude --model nemotron-3.5-lightning该文章在此处记录了 claude、opencode、openclaw 和 hermes。此子命令需要最新版 Ollama，因此先检查 ollama --version；如果未安装，请自行将代理指向 API。Ollama 提供与 OpenAI 兼容的端点，大多数代理框架都支持：
export OPENAI_BASE_URL=http://localhost:11434/v1
export OPENAI_API_KEY=ollamaOllama 会忽略此密钥，但大多数客户端在未设置密钥时不会启动。代理框架侧的配置请参阅将编码代理指向 Ollama以及构建自己的 OpenClaw 代理。
代理无人值守运行后，有两项服务器设置很重要。OLLAMA_KEEP_ALIVE 控制模型在最后一次请求后继续驻留内存的时间；默认值会在五分钟后卸载模型，因此下一次调用又要完整承担加载时间。对于大小为 25 GB 的文件，在没有 GPU 的情况下，加载暂停时间可能长到导致超时。设置 OLLAMA_KEEP_ALIVE=-1 可让模型保持驻留。OLLAMA_HOST=0.0.0.0:11434 使 API 可从其他计算机访问，但它完全不提供身份验证，因此只能通过防火墙规则或私有网络开放。
故障模式及对应提示
拉取立即失败。 Error: pull model manifest: file does not exist 表示该标签不存在。标签名称必须完全匹配。请从库页面复制标签，不要猜测量化后缀。
模型无法加载。 Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB) 表示按当前配置，该标签超出此方案的容量。请改用更小的量化版本，或降低 OLLAMA_CONTEXT_LENGTH，因为 KV cache 也计入该要求。
11434 端口没有响应。 curl: (7) Failed to connect to localhost port 11434 表示服务未运行，或未监听在预期位置。请查看 systemctl status ollama 和 journalctl -u ollama -n 50。如果您还手动启动了 ollama serve，第二个副本会以 Error: listen tcp 127.0.0.1:11434: bind: address already in use 退出。
服务可以响应，但速度非常慢。 在修改任何设置前，先检查 ollama ps。在 GPU 机器上，如果 PROCESSOR 列中出现任何 CPU 占用，表示部分模型已溢出 VRAM。请降低上下文长度，或改用更小的量化版本。在没有 GPU 的机器上，速度慢属于预期结果，无法通过设置修复。
代理在任务执行过程中途忘记指令。 对话内容超出了上下文窗口，最早的令牌已被静默丢弃。请提高 OLLAMA_CONTEXT_LENGTH，并使用 ollama ps 确认模型仍能装入内存。如果无法装入，解决方法是使用更大规格的机器，而不是缩小上下文窗口。
此模型与其他方案的定位
对于小型任务而言，部署 30B MoE 模型的成本较高。如果一个 dense 8B 模型已经能够处理您的任务，那么运行成本会低得多，加载也只需几秒；有关这一决策的直接对比，请参阅 在 VPS 上运行 8B 和 27B 的 Qwen 3。如果您想全面了解某个方案实际能够承载哪些模型，请从 可以自行托管哪些 AI 模型 开始。如果您计划同时提供多个 agent 的服务，而不是只服务一个 agent，请先阅读 Ollama 与 vLLM 的对比，因为 Ollama 不会像生产级推理服务器那样对并发请求进行批处理，这也是单用户部署无法继续扩展的原因。
FAQ
应该在 Linux VPS 上拉取哪个 Nemotron 3.5 Lightning 标签？
使用 nemotron-3.5-lightning:30b-a3b-q4_K_M。该版本大小为 25 GB，支持完整的 1M 最大上下文长度。截至 2026 年 8 月，latest、30b 和 30b-a3b 标签都指向同一个摘要。请显式指定该标签，不要拉取 latest，这样将来该指针重新发布时，不会在您未察觉的情况下改变代理的行为。mlx 标签是 Apple silicon 构建版本，在 Linux 上无法使用。
Nemotron 3.5 Lightning 需要多少 RAM？
NVIDIA 没有公布 Ollama 构建版本的最低内存要求，因此应实际测量，而不是估算。拉取该标签，运行一次模型，并在模型加载期间读取 ollama ps：它会显示实际占用的大小，以及模型是在 GPU 还是 CPU 上运行。如果默认标签的下载大小为 25 GB，这只是最低值，因为 KV cache 会额外占用内存，并且会随您设置的上下文窗口增长。如果 VPS 方案太小，Ollama 会显示 model requires more system memory，并同时列出这两个数值。
没有 GPU 的 VPS 可以运行 Nemotron 3.5 Lightning 吗？
可以，前提是该方案有足够的 RAM 容纳模型权重。MoE 架构也有帮助，因为每个 token 只计算约 30 billion 个参数中的 3 billion。限制因素是速度。没有 GPU 时，模型受内存带宽限制，因此增加 vCPU 几乎不会改善结果。使用固定提示运行 ollama run --verbose，读取 eval rate 行，并根据代理的截止时间评估该数值。对于夜间运行的批处理任务，这通常没有问题。对于需要用户等待结果的任务，通常不适用。
为什么 Ollama 没有提供完整的 1M 上下文窗口？
1M 是模型的最大值，不是 Ollama 的默认值。Ollama 使用小得多的窗口；当对话超出该窗口后，它会丢弃最早的 token，且不会打印错误，因此表现为代理忘记了自己的指令。将 OLLAMA_CONTEXT_LENGTH 设置在 systemd 服务中，或针对每个请求传递 num_ctx。逐步增大该值，并在每次调整后重新检查 ollama ps，因为 KV cache 的内存占用会随窗口大小增加，可能导致部分模型层从 GPU 转移到 CPU。
Nemotron 3.5 Lightning 可以免费用于商业用途吗？
NVIDIA 的模型卡将该模型置于 OpenMDW-1.1 许可证下，并标记为可用于商业用途。这涵盖您自行下载和运行的模型权重。但它不涵盖技术栈中的其他软件，因此请分别检查代理框架及其连接的工具所使用的许可证。如果要将其用于合同或其他法律承诺，请先阅读当前版本的模型卡。