作者： Matt Connor
如何在 VPS 上运行 Nemotron 3.5 Lightning 模型
想在服务器部署 NVIDIA Nemotron 3.5 Lightning？本文详解 Ollama 部署方案，提供准确的量化版本选择建议、内存占用预估，并分析 CPU 运行该 MoE 架构的真实性能表现，助你避开资源配置陷阱。
Nemotron 3.5 Lightning 的用途
Nemotron 3.5 Lightning 是 NVIDIA 于 2026 年 8 月发布的开源 30B 混合专家模型（MoE），专为长时间运行的智能体（agent）设计，而非仅用于单次对话窗口。MoE（混合专家）意味着权重被拆分为多个专家子网络，每个 token 仅通过其中少数几个进行处理。根据 NVIDIA 的模型卡，该模型总参数量为 300 亿，每个 token 激活的参数量为 30 亿。用户需为内存中加载的大量参数付费，但能获得小参数量带来的高速度。
这种权衡是租用服务器时考虑该模型的原因。执行实际任务的智能体一天内会发送数千个短请求，因此单位成本下的吞吐量决定了它是否适合在你的服务器上运行。如果一个模型每次回复需要 40 秒，它作为助手尚可，但作为智能体则表现不佳，因为单个任务可能触发 20 次调用，且你必须等待每一次调用的完成。
NVIDIA 将该架构描述为混合型：交替使用 Mamba-2 和 MoE 层，并辅以特定的注意力层。模型卡显示其最大上下文长度可达 1M token，采用 OpenMDW-1.1 许可，明确可用于商业用途。主要支持语言为英语和编程语言，同时也列出了西班牙语、法语、德语、意大利语和日语。
Artificial Analysis 在 2026 年 8 月发布的测试数据显示，在提供 NVFP4 权重的预发布版 DeepInfra 端点上，其输出速度接近每秒 670 个 token。这是一个托管的 GPU 端点。请将其视为该架构所能达到的性能上限，而非你个人 VPS 的实际运行表现。
哪种 Ollama 标签适合您的 VPS
Ollama 库会针对同一模型权重发布多个构建版本。它们之间的区别在于量化（quantisation），即每个权重所占用的位数，这会显著影响下载大小。
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 的四位（four-bit）构建版本，并支持完整的 1M 上下文。Q8_0 版本为 35 GB，bf16 版本为 66 GB，两者同样支持 1M 上下文。23 GB 的 MLX 构建版本专为 Apple Silicon 设计，且上下文上限为 256K，因此不适合 Linux VPS。
上述数值仅为下载大小，而非内存需求。NVIDIA 并未公布 Ollama 构建版本的最低显存（VRAM）要求，因此请将下载大小仅视为最低基准。模型权重必须驻留在某处：若显卡容量足够则存放在 GPU 显存中，否则存放在系统内存中；此外还需额外预留 KV 缓存（key/value 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安装脚本会创建一个 systemd 服务，该服务以 ollama 用户身份运行，并将模型存储在 /usr/share/ollama/.ollama/models 下。在大多数 VPS 镜像中，该路径位于根文件系统上，因此在申请 25 GB 空间前，请先检查磁盘剩余空间。
df -h /usr/share/ollama如果拉取过程在中途停止并报错 no space left on device，则表示磁盘空间不足。在删除这些部分文件之前，它们会一直占用磁盘空间。随后请确认已下载的内容：
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"在模型加载期间，打开第二个终端窗口：
ollama ps此命令可解答机器的内存占用问题。ollama ps 会输出已加载的模型、其占用的内存大小以及 PROCESSOR 列。100% GPU 表示模型完全驻留在显存（VRAM）中。100% CPU 表示模型未驻留显存，每个 token 均由处理器通过系统内存计算。若显示为 65%/35% CPU/GPU 等拆分状态，则说明层级未完全装入显存，此时 CPU 的参与度决定了运行速度。请勿估算需求，直接加载模型并查看此行输出即可。
如果模型无法加载，Ollama 会直接拒绝请求，而不会导致程序崩溃：
Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB)仅使用 CPU 的 VPS 速度够快吗？
通用 VPS 没有 GPU，因此所有计算任务均由 CPU 完成，且 CPU 必须从系统内存中读取所需的每一个权重。MoE（混合专家模型）在此场景下有优势，因为每个 token 仅涉及 300 亿参数中的约 30 亿个，所以每个 token 的算术运算量远小于稠密型 30B 模型。但这并不能改善内存压力。所有 300 亿参数必须常驻内存，因为路由层可能为任何 token 选择任何专家。
因此，该模型在仅 CPU 环境下的推理速度受限于内存带宽，而非核心数。对于已经拥有合理核心数的方案，增加 vCPU 几乎没有意义。你需要的是足以容纳权重和 KV 缓存的内存容量，以及该方案所能提供的最快内存。
在投入使用前，请使用 测量本地 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 的实际运行时间主要由它决定。
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 token 是该模型的上限，但 Ollama 默认不会提供此配置。Ollama 默认使用较小的窗口，一旦对话超出该长度，就会丢弃最早的 token。此过程不会产生任何日志，因此对于 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 缓存会随允许的 token 数量增加。调大该值并重启后，再次运行 ollama ps 并观察报告的占用大小。如果更改后 PROCESSOR 列从 100% GPU 变为 split，说明 KV 缓存将模型层挤出了 VRAM，导致运行速度大幅下降。在 Ollama 中选择 num_ctx 详细介绍了这种权衡。不要仅仅因为模型说明文档允许就设置为 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 控制模型在最后一次请求后保留在内存中的时长，默认设置会在 5 分钟后将其卸载，导致下一次调用需重新经历完整的加载耗时。在没有 GPU 的情况下，对于 25 GB 的文件，该停顿时间足以导致超时。请设置 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 缓存也计入该需求中。
端口 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 的机器上，运行缓慢是预期结果，无法通过设置修复。
智能体在任务中途遗忘指令。 对话内容超出了上下文窗口，最旧的 token 已被静默丢弃。请提高 OLLAMA_CONTEXT_LENGTH，并通过 ollama ps 确认模型仍能容纳。如果无法容纳，解决方法是更换配置更高的机器，而非缩小窗口大小。
该模型与替代方案的对比
30B MoE 模型对于小型任务而言部署成本过高。如果 8B 稠密模型已能胜任，其运行成本更低且加载仅需数秒，VPS 上的 Qwen 3 8B 与 27B 版本 是进行此类决策时的直接参考。若需全面了解特定配置方案的承载能力，请从 可自托管的 AI 模型 开始查阅。如果您计划同时运行多个智能体而非单个，请先阅读 Ollama 与 vLLM 的对比，因为 Ollama 不具备生产级推理服务器的并发请求批处理能力，而这正是单用户架构扩展性的瓶颈所在。
FAQ
在 Linux VPS 上应该拉取哪个 Nemotron 3.5 Lightning 标签？
请使用 nemotron-3.5-lightning:30b-a3b-q4_K_M。它的大小为 25 GB，支持完整的 1M 最大上下文，且截至 2026 年 8 月，其摘要（digest）与 latest、30b 和 30b-a3b 标签指向的内容一致。请明确指定该标签名称，而不要拉取 latest，这样可以避免未来该指针重新发布时，在您未察觉的情况下改变代理的行为。mlx 标签是 Apple Silicon 构建版本，无法在 Linux 上使用。
Nemotron 3.5 Lightning 需要多少内存？
NVIDIA 未公布 Ollama 构建版本的最低内存要求，因此请通过测量而非估算来确定。拉取标签并运行一次模型，然后在模型加载时读取 ollama ps：它会显示实际占用的内存大小，以及模型是加载在 GPU 还是 CPU 上。下载大小（默认标签为 25 GB）是最低要求，因为 KV 缓存会在此基础上增加，并随您设置的上下文窗口大小而增长。如果方案内存过小，Ollama 会报错 model requires more system memory 并列出所需的两个数值。
我可以在没有 GPU 的 VPS 上运行 Nemotron 3.5 Lightning 吗？
可以。前提是方案内存足以容纳权重。MoE（混合专家模型）架构在此有优势，因为每个 token 仅计算 300 亿参数中的约 30 亿。速度是主要瓶颈。没有 GPU 时，模型受限于内存带宽，增加 vCPU 对性能提升微乎其微。使用固定提示词运行 ollama run --verbose，读取 eval rate 行，并根据代理的响应时限要求评估该数值。对于夜间批处理任务，这通常没问题；但对于需要实时交互的场景，通常无法满足需求。
为什么 Ollama 没有给我提供完整的 1M 上下文窗口？
1M 是模型的最大值，而非 Ollama 的默认值。Ollama 默认使用较小的窗口，当对话超出限制时会丢弃最旧的 token，且不会报错，这会导致代理表现出“遗忘”指令的现象。请在 systemd 服务中设置 OLLAMA_CONTEXT_LENGTH，或在每次请求时传入 num_ctx。建议逐步调大该值并每次重新检查 ollama ps，因为 KV 缓存内存会随窗口大小线性扩展，可能导致模型层被挤出 GPU。
Nemotron 3.5 Lightning 可以商用吗？
NVIDIA 的模型卡将该模型置于 OpenMDW-1.1 许可协议下，并标注为可商用。这涵盖了您自行下载并运行的权重文件。该协议不涉及技术栈中的其他软件，因此请单独检查代理框架及所连接工具的许可协议，并在将其用于任何合同相关用途前，阅读最新的模型卡。