企业官网建设流程全解析

1. 服务器 Docker 部署 Ollama 后本地 VSCode 代码补全链路怎么搭

很多团队手里有一台局域网里的 GPU 服务器，平时跑训练或者推理任务，但写代码的时候还是得靠本地编辑器一个个敲。其实完全可以把这台服务器的算力利用起来，让 VSCode 里的 Continue 插件直接调用服务器上的模型做代码补全。这套链路的核心思路是：服务器上用 Docker 跑 Ollama 提供模型推理服务，本地通过端口转发把请求映射到局域网地址，Continue 插件配置好 Base URL 和模型 ID 之后就能在编辑器里直接补全代码。

Ollama 是一个轻量级的本地大模型运行工具，它能用一条命令拉取并运行各种开源模型，比如 qwen2.5-coder、deepseek-r1、llama3 等。Docker 部署的好处是环境隔离、版本可控、迁移方便，尤其适合服务器上已经有其他服务在跑的情况。Continue 则是 VSCode 里目前比较活跃的 AI 编程插件，支持自定义模型提供方，既能接云端 API 也能接本地 Ollama 服务。

这套方案适合谁？如果你有一台局域网内的 Linux GPU 服务器，本地是 Windows 或 Mac 开发机，想让代码补全和对话走自己的算力而不是依赖外部服务，那这套流程就是为你准备的。整个链路涉及四个环节：服务器 Docker 启动 Ollama、拉取代码模型、本地端口转发、Continue 配置接入。下面我会按实际操作顺序一步步拆开讲，每个环节都给出可复制的命令和配置片段。

需要提前说明的是，Ollama 默认监听 11434 端口，Continue 插件在本地模式下默认请求127.0.0.1:11434，所以端口转发是打通本地和服务器之间的关键一步。如果你希望进一步统一管理模型通道，也可以把 Continue 的 Base URL 改到 TaoToken 的 API 地址，这样本地和服务器上的模型调用可以走同一个入口，后面我会在配置章节里给出具体写法。

2. TaoToken 前置准备与 Ollama 服务启动参数详解

在开始配置 Continue 之前，先把服务器端的 Ollama 服务跑起来。这一步的核心是 Docker 启动参数，尤其是 GPU 支持和端口映射。如果你用的是 NVIDIA 显卡，需要先确认服务器上已经装好了 NVIDIA Container Toolkit，否则--gpus=all这个参数会报错。

先拉取 Ollama 的官方镜像：

docker pull ollama/ollama

然后启动容器，这里给出一个完整的启动命令：

docker run -d \ --gpus=all \ -v ollama:/root/.ollama \ -p 11434:11434 \ --name ollama \ --restart unless-stopped \ ollama/ollama

逐段解释一下这些参数。-d表示后台运行，--gpus=all把宿主机所有 GPU 暴露给容器，-v ollama:/root/.ollama把模型文件持久化到 Docker 卷里，这样容器重建后模型不用重新下载。-p 11434:11434把容器端口映射到宿主机，--restart unless-stopped保证服务器重启后容器自动拉起。

启动完成后，用docker ps确认容器状态：

docker ps | grep ollama

正常输出里应该能看到ollama/ollama镜像和Up状态。如果容器启动后立刻退出，大概率是 GPU 驱动或 Container Toolkit 没装好，可以用docker logs ollama看具体报错。

接下来拉取代码模型。qwen2.5-coder 是目前代码补全场景里表现比较均衡的选择，7B 版本在 8GB 显存左右就能跑：

docker exec -it ollama ollama pull qwen2.5-coder:7b

如果你显存比较充裕，可以上 14B 或 32B 版本，补全质量会更好。拉取完成后用ollama list确认：

docker exec -it ollama ollama list

输出里会列出模型名称、ID、大小和修改时间。看到qwen2.5-coder:7b出现在列表里，说明模型已经就绪。

这里顺便提一下 TaoToken 的前置准备。TaoToken 是一个统一模型调用通道，官网地址是https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=，API 地址是https://taotoken.net/api。如果你后续想把 Continue 的请求统一走 TaoToken，需要先在控制台创建一个 API Key，具体入口在https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite。Key 创建好之后，在 Continue 配置里把apiBase指向 TaoToken 的 API 地址，apiKey填上刚生成的 Key，模型 ID 按 TaoToken 文档里支持的名称填写即可。这样本地 VSCode 的补全请求就会先到 TaoToken，再由 TaoToken 路由到对应模型，适合需要统一管理多个模型来源的场景。

3. Continue config.json 中 models 与 apiBase 字段配置示例

服务器端 Ollama 跑起来之后，回到本地 Windows 开发机。Continue 插件默认请求127.0.0.1:11434，但 Ollama 实际在局域网服务器的192.168.2.246:11434上，所以需要做端口转发。用管理员权限打开 PowerShell，执行：

netsh interface portproxy add v4tov4 listenaddress=127.0.0.1 listenport=11434 connectaddress=192.168.2.246 connectport=11434

这条命令的意思是：本地监听127.0.0.1:11434，把所有请求转发到192.168.2.246:11434。执行完后用 curl 验证：

curl http://127.0.0.1:11434

如果返回Ollama is running，说明转发链路已经通了。如果返回连接拒绝，检查服务器防火墙是否放行了 11434 端口，以及netsh命令是否用管理员权限执行。

接下来配置 Continue。打开 VSCode，点击侧边栏的 Continue 图标，选择 local 模式，然后打开配置文件。Windows 下的路径是%USERPROFILE%\.continue\config.yaml，MacOS 和 Linux 下是~/.continue/config.yaml。如果你用的是较新版本的 Continue，配置文件可能是config.json，字段结构基本一致。

下面给出一个完整的 config.yaml 示例，包含 chat、autocomplete 和 embed 三种角色：

name: LocalAssistant version: 1.0.0 schema: v1 models: - name: Qwen2.5-Coder 7B provider: ollama model: qwen2.5-coder:7b apiBase: http://127.0.0.1:11434 roles: - chat - edit - apply - name: Qwen2.5-Coder Autocomplete provider: ollama model: qwen2.5-coder:7b apiBase: http://127.0.0.1:11434 roles: - autocomplete - name: Nomic Embed provider: ollama model: nomic-embed-text:latest apiBase: http://127.0.0.1:11434 roles: - embed context: - provider: code - provider: docs - provider: diff - provider: terminal - provider: problems - provider: folder - provider: codebase

几个关键字段说明一下。provider指定为ollama，表示走 Ollama 的 API 协议。model必须和ollama list里显示的模型名称完全一致，否则会报模型找不到。apiBase这里填的是转发后的本地地址http://127.0.0.1:11434，如果你不想做端口转发，也可以直接填服务器地址http://192.168.2.246:11434，前提是本地能直接访问服务器端口。roles指定模型用途，autocomplete用于代码补全，chat用于对话，embed用于向量化。

如果你想把请求改到 TaoToken 统一通道，把provider改成openai，apiBase改成https://taotoken.net/api，apiKey填上在控制台创建的 Key，model填 TaoToken 支持的模型 ID。这样 Continue 的请求会先到 TaoToken，再由 TaoToken 转发到对应模型。这种写法适合需要统一管理多个模型来源、或者本地服务器暂时没有合适模型的情况。

配置保存后，Continue 会自动重载。如果没生效，按Ctrl+Shift+P执行Continue: Reload Config手动刷新。

4. 验证补全请求与端口转发连通性排查

配置写完之后，最重要的一步是验证整条链路是否真的通了。验证分两层：先确认端口转发和 Ollama API 能正常响应，再确认 Continue 插件能拿到补全结果。

第一层验证，在本地 PowerShell 里直接请求 Ollama 的 API：

curl http://127.0.0.1:11434/api/tags

正常返回是一个 JSON，里面列出服务器上所有已拉取的模型。如果返回空列表或者连接超时，说明端口转发或服务器端 Ollama 有问题。可以分步排查：先在服务器上执行curl http://127.0.0.1:11434/api/tags，确认 Ollama 本身正常；再在本地执行curl http://192.168.2.246:11434/api/tags，确认局域网直连正常；最后测127.0.0.1的转发地址。

第二层验证，在 VSCode 里按Ctrl+L打开 Continue 对话框，输入一个简单的 prompt，比如「写一个 Python 函数计算斐波那契数列」。如果模型正常返回代码，说明 chat 角色配置成功。接着测试补全：新建一个.py文件，输入def quick_sort，稍等一两秒，看是否有灰色补全建议出现。如果没有，检查autocomplete角色的模型是否配置正确，以及 Continue 的补全功能是否在设置里开启。

还可以用 Ollama 的 generate 接口直接测试模型推理：

curl http://127.0.0.1:11434/api/generate -d '{ "model": "qwen2.5-coder:7b", "prompt": "def add(a, b):", "stream": false }'

返回的 JSON 里response字段就是模型生成的补全内容。如果这一步能拿到结果，但 Continue 里没反应，问题大概率出在 Continue 的配置字段上，重点检查model名称和roles是否匹配。

实测下来，端口转发这一步最容易出问题。Windows 的netsh portproxy在系统重启后会失效，需要重新执行，或者写一个开机脚本自动添加。另外，如果服务器上 Ollama 容器重启后 IP 变了，转发规则也要跟着改。建议给服务器配一个固定局域网 IP，避免频繁调整。

5. 常见报错排查：401、local proxy failed、reading choices 与 OAuth

配置过程中会遇到几类典型报错，这里按实际出现的频率逐个拆解。

401 Unauthorized：这个报错通常出现在你把apiBase指向 TaoToken 或其他需要鉴权的通道，但apiKey没填或者填错了。检查 config.yaml 里对应模型的apiKey字段，确认 Key 没有多余空格，也没有过期。如果用的是 Ollama 本地服务，一般不会出现 401，因为 Ollama 默认不校验 Key。

local proxy failed：Continue 在请求本地地址时，如果端口转发没生效或者服务器不可达，会报这个错。排查顺序是：先curl http://127.0.0.1:11434看转发是否通，再curl http://192.168.2.246:11434看局域网直连是否通，最后检查服务器防火墙和 Ollama 容器状态。如果服务器上 Ollama 容器挂了，docker start ollama重新拉起即可。

reading choices 报错：这个错误一般出现在使用 OpenAI 兼容接口时，返回的 JSON 结构里没有choices字段。常见原因是apiBase路径写错了，比如漏了/v1或者多写了/api。Ollama 的 OpenAI 兼容接口地址是http://127.0.0.1:11434/v1，如果你用provider: openai接 Ollama，apiBase要写成这个。如果接 TaoToken，apiBase写https://taotoken.net/api，具体路径以文档为准。

OAuth 相关报错：Continue 在 local 模式下一般不需要登录，但如果你之前登录过云端账号，插件可能会尝试走 OAuth 流程。解决办法是在 Continue 设置里切换到 local 模式，或者清除%USERPROFILE%\.continue下的认证缓存文件。如果用的是 Codex 或 Claude Code 这类需要 OAuth 的工具，检查auth.json里的 token 是否过期，必要时重新走一遍授权流程。

另外提一下 CC Switch 和 Cline MCP 的场景。如果你在 Continue 之外还用了 CC Switch 管理多个模型配置，或者用 Cline 的 MCP 功能接本地服务，需要确保三件套一致：Base URL、Key、Model ID。Base URL 指向实际服务地址，Key 按服务要求填写，Model ID 必须和服务端注册的名称完全匹配。任何一项不一致都会导致请求失败。

6. 长期编码场景下的模型通道选择与接入建议

如果你只是偶尔用一下代码补全，本地 Ollama 加端口转发这套方案已经够用了。但如果你每天都要写代码，而且团队里多个人共用一台 GPU 服务器，那模型通道的管理就会变成一个实际问题。每个人本地配置不一样，模型版本不统一，排查问题的时候很难定位是配置问题还是服务问题。

这种场景下，把 Continue 的 Base URL 统一改到 TaoToken 是一个比较省心的做法。TaoToken 的 API 地址是https://taotoken.net/api，在控制台创建 Key 之后，所有人的 Continue 配置里只需要填同一个apiBase和各自的apiKey，模型 ID 按文档里支持的名称填写。这样模型调用走统一通道，版本和路由由通道侧管理，本地不用再关心服务器 IP 变没变、端口转发有没有失效。

具体接入步骤分三步。第一步，在 TaoToken 控制台创建 API Key，入口在https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite。第二步，打开 Continue 的 config.yaml，把provider改成openai，apiBase填https://taotoken.net/api，apiKey填刚创建的 Key，model填支持的模型 ID。第三步，保存配置后按Ctrl+L发一条测试 prompt，确认能正常返回结果。

如果你更偏向长期编码和 Agent 场景，可以了解一下 Coding Plan，入口在https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite。这个方案适合需要持续调用模型做代码生成、重构、测试补全的团队，通道侧会做请求调度和额度管理，本地配置和上面基本一致。

接入文档在https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite，里面有各语言和工具的接入示例，包括 Continue、Cline、Claude Code 等。API Keys 管理页面在https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite，可以随时创建和吊销 Key。模型对话测试入口在https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=chat&utm_campaign=rewrite，不确定模型 ID 是否正确的时候，可以先去这里发一条消息验证。

最后说一个实际踩过的坑。端口转发在 Windows 重启后会失效，如果团队里有人用笔记本办公，每次合盖再打开都可能断掉。解决办法是写一个 PowerShell 脚本，开机自动执行netsh interface portproxy add命令，或者干脆把 Continue 的apiBase直接指向服务器局域网 IP，跳过转发这一步。如果服务器 IP 是动态分配的，在路由器里给它绑一个静态 IP，省得每次都要改配置。