LM Studio + Continue：搭建本地AI编程环境完整指南

在AI辅助编程日益普及的今天，GitHub Copilot 等云端工具虽然强大，但订阅费用、隐私顾虑以及网络依赖始终是绕不开的痛点。GitHub Copilot 基于 OpenAI 的 Codex 模型（后升级为 GPT-4 系列），自2021年技术预览以来已成为最主流的AI编程助手，月订阅费为10美元（个人版）。其核心工作原理是将用户的代码上下文发送到云端服务器进行推理，再将生成的建议返回本地编辑器。这意味着代码片段会经过第三方服务器，对于涉及商业机密、军工安防或金融合规的项目，存在不可忽视的数据泄露风险；而云端依赖也意味着在断网、高延迟或服务器宕机时完全无法使用。

本文基于B站UP主 Lorem314 的实操教程，系统梳理如何借助 LM Studio 在本地部署大语言模型，再通过 VS Code 的开源插件 Continue 实现代码自动补全与 Agent 编程，打造一套完全离线、免费且私密的本地AI编程环境。

用 LM Studio 部署本地大语言模型

LM Studio 是一款支持在本地运行大语言模型的桌面应用，也是整套方案的核心基础设施。其底层基于 llama.cpp 推理引擎——这是由 Georgi Gerganov 开发的纯 C/C++ 大语言模型推理框架，支持 CPU 和 GPU 混合推理。LM Studio 在此之上封装了图形化界面、模型管理和 OpenAI 兼容的 API 服务层，使非专业用户也能轻松部署本地模型。

需要注意的是，官网下载页面提供了两个版本：第一个 Bionic 只是纯聊天工具，无法对外开放 API 服务；真正需要的是第二个 LM Studio，它支持向其他程序提供 API 接口——这也是后续对接 VS Code 的关键前提。其 API 服务遵循 OpenAI Chat Completions API 规范，这意味着任何支持 OpenAI API 的客户端——包括 Continue、Cursor 等——都可以无缝对接，无需额外适配。

安装完成后，首要任务是下载并加载一个模型。在左侧边栏的搜索功能中，教程以通义千问（Qwen）系列为例进行演示。模型名称后的 B（Billion） 代表参数量，例如 30B 即 300 亿参数。一般来说，参数越多，模型体积越大、生成质量越高，但对硬件的要求也越苛刻。

读懂GGUF模型格式与量化等级

选择模型时有两个技术细节值得关注：

文件格式：优先选择 GGUF 格式。GGUF（GPT-Generated Unified Format）是 llama.cpp 项目从早期的 GGML 格式演进而来的模型存储格式，于2023年8月正式推出。与 Hugging Face 生态中广泛使用的 SafeTensors 格式不同，GGUF 将模型权重、分词器配置和超参数元数据全部封装在单一文件中，天然支持量化权重存储，且无需 Python 运行时即可加载。它兼容 Windows、Linux 和 macOS，通用性最好。相比之下，SafeTensors 格式虽然安全性好（避免了 pickle 反序列化漏洞），但通常需要配合 transformers 库和完整的 Python 环境使用，无法在 LM Studio 中直接使用。
量化版本：Q 即 Quantized（量化），后面的数字代表用多少位保存权重。量化是模型压缩的核心技术之一，其本质是用更低精度的数据类型来近似表示原始的高精度浮点权重。原始模型通常使用 FP16（16位浮点数，每个参数占2字节）或 BF16 存储，一个7B参数模型就需要约14GB空间。通过 Q8 量化（8位整型），空间直接减半至约7GB；Q4 量化则进一步压缩至约3.5GB。位数越高，体积越大、质量越好。此外，后缀中的 K 表示较新的 K-Quant 量化方法——它对模型不同层采用不同的量化精度，对信息密度高的注意力层保留更高精度，对冗余较多的前馈层使用更激进的压缩，从而在相同位宽下获得更好的生成质量。M/S/L/XL 则代表 Medium、Small、Large 等不同尺寸变体，其中 M（Medium）通常是质量与体积的最佳平衡点。

显存不够怎么办？善用MOE混合专家模型

加载模型时最需要关注的是体积。模型权重会优先载入 GPU 显存，超出部分才转入内存。一旦数据落到内存，就需要经由 PCIe 总线传输，响应速度会明显下降。PCIe 4.0 x16 的理论带宽约为 32GB/s，PCIe 5.0 x16 约为 64GB/s，而 GPU 的 HBM/GDDR 显存带宽通常在 500-1000GB/s 以上。这意味着从内存读取参数的速度可能比从显存读取慢 10-30 倍，直接体现为推理时每秒生成的 Token 数（tokens/s）大幅下降。

如果有一部分放到了内存中,那么就需要通过PCIE总线来传输数据

问题在于，一个 17G 的模型对消费级显卡而言几乎不可能全部塞进显存——即便是 RTX 5080 也仅有 16G 显存。此时有一个非常实用的方案：选择名称中带 A3B 的 MOE 模型（Mixture of Experts，混合专家模型）。

混合专家模型的概念最早可追溯到1991年的学术论文，但真正在大语言模型中大放异彩是从 Google 的 Switch Transformer（2021年）和后来的 Mixtral 8x7B（2023年底由 Mistral AI 发布）开始。在传统的稠密（Dense）Transformer 模型中，每个 Token 都会经过所有参数层的计算；而 MoE 架构将前馈网络（FFN）层替换为多个并行的"专家"子网络，并引入一个门控网络（Router/Gate）来决定每个 Token 应被分配给哪些专家处理。

名称中的 A（active）表示每次激活的参数量。例如一个 30B 参数的模型，每次可能只激活约 3B 参数，这意味着虽然模型容量（知识储备）接近 30B 级别，但每次推理的计算量仅相当于 3B 模型，实现了"用大模型的知识、小模型的速度"。这是在有限显存下兼顾速度与质量的关键技巧——非活跃专家虽然仍需存储在内存中，但不参与当前计算，可以被放置在较慢的存储介质上。

从 Hugging Face 手动下载GGUF模型

LM Studio 内置下载器偶尔不稳定，此时可转向 Hugging Face 手动下载。搜索时务必加上 GGUF 关键字（如 Qwen A3B GGUF），否则下载的将是无法使用的 Safe Tensor 文件。下载完成后，需将 GGUF 文件放入 LM Studio 的默认下载文件夹，并按"作者名/模型名"的层级结构创建对应目录，模型才会出现在加载列表中。

在里面去放下载好的GGUF格式的文件

三个关键加载参数决定运行体验

加载模型前，有三个参数直接影响推理速度和资源占用：

Context Length（上下文长度）：决定模型一次能理解和思考的 Token 总量，调得越高越占空间。上下文长度以 Token 为单位衡量——英文中平均1个单词约1.3个 Token，中文中1个汉字通常为1-2个 Token。一个 8K 上下文大约对应 6000 个英文单词或约 200 行代码。在 AI 编程场景中，更长的上下文意味着模型可以同时理解更多文件内容、函数定义和项目结构，生成更准确的补全。但上下文长度与显存占用呈近似线性关系（因为需要存储 KV Cache），将上下文从 4K 扩展到 32K 可能额外消耗数 GB 显存。因此在本地部署时，需要根据实际显存余量合理设置此参数。
GPU Offload：设定给 GPU 预留的空间。拉满即全部放入显存；若想为其他软件腾出显存，可适当调低，但代价是模型需更频繁地从内存读取参数，速度下降。这本质上是在显存容量和推理速度之间做精细的取舍。
Force MOE weights onto CPU：仅 MOE 模型才有的选项，用于将指定层数的专家权重强制交给 CPU 和内存处理。设为 0 则全交给 GPU；数值越高，交给 CPU 的部分越多。实测将该值设为 32 左右，既为显存腾出空间，响应速度又能保持在可接受范围。

加载后可通过任务管理器观察：虽然模型体积达 22G，但由于大部分专家权重被放到内存，专用 GPU 内存并未占满——这正是 MOE 模型的优势所在。

开启API服务对接VS Code

要让 VS Code 使用本地模型，需在 LM Studio 的开发者面板中加载模型（若无该面板，可在"设置-开发者"中打开开发者模式）。加载后，LM Studio 会在本地开启 API 服务，其他软件即可通过该地址连接。

同时也会在本地开启API服务

Continue 是一款开源的 VS Code AI 编程助手插件，由同名初创公司开发并以 Apache 2.0 协议开源。其核心设计理念是"模型无关"（model-agnostic）——它不绑定任何特定的模型提供商，用户可以自由连接 OpenAI、Anthropic、Ollama、LM Studio 等任意后端，这与 GitHub Copilot 的封闭生态形成鲜明对比。Continue 支持三种核心功能：Chat（对话式编程问答）、Autocomplete（行内代码补全）和 Edit（选中代码后进行修改），其 Agent 模式还允许模型调用工具（如读写文件、执行终端命令），实现更复杂的多步骤编程任务。

在 VS Code 扩展市场搜索 Continue 安装后，侧边栏会出现其图标。

Continue插件的补全参数调优建议

在 Continue 的配置中，几个补全相关参数值得留意：

自动补全超时时间：建议设为 1500–3000 毫秒。若电脑性能有限、推理较慢，可适当延长，避免响应返回前请求就被取消。
防抖输入：一般设为 250–300 毫秒。
工具调用权限：读取文件可放开，创建文件建议保留确认。若觉得某些规则（如 Fetch URL、Read Skill）无需询问，也可全部设为 Auto。

配置模型并实测AI编程效果

在模型配置中，Provider 选择 LM Studio，然后编辑配置文件（Continue 的配置文件采用 JSON 格式，位于 ~/.continue/config.json）。建议配置两个模型：一个用于对话/Agent（如 Qwen Agent），一个更小的模型用于代码自动补全（如 Qwen Autocomplete）。

首先是Name

配置文件中的关键字段包括：

Name：自定义名称，用于区分不同用途。
Provider：均填 LM Studio。
Model：填 LM Studio 中加载的模型实际名称（可直接复制粘贴）。
API Base：本地地址的 1234 端口后需加上 /v1 后缀，即使用 OpenAI 兼容接口。OpenAI 的 Chat Completions API（/v1/chat/completions）已经成为大语言模型 API 的事实标准，几乎所有本地推理框架（llama.cpp、vLLM、Ollama、LM Studio）和众多云端模型提供商（DeepSeek、Mistral、Groq 等）都提供了兼容该接口的实现。这种标准化使得上层应用只需适配一套 API 规范，就能在不同模型后端之间自由切换。
Roles：默认为对话模型；若指定为补全模型需加 autocomplete；对话模型若需图片分析与工具调用能力，可补充 capabilities 中的 tool_use 与 image_input。

配置保存后，即可在 Chat/Edit 中选用 Agent 模型、在补全场景选用 Autocomplete 模型。实测让模型"在根目录写一个导出冒泡排序函数的 sort.js"，模型经过思考后成功生成文件；随后在编写调用代码时，自动补全也顺利给出了正确内容，运行结果排序无误。

本地AI编程的价值与适用场景

LM Studio + Continue 的组合，为开发者提供了一条彻底摆脱云端订阅、保障代码隐私的路径。其核心门槛在于硬件——显存决定了能跑多大的模型。而 MOE 模型的出现，让消费级显卡也能运行数百亿参数级别的模型，大幅降低了本地部署的成本。

当然，本地方案在推理速度和顶级模型能力上仍难与云端旗舰持平，适合对隐私敏感、有稳定硬件基础或希望离线工作的开发者。对于追求极致体验的用户，这套方案更适合作为 GitHub Copilot 的有力补充而非完全替代。无论如何，它代表了AI编程走向本地化、私有化的重要方向。