ChatGPT接入本地大模型：零成本无限Token完整教程

背景：Codex 与 ChatGPT 融合带来的本地化机遇

OpenAI Codex 最初是一个专门针对代码生成训练的语言模型，基于 GPT-3 架构微调而来，是 GitHub Copilot 早期的底层引擎。值得了解的是，Codex 于2021年正式发布时，其训练数据包含来自 GitHub 的数十亿行公开代码，覆盖数十种编程语言，在代码补全、函数生成、自然语言转代码等任务上的表现远超通用语言模型。

Codex 演进的深层逻辑：Codex 从专用代码模型到被通用模型整合的演进路径，体现了大模型发展中「规模律（Scaling Law）」的实践验证。专用微调模型在特定任务上虽有短期优势，但随着通用基础模型参数规模持续扩大，其泛化能力最终往往能覆盖甚至超越专用模型。这推动了从「GPT-3 + Codex 微调」的专用范式向「GPT-4 单一大模型统一能力」的通用范式转变——代码能力不再需要独立模型承载，而是作为涌现能力（Emergent Ability）自然包含在足够大的通用模型中。这也是为什么 2023 年后独立 Codex API 逐步退出历史舞台，代码智能体的竞争转向了通用模型的代码推理能力与 Agent 框架设计。

2023年 GPT-4 系列发布后，代码能力已被整合进通用模型，独立 Codex API 逐步退出历史舞台——这一演进路径体现了大模型从专用走向通用、再以智能体形式垂直落地的整体趋势。2025 年 OpenAI 将 Codex 能力整合进 ChatGPT 桌面客户端后，ChatGPT 实际上成为了一个具备代码智能体（Coding Agent）能力的工具，能够直接读写本地文件、执行终端命令。这一架构变化的关键在于：桌面客户端本质上是通过标准 API 调用后端模型，只要 API 格式兼容，任何本地推理服务均可作为替代后端接入。

值得关注的是，OpenAI 于2023年确立的 /v1/chat/completions 接口规范如今已成为 LLM 服务领域的事实标准。这一规范定义了请求体（包含 model、messages、temperature 等字段）和响应体的 JSON 格式，以及流式传输（Server-Sent Events）的协议细节。

事实标准的形成机制：事实标准（de facto standard）的确立通常依赖市场先发优势而非正式标准化组织背书。OpenAI API 格式的广泛采纳是一个典型案例：当生态中足够多的工具链——IDE 插件、桌面客户端、测试框架、智能体编排库——都基于同一接口规范构建后，新进入者若不兼容该规范将面临极高的迁移摩擦成本，形成强烈的网络效应。这与 POSIX 接口规范在 Unix/Linux 生态中的历史地位颇为相似：开发者面向接口编程，底层实现可以随时替换，生态的互操作性由接口规范而非单一厂商保证。正是这一机制，使得 Ollama、LM Studio 等工具选择兼容 OpenAI 格式成为几乎必然的市场决策。

流式传输的底层机制：流式传输是用户体验「逐字输出」效果的底层实现。OpenAI API 通过 Server-Sent Events（SSE）协议实现：服务端在生成每个 Token 后立即通过 HTTP 长连接推送一条 data: {...} 事件，客户端逐条解析并渲染，无需等待完整响应。SSE 基于标准 HTTP/1.1，无需 WebSocket 握手，实现简单且穿透防火墙能力强。在 OpenAI 规范中，请求体设置 "stream": true 即可启用，响应以 data: [DONE] 标志结束。各本地推理框架对 SSE 的完整支持，是 ChatGPT 桌面客户端实现流畅「打字机效果」的必要条件。

由于 OpenAI 在市场上的先发优势，Ollama、LM Studio、llama.cpp、vLLM 等主流推理框架均选择实现相同接口，形成了「一套客户端、多种后端」的生态格局——这也是本文所有方案能够通用的根本原因：应用程序只需面向接口编程，无需关心底层模型的具体实现。

很多人开始关注一个问题：能否绕开云端调用，让 ChatGPT 直接跑在本地部署的开源大模型上？答案是肯定的。通过本文介绍的方法，你不仅可以实现「零成本、无限 Token」的使用体验，还能保证数据完全本地化，不经过任何第三方服务器。

本教程整理了两条主流接入路径：一条是面向新手的 Ollama 直连方案，另一条是通过 CC Switch 中转的通用方案，后者兼容 LM Studio、llama.cpp、vLLM 等几乎所有能开放 API 端口的部署工具。

准备工作：安装官方版 ChatGPT

首先不需要去寻找任何来路不明的安装包。直接点击电脑下方的搜索框，输入「Microsoft Store」打开应用商店，在商店内搜索「ChatGPT」即可找到官方版本。

安装完成后先不要急着打开，因为我们后续要对它的模型接入做改造。使用官方渠道下载不仅能避免安全风险，也能保证程序版本与后续配置的兼容性。

方案一：Ollama 直连——新手最省心的本地大模型接入方式

Ollama 是目前新手上手最快的本地大模型运行工具，它将模型下载、运行、API 服务封装成极简的命令行操作，几乎无需任何配置基础。

技术背景：Ollama 的底层推理引擎基于 llama.cpp 构建，llama.cpp 是由 Georgi Gerganov 开发的高性能 C++ 推理库，支持 CPU 和 GPU 混合推理，并通过 GGUF（GPT-Generated Unified Format）量化格式大幅压缩模型体积与显存占用。Ollama 在此基础上封装了模型仓库管理、自动 API 服务启动（默认监听 localhost:11434）以及跨平台守护进程等功能，用户无需手动配置 CUDA 环境或编译工具链，复杂的底层依赖被完全屏蔽。

深入了解 GGUF 量化：量化是指将模型权重从原始的 float32（32位浮点数）压缩为更低精度的整数表示，如 INT8（8位）、INT4（4位）甚至 INT2，从而大幅减少显存占用和内存带宽需求。常见量化级别如 Q4_K_M 中，4 代表4位量化，K 表示使用了 k-quants 混合精度策略（对关键权重保留更高精度），M 代表中等质量版本。量化虽然会带来一定的精度损失，但实践中 Q4_K_M 在多数推理任务上与全精度模型的差距极小，是性能与质量的最佳平衡点，也是社区最广泛推荐的默认选择。

量化的信息论基础：从更深层的技术视角看，量化本质上是一种有损压缩，其理论依据来自神经网络权重的「低秩性」：大量研究表明，训练后的模型权重矩阵存在大量冗余信息，许多权重值对最终输出的贡献微乎其微。k-quants 策略的创新之处在于识别出「重要权重」（如嵌入层、注意力输出层）并对其保留更高精度，而对贡献较小的前馈网络中间层使用更激进的压缩，实现了精度与压缩率的精细化权衡。这也是为什么同参数量的 Q4_K_M 往往比朴素 INT4 量化表现更好的原因。

下载并运行本地模型

第一步，打开 Ollama 官网下载并安装客户端。安装完成后回到官网，页面上已列出所有支持的开源大模型。

先打開OLAMA的官網安裝

新手建议选择通义千问^广告（Qwen）3.6 或 3.5 系列，具体版本要根据自己电脑的显存大小来挑选——显存越大，能运行的模型参数量就越高。

显存与参数量对照参考：以常见的 4-bit 量化（Q4_K_M）为例，每十亿参数约需 0.5~~0.6 GB 显存。7B 模型约需 4~~5 GB 显存，13B 约需 8 GB，34B 约需 20 GB，70B 则需 40 GB 以上。Qwen 3.5/3.6 系列之所以被推荐，是因为该系列在中英文双语能力与模型体积之间取得了良好平衡，4B 和 7B 版本在入门级显卡（如 8 GB 显存的 RTX 3060）上即可流畅运行。对于显存不足的情况，Ollama 支持 CPU+GPU 混合推理，但速度会有所下降。

复制对应模型的运行代码，粘贴到系统 CMD 命令行中，回车后 Ollama 会自动将模型下载到本地。

启动 ChatGPT 调用本地模型

模型下载完成后，在 CMD 里输入 Ollama 的 ChatGPT 启动指令，选择刚下载好的本地模型，回车。此时 ChatGPT 会自动启动，其调用的推理引擎已切换为你的本地大模型。

不連碗也能隨意用

完成后，即使完全断网也能正常使用，Token 消耗归零，隐私数据不会外流。

方案二：CC Switch 中转——兼容 LM Studio / llama.cpp / vLLM 的通用方案

如果你已经在使用 LM Studio、llama.cpp 或 vLLM 等工具部署了本地模型，不必重新用 Ollama 折腾一遍。借助 CC Switch 做中转，只要模型能开放 API 端口，就能无缝接入 ChatGPT。下面以 LM Studio 为例演示完整流程。

推理框架简介：vLLM 是由加州大学伯克利分校开发的高吞吐量推理引擎，其核心创新是 PagedAttention 技术——借鉴操作系统虚拟内存的分页思想管理 KV Cache，显存利用率较传统框架提升 60%~~80%，并发吞吐量提高 2~~4 倍，特别适合多用户并发的服务端部署。

PagedAttention 详解：传统推理框架为每个请求预分配连续的 KV Cache 显存块，导致大量内存碎片和浪费；PagedAttention 将 KV Cache 拆分为固定大小的非连续「页」，通过页表动态映射，使多个请求可以共享同一物理显存页中未使用的 Token 槽位，大幅提升并发效率。这一机制对单用户本地场景收益有限，但在需要同时服务多个用户的生产环境中优势显著，这也是 vLLM 通常被选用于服务端部署而非个人电脑的原因。

llama.cpp 更适合单机本地推理，LM Studio 则提供了图形化界面封装，降低了使用门槛。LM Studio 由 Element Labs 开发，支持从 Hugging Face 直接搜索和下载 GGUF 格式模型，其 Developer 模式可将本地模型暴露为 OpenAI 兼容的 REST API 服务（默认端口 1234），内置参数调节（温度、Top-P、重复惩罚等）和对话历史管理等功能，在图形界面易用性与 API 开放性之间取得了良好平衡。这三者加上 Ollama，均对外提供 OpenAI 兼容 API（遵循 /v1/chat/completions 接口规范），因此可通过 CC Switch 统一接入——这也是整套方案通用性的根本来源。

推理框架选型指南：四种主流推理框架各有适用场景，理解其差异有助于做出更合理的技术选型。Ollama 最适合零配置快速上手，内置模型管理和自动服务化，适合个人日常使用；LM Studio 适合需要图形界面调参和模型管理的用户，开发者模式的 API 暴露功能使其兼顾易用性与可集成性；llama.cpp 则适合需要极致性能调优或嵌入到自定义程序中的高级用户，提供最底层的控制粒度；vLLM 专为生产环境多并发场景设计，若你的目标是在局域网内为团队多人同时提供服务，vLLM 是最优选择，但其配置复杂度和对 NVIDIA GPU 的依赖也最高。

第一步：在 LM Studio 中开启本地服务

先去 CC Switch 的 GitHub 页面，点击右侧 Release 区下载最新版并完成安装。

然后回到 LM Studio 进行两步设置：

打开后点击顶部的「Developer」图标，将左上角的 Server 开关打开；
点击「Load Model」加载提前下载好的本地模型。

提前下好的本地模型

加载完毕后，在右侧将**上下文长度（Context Length）**调大，再点击右下角的重载按钮使设置生效。

上下文长度与 KV Cache 的关系：上下文长度是指模型在单次推理中能够同时处理的最大 Token 数量。英文约每 4 个字符为 1 个 Token，中文约每 1.5~~2 个汉字为 1 个 Token。对于代码开发场景，较大的上下文窗口（如 32K~~128K Token）意味着模型可以一次性读入整个代码文件或完整的多轮对话历史。

从技术原理上看，上下文越长，模型需要缓存的 KV Cache（Key-Value Cache）就越大。KV Cache 是 Transformer 推理的核心优化机制：模型生成每个新 Token 时无需重新计算所有历史 Token 的注意力权重，而是从缓存中直接读取，极大提升推理速度。但这一机制的代价是显存占用随上下文长度线性增长——以7B参数模型为例，每增加1K Token 的上下文约消耗 0.5~1 GB 显存。因此，手动调大上下文长度时需确保剩余显存充足，否则可能出现显存溢出（OOM）导致崩溃。

实用建议：对于代码 Agent 场景，建议将上下文长度设置为显存允许范围内的最大值，但保留至少 2~4 GB 显存余量用于模型权重本身。一个实用的估算公式：可用上下文 Token 数 ≈（空闲显存 GB × 1024）/ 每千 Token 显存消耗(GB)。若出现崩溃，优先降低上下文长度而非更换模型。

第二步：在 CC Switch 中新建配置

打开 CC Switch，点击顶部的「OpenAI」标签，再点右上角的加号新建自定义配置。供应商名称和 API Key 随意填写即可，无需校验。

最关键的是 API 请求地址：将 LM Studio 的服务地址复制过来，手动补上 /v1 后缀，然后点击「获取模型列表」并添加模型。这里的 /v1 后缀是 OpenAI 兼容 API 的标准路径前缀，所有兼容该规范的本地服务都遵循此约定。

把模型名稱連貼到上面的默認模型一覽裡面

点击向下箭头选中刚加载的模型，将模型名称粘贴到默认模型栏，上下文长度与 LM Studio 保持一致（或留空），点击添加即完成配置。

第三步：切换并启用

回到 CC Switch 主页面，将模型切换至刚配置好的 LM Studio 方案，点击启动按钮。重启 ChatGPT 后，程序调用的就是基于 LM Studio 的本地大模型了。

通用逻辑：一套配置打通所有 AI 智能体

本教程最大的价值在于其通用性。无论使用 Ollama、LM Studio、llama.cpp 还是 vLLM，本地大模型的接入逻辑都是相同的：

让本地工具开放一个兼容 OpenAI 格式的 API 端口；
用 CC Switch 或原生方式将该端口配置到目标程序中；
切换模型并重启生效。

更重要的是，这套方法不只适用于 ChatGPT。Claude Code 是 Anthropic 推出的命令行代码智能体，能在终端环境中自主完成代码编写、调试和文件操作；OpenCode 则是社区开发的开源替代方案，同样兼容多种 LLM 后端。

这类「AI 编程智能体」工具代表了当前 AI 应用落地最活跃的方向之一。不同于单纯的代码补全，编程智能体具备「规划—执行—反思」的完整循环能力，其底层执行范式被称为 ReAct（Reasoning + Acting）——由 Google 研究团队于2022年提出。ReAct 将 LLM 的推理过程与外部工具调用交织在一起：模型先输出「思考」步骤（Thought），再输出「行动」指令（Action），等待环境返回「观察」结果（Observation），随后继续下一轮思考直至任务完成。这一循环使模型能够处理需要多步骤、多工具协作的复杂任务，例如先读取文件内容、分析错误、修改代码、执行测试、再根据测试结果迭代修复。

ReAct 框架解决的核心问题：ReAct 之所以有效，在于它解决了纯语言模型在复杂任务上的两个根本性缺陷——幻觉（Hallucination）和状态感知缺失。纯语言模型在面对多步骤任务时，往往会在推理链中途「凭空捏造」中间结果（即幻觉），因为模型无法获取任务执行的真实状态反馈。ReAct 通过强制模型与外部环境交互，使每一轮「观察」结果都为下一轮推理提供经过现实验证的锚点，将错误纠正机制内嵌于执行循环中，大幅降低长链任务的累积误差。在代码 Agent 场景中，这意味着模型写出代码后立即执行并观察报错信息，而非在纯文本推理中「预测」代码是否正确——后者几乎必然产生难以察觉的逻辑错误。

工具调用（Tool Use / Function Calling）的底层机制：工具调用是 LLM 从「对话助手」升级为「智能体」的关键技术。其原理是在系统提示中向模型声明可用工具的 JSON Schema（函数名称、参数类型、功能描述），模型推理时若判断需要调用某工具，会在响应中输出结构化的 JSON 调用指令而非纯文本，由宿主程序解析并实际执行，再将执行结果回注上下文，形成「思考—行动—观察」的 ReAct 循环。OpenAI 于 2023 年将 Function Calling 纳入 /v1/chat/completions 规范后，各推理框架相继跟进实现，这是编程智能体在本地部署后仍能保持读写文件、执行命令等完整能力的技术前提。

本地模型的 Function Calling 支持现状：并非所有本地模型都能可靠支持 Function Calling。工具调用要求模型在特定格式约束下输出结构化 JSON，对模型的指令遵循能力（Instruction Following）要求较高。在参数量较小（7B 以下）或未经专门微调的模型上，工具调用的成功率可能不稳定，表现为输出格式错误或无法正确解析工具名称。推荐优先选择经过专门 Function Calling 微调的模型版本（通常在模型名称中标注 instruct 或 fc 后缀），以获得更稳定的 Agent 体验。

这类工具的共同架构特征是：一个负责推理和规划的 LLM 核心，加上一套工具调用框架（Tool Use / Function Calling），对外统一通过 OpenAI 兼容 API 接受模型配置。这一设计使得本文的本地化方案可以无差别复用，实现整个 AI 开发工具链的完全本地化。

总结：本地大模型接入 ChatGPT 的核心思路

随着 OpenAI 将 Codex 整合进 ChatGPT 桌面端，本地模型接入比想象中简单许多。两条路径各有侧重：

新手首选 Ollama：安装即用，命令行一键拉起模型，底层基于 llama.cpp + GGUF 量化，门槛极低；
进阶用户选 CC Switch：灵活中转，兼容现有部署工具，无需重复配置。

核心思路始终围绕「OpenAI 兼容 API 端口 + 配置切换」这一模式展开——这一模式之所以有效，是因为 OpenAI API 格式已成为 LLM 服务领域的事实标准，各主流推理框架均原生支持。这一标准的形成具有深刻的生态意义：它降低了用户在不同工具之间迁移的成本，也倒逼各厂商和开源项目向兼容性方向收敛，最终受益的是整个开发者社区。类比来看，这与 USB 接口标准统一充电协议的效果如出一辙——当接口标准化后，设备（客户端）与电源（模型后端）可以自由组合，生态创新的速度也随之加快。

需要注意的是，本地模型的实际效果高度依赖硬件配置——显存大小直接决定可运行的参数量，上下文长度设置则影响 KV Cache 的显存占用与实际可用性。建议根据自身设备理性选择模型参数量，在使用体验与运行性能之间找到平衡点。

本地部署的隐私边界：除性能外，本地部署的另一核心价值是数据主权。当所有推理在本机完成时，对话内容、代码逻辑、业务数据均不离开本地网络，从根本上规避了云端服务可能存在的数据留存、训练利用或合规风险。对于处理敏感代码库、内部文档或个人隐私信息的场景，这一优势的价值往往超过性能本身的考量。