2026 实测：VPS 上自托管 AI 编程助手——Continue / Cline + 本地模型，代码不出机的配置与避坑

2026-08-16 · DevCraft Studio

讲解在 VPS 上用 Continue 与 Cline 对接 Ollama 本地模型（Qwen-Coder 等）自托管 AI 编程助手，代码不出机，含上下文窗口、24GB 显存与混合路由配置与避坑。

延伸阅读

更多相关攻略推荐：【知识库自托管 02】2026 实测：VPS 自托管 Anythin、【知识库自托管 03】2026 实测：搬瓦工/RackNerd 上自、2026 VPS 选购决策树与白皮书：一张图看懂怎么买、2026 海外 VPS 行业趋势年报：价格、架构与格局全景、如何给 VPS 厂商做"信用评估"：跑路、超售与售后风险排查手册。

为什么要在 VPS 上自托管 AI 编程助手

到了 2026 年，本地化 AI 编程已经从极客玩具变成很多团队的硬需求。Cline 的安装量在年中突破了 800 万，Continue 的插件生态也相当成熟，两大开源方案加起来覆盖了补全、聊天、多文件编辑的完整链路。但真正推动大家把模型搬到 VPS 上的，往往不是省钱，而是三个更现实的原因。

第一是代码隐私。金融、医疗、政企类团队的项目里有一堆不能外传的源码，直接丢给云端大模型有合规风险。把推理跑在自己掌控的机器上，代码从生到死都不出安全边界。第二是摆脱订阅与限流。云端方案按席位、按 token 计费，重构大项目时一不小心就触发限流；自己跑模型，唯一的瓶颈就是显卡。第三是可控。你想换 Qwen-Coder、Devstral 还是其他开源权重，随时换，没有厂商锁定。

本文讲的是一套可落地的组合：用 Ollama 在 VPS 上托管本地代码模型，用 Continue 负责编辑器内的补全和对话，用 Cline 负责跨文件、带工具调用的 Agent 式编辑。读完你能在一台带显卡的 VPS 上搭出一套代码不会被第三方看到的编程助手。

整体架构：三件套各管什么

很多人一开始会把 Continue 和 Cline 搞混，其实它俩分工很清楚。

  • Ollama：本地模型服务器，默认监听 11434 端口，对外提供 OpenAI 兼容接口。它负责真正跑模型推理。
  • Continue：VS Code / JetBrains 插件，强项是 tab 补全（fill-in-the-middle）和侧边栏聊天，延迟敏感，适合日常写代码时的顺手建议。
  • Cline：Agent 式编程助手，会读文件、跑终端命令、做多文件改动，每步可批准。它更适合有计划、有步骤的重构任务。

一个常见搭配是：Continue 用 1.5B 小模型做即时补全，Cline 用 30B 级别的大模型做 Agent 任务。两者都连同一个 Ollama 服务，互不冲突。

第一步：选一台带 GPU 的 VPS

本地跑代码模型，显卡是绕不开的门槛。先说结论：真正能拿来做 Agent 式编程的本地模型，建议至少 24GB 显存。社区里 RTX 3090、RTX 4090（都是 24GB）被公认为本地编程的甜点配置，能在 Q4 量化下跑起 Qwen3-Coder 30B 并撑住四万 token 以上的上下文。

显存和能跑的模型大致是这样：12GB（比如 RTX 3060 12GB）只能勉强上 14B 量化，工具调用和上下文处理会打折；16GB 能上 14B 到 32B 量化（部分卸载）；24GB 是本地 Agent 的推荐起点；32GB 以上才逐渐逼近云端旗舰模型的体验。纯 CPU 或 8GB 显存基本只够 7B 模型，做单文件小改可以，复杂任务会崩。

选厂商时，看预算和地区。要正经 GPU 实例，可以看 Vultr 的专用 GPU 机型，或者 Contabo 的便宜 GPU 套餐；如果预算紧张、只跑 7B 到 14B 量化模型做轻量补全，Racknerd、Cloudcone、Hostdare 这些高性价比 VPS 也能胜任（注意选带足够内存的套餐，并把模型放 SSD 上避免加载卡顿）。无论选哪家，记得确认能装 NVIDIA 驱动、能开 11434 端口或走隧道。

第二步：在 VPS 上装 Ollama 并拉取代码模型

登录 VPS 后，先装 Ollama：

curl -fsSL https://ollama.com/install.sh | sh
ollama --version

装完它会以系统服务形式常驻。接着拉代码模型。建议拉两个：一个小模型做补全，一个大模型做 Agent 编辑。

ollama pull qwen2.5-coder:1.5b
ollama pull qwen2.5-coder:7b
ollama pull qwen3-coder:30b
ollama pull devstral-small-2:24b

2026 年本地代码模型的第一梯队是 Qwen3-Coder 30B（MoE 架构，原生 256K 上下文）和 Devstral Small 2 24B（SWE-bench 表现亮眼）。如果你显存有限，Qwen2.5-Coder 的 7B 和 14B 量化版本是更稳的入门选择。模型拉下来后用 ollama list 确认都在。

第三步：把 Ollama 暴露给本地编辑器（代码不出机的关键）

重点来了：不要直接把 11434 端口公网开放。那样谁都能调你的模型，而且日志可能泄露上下文。正确做法是走 SSH 隧道，把远端端口映射到本机。

ssh -N -L 11434:127.0.0.1:11434 user@your-vps-ip

这条命令在你电脑本地开一个 11434 端口，流量通过加密隧道转发到 VPS 的本地端口。你的 VS Code 插件连的是 localhost:11434，代码和请求全程走 SSH 加密，VPS 上模型吐出的结果也只在你本机显示。想更省事可以不写公网防火墙规则，关掉 11434 的入站，只留 22 端口。

如果你团队多人要用，可以给 Ollama 套一层带鉴权的反向代理（比如 Nginx + 基础认证 + HTTPS），再配合 VPN 或隧道。核心原则只有一个：模型端口绝不能裸奔在公网。

第四步：Continue 做补全 + 聊天

本地编辑器装好 Continue 插件后，改它的配置文件（一般是 ~/.continue/config.yaml）。用 schema v1 写法，把角色分开：

name: Local Coding Stack
version: 1.0.0
schema: v1
models:
  - name: Qwen Coder 7B
    provider: ollama
    model: qwen2.5-coder:7b
    roles:
      - chat
      - edit
  - name: Qwen Autocomplete
    provider: ollama
    model: qwen2.5-coder:1.5b
    roles:
      - autocomplete

保存后 Continue 会自动重载，不用重启。这里有一个坑：补全一定要用带 fill-in-the-middle 训练的模型，并分配 autocomplete 角色，否则行内建议会乱码。Qwen-Coder 全系列支持 FIM，所以大小模型都能用。另一个坑是别让 GitHub Copilot 和 Continue 同时抢幽灵文本，有 Copilot 就先关掉。

验证很简单：新建 test.py 输入 def fib(，停顿一下，灰色补全建议就该出现了，按 Tab 接受。首条补全会慢几秒，因为模型正在加载进显存，之后就顺了。

第五步：Cline 做多文件 Agent 编辑（避开上下文陷阱）

Cline 连本地 Ollama 也简单：在设置里把 API Provider 选 Ollama，Base URL 填 http://localhost:11434，下拉选你拉好的模型即可。但它有个 90% 新手都会踩的坑——上下文窗口陷阱。

Ollama 默认把模型的上下文窗口（num_ctx）压到大约 2K 到 4K token。Cline 这种 Agent 会一次性把多个文件、命令输出塞进上下文，几轮工具调用后就把窗口撑爆，然后它会在你看不见的地方静默截断、循环或失败。修法是把上下文显式拉高到 32K 以上。两种办法：

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

或者写一个 Modelfile 固化：

FROM qwen3-coder:30b
PARAMETER num_ctx 32768
ollama create qwen3-coder-32k -f Modelfile

然后在 Cline 里选新建出来的 qwen3-coder-32k。32K 是 Cline 的实用下限，条件允许开 64K 更稳。另外建议打开 Cline 的 Compact Prompt（压缩提示）选项，任务保持聚焦，上下文越大响应越慢。

实测里，24GB 显存跑 Qwen3-Coder 30B（Q4）能稳定撑四万 token 上下文，做跨文件重构、补测试、改接口都很顺。显存不够就降到 14B，别硬上 30B，否则频繁卸载到内存会卡到没法用。

第六步：混合路由（本地跑小活，云端跑难题）

本地模型的定位不是全盘替代云端旗舰，而是把合适的工作留在边界内。混合路由的思路是：日常补全、单文件小改、敏感代码库的全部操作，走本地 Ollama；碰到特别难的多步架构任务，临时切到云端强模型，敏感片段不喂给它。

Cline 本身支持任意厂商，你可以在不同任务间切换 Provider：简单活用 Ollama 本地，难的活切到 API Provider。也可以用开源路由工具（比如社区里的 CC-Switch 类本地路由）在 127.0.0.1 上起一个转发层，把不同请求按规则分流到本地或云端，Cline 只需连一个本地地址。这样既能保住代码隐私的底线，又不放弃云端在难题上的能力。

一句话总结这套架构的价值：把高频、敏感、可并行的工作留在自己机器上，把低频、高难、可脱敏的工作交给云端。你既守住了合规边界，也没有牺牲太多生产力。