用 Twinny 在 VS Code 中接入本地模型实现代码补全与对话

Twinny 是一款 VS Code 扩展，把代码补全、内联编辑、对话、Agent 模式、工作区索引、代码评审与终端命令生成这些能力，全部接到你自己指定的模型服务器上。模型可以跑在本机，可以跑在你另一台电脑上（通过加密的点对点链路），也可以走托管 API。扩展本身不收集遥测、不需要登录，采用 MIT 许可。适合希望代码不出本机、又想在编辑器里获得补全与问答能力的开发者；也适合手上已有 GPU、想把算力用起来的团队。如果你只是想先看看这类本地模型工具的整体思路，可以先浏览 Twinny 的工具页，再回到本文按步骤配置。

需要先建立一个认知：Twinny 本身不含模型。它的质量取决于背后的模型，而模型的速度取决于跑它的机器。所以本文的重点不是「装个插件」，而是把服务器、模型、任务三者配对——补全要快，对话要准，两者往往不是同一个模型。

准备工作

硬件与内存的对应关系

模型规模用参数量表示（1.5B、7B、14B……）。在常见的 4 比特量化下，所需内存大致是每十亿参数 0.6 GB，再留一点给上下文。模型必须装进快速内存——GPU 显存或 Apple 统一内存——才跑得快；溢出到系统内存或纯 CPU 推理也能用，只是慢。官方给出的起步配置如下，属于参考起点而非硬性规则：

可用内存	补全用模型	对话与编辑用模型
仅 CPU，8 GB 内存	qwen2.5-coder:1.5b-base	qwen2.5-coder:1.5b-instruct 或 3b-instruct，慢但可用
4–6 GB 显存	qwen2.5-coder:1.5b-base	qwen2.5-coder:3b-instruct
8 GB 显存	qwen2.5-coder:1.5b-base 或 7b-base	qwen2.5-coder:7b-instruct
12–16 GB 显存，或 16 GB 以上 Apple 芯片	qwen2.5-coder:7b-base	qwen2.5-coder:14b-instruct
24 GB 显存，或 32 GB 以上 Apple 芯片	qwen2.5-coder:7b-base	qwen2.5-coder:32b-instruct、codestral

比参数规模更重要的两件事：

• 补全要速度。两秒后才出现的建议，用户早就自己敲过去了。在能跑 7B 的机器上，用 1.5B 或 3B 的 base 模型做补全，体验往往反而更好。
• 对话可以等。问答、评审、内联编辑对延迟不敏感，可以把更大的模型留给它们。

Agent 模式比普通对话更吃模型：需要一个能力较强的编码模型（例如 qwen3-coder:30b），上下文至少 8k token。

选择本地服务器

常见选择有四种，按上手难度排序：

• Ollama：几乎适合所有人。一条命令安装、一条命令拉模型，作为后台服务运行，原生提供补全与嵌入端点，也是 Devices 功能共享的那一种。
• LM Studio：带图形界面，适合喜欢在桌面应用里浏览和试模型的 Windows / macOS 用户，内置服务器。
• llama.cpp：自己挑 GGUF 文件和每个启动参数，原始速度最好，但没有模型管理。
• vLLM、TGI 等：OpenAI 兼容接口，吞吐更高，适合从一台 GPU 机器给整个团队提供服务，配置也更复杂。

拿不准就用 Ollama。本文的完整示例也以 Ollama 为准；其他服务器跑起来之后流程一致。

账号与安装

不需要注册账号，也不需要 API 密钥——除非你打算用托管 API。需要准备的是：

1. 从 Ollama 官网安装 Ollama，它会作为后台服务常驻。
2. 从 VS Code Marketplace 或 Open VSX 安装 Twinny 扩展。

操作步骤

第一步：拉取两个模型

对话和补全是两种不同的任务，需要两种不同的模型。在终端里执行：

ollama pull qwen2.5-coder:7b-instruct
ollama pull qwen2.5-coder:1.5b-base

为什么是两个？对话需要会听指令的 instruct 模型；代码补全需要为 fill-in-the-middle 训练过的模型，在多数模型家族里这是 base 或 code 变体。instruct 模型在补全场景下会「说话」而不是「补代码」。补全模型越小越好，速度比深度重要，上面这个 1.5B 模型在多数笔记本上能在零点几秒内给出结果。

如果还要用工作区搜索，再拉一个嵌入模型：

ollama pull nomic-embed-text

第二步：让 Twinny 自动发现服务器

首次运行时，Twinny 会探测常见的本地端口。Ollama 在 11434 端口应答，于是 Twinny 读取它的模型列表，自动创建以下配置并在通知里告知：

• 一个对话 provider，使用 instruct 模型；
• 一个自动补全 provider，使用 base 模型；
• 如果装了嵌入模型，再加一个嵌入 provider。

某个任务如果找不到合适的模型，Twinny 会把它留空，而不是指向错误类型的模型。判断依据是模型名称：自动补全会取列表中第一个名字里带 code 或 coder 的模型，这可能正好是 qwen2.5-coder:7b-instruct。所以自动发现之后要检查一下补全拿到的是哪个模型，必要时手动换成 base 版本。

如果没有任何服务器应答（Ollama 还没启动，或用了非默认端口），Twinny 会提示一次，并给出「Choose a provider」按钮；Providers 标签页会显示欢迎界面，上面有「Search again」「Choose a provider」「Import providers」三个入口。启动服务器后重新搜索，或者直接选 Ollama 预设并填入端口。

第三步：在 Providers 标签页核对三个任务

从活动栏打开 Twinny 侧边栏，进入 Providers 标签页（机器人图标）。页面按任务分成三块：对话、自动补全、嵌入。每块显示当前生效的 provider；空白的区块意味着该任务没有配置任何模型。

在某个 provider 的卡片上点「Test provider」，会发送一个小请求，返回成功或服务器给出的原始错误信息。这是排查配置问题最快的手段——它把服务器端的报错原样带回来，而不是笼统地说「连接失败」。

状态栏在空闲时显示 </>，生成过程中显示转圈动画，点击它可以打开快捷操作。

第四步：验证代码补全

打开一个源码文件，开始写一个函数。短暂停顿后，编辑器里会出现灰色的建议文本，按 Tab 接受。

想要多行建议，可以先写一行描述接下来要做什么的注释，然后在下一行停住，等待多行补全出现。补全会结合打开的文件、最近的编辑和 IntelliSense 提供的上下文。

第五步：验证内联编辑

选中几行代码，按 Ctrl+I（macOS 上是 Cmd+I），输入修改要求，例如「add error handling」，回车。改动会以 diff 形式流式显示在编辑器里。按 Ctrl+Shift+Enter 接受，按 Ctrl+Shift+Backspace 拒绝，也可以继续细化要求。

第六步：验证对话与上下文引用

在侧边栏的输入框里敲 @，会列出可以附加的内容：某个文件、某个符号、当前问题列表、git diff、终端的最后一次输出，以及 @workspace（对工作区索引做一次搜索）。附加之后提问即可。

回答里的代码块带有 apply、insert、copy、new file、terminal 几个按钮，可以直接把代码落到编辑器或终端里。

第七步：从报错直接修复

把光标放在带红色波浪线的位置，打开灯泡菜单，选择「Fix with Twinny」。这是把诊断信息直接送进对话流程的快捷入口。

第八步（可选）：开启 Agent 模式

打开 Agent 模式后，对话模型会读取、搜索、编辑文件并执行命令，每一步都展示出来。命令在执行前会先询问，除非你显式允许。注意这一步对模型的要求高于普通对话：需要能力较强的编码模型，上下文 8k token 以上。

第九步（可选）：建立工作区索引

把工作区做嵌入之后，对话就能找到问题所指向的代码，结果由本地 reranker 排序。索引存放在 ~/.twinny/embeddings/ 下，每个工作区一个文件夹。

一个完整示例

下面是从零到能用的最小路径，假设机器有 8 GB 显存。

1. 安装并启动 Ollama，确认服务在后台运行。

2. 拉取模型：

ollama pull qwen2.5-coder:7b-instruct
ollama pull qwen2.5-coder:1.5b-base
ollama pull nomic-embed-text

3. 安装 Twinny 扩展，重启 VS Code。

4. 等待自动发现。通知里会说明创建了哪些 provider。打开 Providers 标签页，确认：对话指向 7b-instruct，补全指向 1.5b-base，嵌入指向 nomic-embed-text。如果补全被指到了 7b-instruct，手动改成 1.5b-base。

5. 逐个点 Test provider，三个都返回成功再往下走。

6. 写一个函数，等灰色建议出现，按 Tab 接受。

7. 选中一段代码，Ctrl+I，输入「add error handling」，回车，看 diff，Ctrl+Shift+Enter 接受。

8. 在侧边栏提问，用 @ 附加当前文件，确认回答里的代码块按钮可用。

到这里，补全、内联编辑、对话三条主链路都通了。剩下的 Agent 模式、工作区索引、代码评审、提交信息生成、终端命令生成，都是在这套 provider 配置之上叠加的功能。

注意事项

小显存上两个模型会互相换出

小显存 GPU 上同一时刻只能驻留一个模型。如果对话和补全用的是同一台服务器上的不同模型，每次请求都可能把另一个换出去。Ollama 会为 Twinny 把补全模型保持加载 twinny.keepAlive 指定的时长（默认 5 分钟），Twinny 在 VS Code 启动或重新获得焦点时会重新加载它（twinny.warmUpModel）。显存足够时，两个模型可以同时驻留。

自动发现的模型匹配只看名字

前面提过，自动补全取的是名字里带 code 或 coder 的第一个模型，这可能是 instruct 版本。instruct 模型做补全会输出解释性文字而不是干净的补全结果。装完扩展后务必检查这一项。

托管 API 的适用边界

以下情况适合改用托管 API：想要对话、评审、编辑拿到最好的回答，且代码不涉密；没有 GPU 而 CPU 很慢；想用 Codestral 做补全但不想自己跑。Mistral 托管的 Codestral 是 Twinny 唯一推荐用于自动补全的托管模型。托管 provider 及其能力在 Hosted APIs 页面列出；Anthropic、Groq、Cohere、Perplexity、Gemini 在 Twinny 中仅用于对话。

上下文窗口

上下文窗口决定了模型一次能看到多少代码。补全场景下窗口不必很大，但对话、评审和 Agent 模式会附加文件、符号、问题、diff、终端输出，窗口太小会截断关键信息。Agent 模式明确要求 8k token 以上。

配置与数据存放位置

内容	位置
Provider 配置	VS Code 全局状态；若 twinny.providerStorageLocation 设为 file，则存于扩展全局存储中的文件
对话记录	VS Code 全局状态
提示词模板	~/.twinny/templates/*.hbs
工作区索引	~/.twinny/embeddings/，每个工作区一个文件夹
P2P 身份与已配对设备（命令行节点）	~/.twinny/node/
P2P 身份（扩展）	VS Code 密钥存储
日志	Twinny 输出通道

排查问题时先看 Twinny 输出通道，再回到 Providers 标签页点 Test provider 拿服务器原始报错，这两处基本能定位绝大多数配置问题。

最后提醒一句：模型名称、可用 provider、各功能的支持范围会随版本变化，具体以官网当前信息为准。