很多开发者在接触大模型时第一反应往往是调用云端 API。确实开箱即用的服务能让人快速验证想法但随着项目深入数据隐私、响应延迟以及长期调用的成本问题逐渐浮出水面。当你需要将敏感的业务数据喂给模型或者希望在断网环境下也能稳定运行智能助手时本地部署就成了绕不开的选项。这不仅仅是为了“拥有”一个模型更是为了获得对算力、数据和业务逻辑的完全掌控权。然而本地部署听起来很美好实际操作中却容易让人望而却步。硬件门槛高不高显存够不够用开源模型的效果能否媲美商业版这些问题常常让初学者在门口徘徊。其实现在的开源生态已经非常成熟消费级显卡配合优化的推理框架完全能够跑起性能不错的 7B 甚至 14B 参数量的模型。关键在于如何避开那些不必要的坑用最朴素的方案先跑通流程再考虑优化。这篇文章不会堆砌晦涩的理论也不会推荐昂贵的企业级方案。我们将聚焦于普通开发者最关心的实际问题如何在自己的电脑或家用服务器上搭建一套真正可用、可控的大模型环境。无论你是想构建内部知识库还是单纯想体验私有化部署的乐趣接下来的内容都将提供一条清晰、可落地的路径。我们将从成本真相聊起一步步拆解架构选型直到你亲手敲下命令看到模型吐出第一个字。一、为什么要在本地部署大模型选择本地部署核心驱动力通常来自三个方面数据安全、定制化需求和学习研究。首先是数据主权。在使用公有云 API 时无论服务商的承诺多么可靠数据终究要离开你的内网。对于金融、医疗、法律等敏感行业或者涉及公司核心代码库的场景将数据上传到第三方服务器存在合规风险。本地部署意味着数据永远留在本地硬盘和内存中从物理层面上杜绝了泄露隐患。其次是定制化的自由度。云端模型通常是通用的“万金油”难以针对特定领域的术语或业务逻辑进行深度微调。而在本地你可以随意更换基座模型尝试不同的量化版本甚至利用 LoRA 等技术加载专属的微调权重。这种灵活性让模型真正变成了为你量身打造的工具而不是一个黑盒服务。最后是学习研究。这也是我本次尝试本地搭建的主要原因作为20多年的IT从业者希望通过从环境搭建、使用、完善的过程进一步了解大模型技术栈涉及的组件、功能和应用。二、其实也不是全免费很多人被“开源免费”的口号吸引认为本地部署就是零成本。这是一个常见的误区。虽然模型权重文件本身大多遵循开源协议可以免费下载但为了让它们跑起来隐性成本不容忽视。最大的成本在于硬件投入特别是当前内存价格飙升的环境下硬件投入细算下来也是一笔不小的投入。大模型对显存VRAM有着极高的要求。一般来说运行一个 7B 参数的模型如果是半精度FP16至少需要 14GB 显存即使经过 4-bit 量化压缩也需要 6GB 以上的显存才能流畅运行。如果你想尝试 13B 或更大参数的模型或者希望支持更长的上下文窗口消费级显卡往往捉襟见肘可能需要多卡互联甚至上专业卡。这意味着你可能需要升级显卡、增加内存条甚至更换电源和散热系统。其次是电力与维护成本。高性能显卡在全速推理时功耗惊人长时间运行带来的电费支出是一笔不小的开销。此外本地部署需要自己维护环境依赖、处理驱动冲突、监控温度与负载这些时间成本也是隐形的投入。最后是机会成本。本地算力是有限的当你把显卡用于跑大模型时它就无法同时用于渲染、游戏或其他计算任务。因此在决定部署前务必根据自己的实际需求和预算算好这笔账避免盲目跟风导致设备闲置或性能瓶颈。接下来介绍一下本次搭建的可用资源一、Windows PC24年10月购入配件自装10000左右OSWindows 11 专业版CPUIntel Core i5-14600KF 核心数146P8E线程数2012P8EGPUNVIDIA GeForce RTX 4070MemoryDDR5 32G16G*2 6800MHz二、Mac mini2020购入4000左右OSTahoe 26.5.2CPU/GPUM1Memory16G三、先来实现最最朴素的需求在追求高性能、高并发之前我们首先要达成的目标是“跑通”。最朴素的需求非常简单在本地终端能打开一个类似ChatGPT的对话框输入一段提示词模型能在一分钟内给出合理的回复。不要小看这一步它能帮你验证硬件兼容性、环境配置是否正确并建立对模型行为的直观感受。再结合目前可用的硬件资源总结一下本次搭建需要实现的能力需求全本地化、开源、免费满足日常问答、编码辅助局域网内多终端可使用拥有类似ChatGPT的UI、支持多模型切换/扩展支持降级服务主要是为了省电支持未来的联网、Agent、RAG等扩展四、组件选型和搭建架构要实现上述目标我们需要选择合适的软件栈。目前的开源社区中有几个主流且成熟的方案可供选择。当然关于组件选型需要结合可用资源和应用目标过程还有点复杂后面有机会单开一篇细说这里就直接先上选完的架构图吧模型层这是核心引擎负责加载模型并执行计算。Ollama目前最推荐的入门方案。它将模型管理、API 服务和命令行工具打包在一起安装极其简单支持自动下载模型对新手非常友好。qwen3.5:9b-q4_K_M9.7BQ4_K_M权重仅 ~6.6GB4070 12G → 纯 GPU 轻松装下还能开 32k ctx带 vision thinking和 27B 同架构能力是 27B 的蒸馏/小版预期速度 ~60-80 tok/s用于日常对话qwen2.5-coder:14b显存占用~12GB刚好适配4070用于编码完整项目生成、重构qwen2.5-coder:7b~6-8G统一内存考虑到Mac mini作为7*24运行环境还需要部署其他组件故需预留内存它用用于代码解释、单文件生成在windows关机省电状态下也能完成简单任务网关层统一网关负责多模型接入、路由、降级LiteLLM统一API暴露对外统一暴露成OpenAI格式的API多平台无缝切换支持无缝切换本地Ollama、云端Gemini等路由策略可自定义路由策略支持按复杂度自动分流降级支持模型、平台级的fail overSafetensorsHugging Face 原生格式安全性高加载速度快但通常需要较大的显存支持。前端层ChatGPT式的交互式前端Open WebUI类ChatGPT的聊天见面支持多用户账号体系支持连Ollama或任意OpenAI-compatible后端内置RAG支持联网搜索支持多模态支持对话中模型切换推荐架构对于大多数个人开发者最稳健的初始架构是Ollama模型 LiteLLM网关 Open WebUI前端。这种组合既保留了命令行的灵活性又提供了友好的交互界面且资源占用相对可控。数据流向也很清晰用户请求 - Open WebUI - LiteLLM网关 - Ollama API - 模型推理 - 返回结果。五、巨详细的搭建过程下面我们开始搭建本地大模型环境。Windows上只需要部署两个模型故我们先来搞定Windows1. 安装 Ollamawindows上安装Ollama非常简单就和你装微信一下到官网下载安装包直接双击一步步安装即可附上下载地址https://ollama.com/download/windows安装完成后Ollama会自动以后台服务形式运行。你可以通过一下命令在CMD窗口检查状态ollama--version如果输出了版本号说明安装成功。打开 http://localhost:11434页面显示 Ollama is running就稳了2. 下载并运行模型Ollama 内置了模型库可以直接拉取常用的开源模型。我们要运行的是 qwen2.5-coder 的14B版本和qwen3.5的9B量化版本在终端输入ollama pull qwen2.5-coder:14b ollama pull qwen3.5:9b-q4_K_M首次执行时Ollama 会自动下载模型文件。下载速度取决于你的网络状况。下载完成后你会直接进入交互模式。如果要验证两个模型是否已完成下载可在CMD执行以下命令看看显示的模型清单中是否有存在。ollama list3. 测试对话现在你可以直接在光标后输入问题。例如 请用 Python 写一个快速排序算法并解释其原理。稍等片刻根据硬件性能首字延迟可能在 1-5 秒之间模型便会开始生成代码和解释。快速排序是一种高效的分治算法... def quick_sort(arr): if len(arr) 1: return arr pivot arr[len(arr) // 2] left [x for x in arr if x pivot] middle [x for x in arr if x pivot] right [x for x in arr if x pivot] return quick_sort(left) middle quick_sort(right) ...如果你看到了类似的输出恭喜你最核心的步骤已经完成4. 网络设置按照架构需要将Windows上的ollama下挂到Mac mini的LiteLLM下故需要将windows上部署的Ollama提供的模型服务开放至局域网第一步网络配置1、Win R​ → 输入 sysdm.cpl→ 回车 2、切到 “高级”​ 选项卡 3、点击 “环境变量” 4、在 “用户变量”上半区→ “新建” 5、填写 - 变量名OLLAMA_HOST - 变量值0.0.0.0 6、一路 确定 7、重启 Ollama - 右下角托盘 → 右键羊驼图标 → Quit - 开始菜单重新打开 Ollama第二步防火墙放行需要管理员模式执行netsh advfirewall firewall add rule nameOllama 11434dirin actionallow protocolTCP localport114345. 其他设置及常用命令Qwen2.5-Coder-14B 原生支持 128K 上下文没错但我们在coder-14b可用的情况下qwen3.5:9b也是可用的状态故以9b模型为主故coder-14b我们设置ctx为8192但这个配置如果设置成全局会同时限制9B的上下文长度。如果后续你要给9B喂长文档/RAG可以单独给9B建个Modelfile自定义上下文长度所以我们为Qwen2.5-Coder-14b和qwen3.5:9b各自建立独立的Modelfile文件配置对应参数新建Modelfile文件# 模型 FROM qwen2.5-coder:14b # 限制上下文窗口保护 4070 的 12G 显存 PARAMETER num_ctx 8192 # 【优化】强制全量 GPU 推理防止 Ollama 抽风把一部分层放到内存里 PARAMETER num_gpu 99 # 【可选】定制系统提示词让它更专注于代码工程 SYSTEM 你是资深 Python 开发专家。请严格遵循 PEP8 规范。 在生成代码时必须包含必要的注释、错误处理和类型提示。 如果涉及文件结构请明确标注文件名。 新建Modelfile-qwen3.5-9b文件# 模型 FROM qwen3.5:9b-q4_K_M # 按需设最高262144不用全局改环境变量 PARAMETER num_ctx 131072 # 【优化】强制全量 GPU 推理防止 Ollama 抽风把一部分层放到内存里 PARAMETER num_gpu 99应用num_ctx、num_gpu参数此处create后的名字要记住后面配置LiteLLM时候要用到ollama create qwen2.5-coder:14b-f Modelfile ollama run qwen2.5-coder:14b ollama create qwen3.5-long-f Modelfile-qwen3.5-9b ollama run qwen3.5-long确认14b模型 num_ctx 8192确认9b模型num_ctx 131072ollama show qwen2.5-coder:14b ollama show qwen3.5:9b-long实时监控GPU和显存使用情况nvidia-smi--query-gpumemory.used,memory.total--formatcsv-l 1至此, Windows上的部署已经全部完成可通过以下方式最终确认在Mac mini上浏览器打开 http://10.25.1.58:11434页面显示 Ollama is running就稳了接下来开始Mac mini上相关组件的部署Mac mini上需要部署的组件较多我们按照以下顺序来进行Ollama - pull model - LiteLLM - OpenWeb UI1. 安装 Ollama和windows一样前往Ollama官网下载Mac OS安装包dmg文件和Mac上的其他软件一样安装即可。2. 下载并运行模型在终端窗口执行如下命令ollama pull qwen2.5-coder:7b配置Mac 上的模型参数虽然 Mac 内存大但为了和 Windows 端保持一致的行为防止 Agent 混乱我们也把 Context 限制在 8192。创建 Modelfile在终端执行catModelfileEOF FROM qwen2.5-coder:7b # 限制上下文为 8K保证长时间运行不卡顿 PARAMETER num_ctx 8192 # M系列芯片专用设置 GPU 层数16G内存很充裕可以设高点 PARAMETER num_gpu 99 SYSTEM 你是资深 Python 开发专家。请严格遵循 PEP8 规范。 在生成代码时必须包含必要的注释、错误处理和类型提示。 EOF应用参数构建自定义模型ollama create qwen2.5-coder:7b-8k-fModelfile启用模型ollama run qwen2.5-coder:7b-8k--verbose输入测试指令跑一下试试用 Python 写一个读取 CSV 文件的脚本确保 Mac 的 Ollama 也能被局域网访问编辑你的 shell 配置文件如果你用的是默认的 zsh就编辑 ~/.zshrcechoexport OLLAMA_HOST0.0.0.0~/.zshrcsource~/.zshrc重启 Ollama 服务点击顶部菜单栏的羊驼图标 - Quit Ollama。然后重新打开 Ollama。验证在 Mac 终端输入curlhttp://10.25.1.71:11434看到 Ollama is running即成功。3. 安装 LiteLLM因为我们需要用LiteLLM来做模型的路由和Fail over所以需要 proxy 网关功能带 Web UI、路由、fallback# 补装 proxy 完整依赖如果之前只装了 litellm 基础包pipinstalllitellm[proxy]# 验版本python-cimport litellm; print(LiteLLM 版本:, litellm.__version__)# 验命令whichlitellm litellm--help|head-5配置路由和主备策略在你 Mac 上找个目录创建 config.yamlgeneral_settings:# xxxx部分请自行设置一个密钥串这个后面需要配置到OpenWeb UI的配置中master_key:sk-litellm-local-xxxxxxxxxxxxmodel_list:# Windows 9Bvision thinking 轻量档# 这个model_name最终会显示在OpenWeb UI的界面上-model_name:local-coder-visionlitellm_params:# 这里的model需要和前面用ollama create xxx -f Modelfile构建的名字保持一致即xxx部分model:ollama_chat/qwen3.5:9b-longapi_base:http://10.25.1.58:11434timeout:30num_retries:1model_info:order:0# 主节点Windows 14B主力编码-model_name:local-coderlitellm_params:# 这里的model需要和前面用ollama create xxx -f Modelfile构建的名字保持一致即xxx部分model:ollama_chat/qwen2.5-coder:14bapi_base:http://10.25.1.58:11434timeout:30num_retries:1model_info:order:1# 备节点Mac 7B自动 fallback-model_name:local-coderlitellm_params:# 这里的model需要和前面用ollama create xxx -f Modelfile构建的名字保持一致即xxx部分model:ollama_chat/qwen2.5-coder:7bapi_base:http://10.25.1.71:11434timeout:30num_retries:1model_info:order:2router_settings:fallbacks:-local-coder:-local-codertimeout:30num_retries:1allowed_fails:2cooldown_time:30litellm_settings:drop_params:trueset_verbose:falselog_level:WARNING一些说明- order只对「同 model_name」的部署生效你现在的拆分是对的 model_info.order的作用是同一个model_name下的多个部署数字越小优先级越高。 - 给 9B 单独设了 model_name:local-coder-vision和另外两个用于编码的模型使用 local-coder完全解耦。 - fallback逻辑只作用于同名为local-coder的两个模型部署优先走 order:1的 Windows 14B14B 挂了之后自动 fallback 到order:2的 Mac 7B和独立的local-coder-vision节点完全没有交集不会出现「选9B当编码主力」或者「9B被误当成备用节点」的问题。给 Mac 的 4000 端口也提前放行LiteLLM 要用# 启动 LiteLLM 网关litellm--configconfig.yaml--port4000--host0.0.0.0--detailed_debug# 想放后台运行加 nohupnohuplitellm--configconfig.yaml--port4000--host0.0.0.0litellm.log21# Mac 防火墙放行如果开了防火墙sudopfctl-d# 临时禁用测试完再开或者把 LiteLLM 加入允许列表4. 安装 OpenWeb UI前置条件Mac 上要有 DockerOpenWebUI 官方只给 Docker 镜像没原生 macOS 安装包。先安装docker推荐轻量级方案Colima Docker CLIM1 友好brewinstallcolimadockerdocker-composecolima startColima 在 M1 16G 上比 Docker Desktop 省内存不少长期开的话更舒服。新建docker配置文件docker-compose.yml和 LiteLLM 的 config 同目录好管理version:3.8services:openwebui:image:ghcr.io/open-webui/open-webui:maincontainer_name:openwebuiports:# 默认是3000:8080,但我mac上的3000端口被gitea占用故改用3001-3001:8080volumes:-openwebui-data:/app/backend/dataenvironment:# 关键指向 LiteLLM 的 APIMac 上 Docker 访问宿主机用 host.docker.internal-OPENAI_API_BASE_URLhttp://host.docker.internal:4000/v1# 用你 LiteLLM 的 Master Key-OPENAI_API_KEYsk-litellm-local-xxxxxxxx# 不启用 OpenWebUI 自带的 Ollama我们用 LiteLLM 管双机-ENABLE_OLLAMA_APIfalse# 本地用可以关认证省得还要注册账号要账号的话改 true-WEBUI_AUTHfalse# 允许跨域后面手机/iPad 访问用得上-CORS_ALLOW_ORIGIN*extra_hosts:-host.docker.internal:host-gatewayrestart:unless-stoppedvolumes:openwebui-data:几个关键点解释host.docker.internal:4000→ Docker 容器里访问 Mac 宿主机上的 LiteLLM4000 端口OPENAI_API_KEY填你 LiteLLM 的 LITELLM_MASTER_KEY和 curl 用的那个一样ENABLE_OLLAMA_APIfalse→ OpenWebUI 别自己管 Ollama统一走 LiteLLM 主备WEBUI_AUTHfalse→ 本地单用户场景不用注册打开就能用要账号的话改 true首次打开会让你建管理员启动cd~/local_llm_gatewaydockercompose up-d首次会拉镜像约 200-400MB取决于版本之后启动 2-3 秒完事。确认跑起来dockerps|grepopenwebui看到 openwebui容器 Up就 OK。访问 第一次配置浏览器打开http://10.25.1.71:3000 如果 WEBUI_AUTHfalse直接进主页如果 true首次会让你建管理员账号随便填个邮箱密码本地用无所谓。 确认连上 LiteLLM 主备 顶部模型下拉 → 应该能看到 local-coder来自 LiteLLM 的 /v1/models 选 local-coder发一句 print(123) 看 Mac 上 LiteLLM 的日志 ✅ 显示 http://10.25.1.58:11434→ Windows 14B 主力 关 Windows Ollama 再发 → 显示 http://10.25.1.71:11434→ Mac 7B 备用 和之前 curl 验证的逻辑完全一致只是换成了网页界面。5. 全流程验证Mac资源统一内存占用情况1LiteLLM ~50-100MB 2OpenWebUIDocker~200-400MB 3Mac 本地 Ollama 7B 待机 ~5-6GB M1 16G 开 LiteLLM OpenWebUI Mac 7B 待机还剩不少余量完全没问题。14B 推理和9B通用都在 Windows 上Mac 这边只跑备用 路由 WebUI。验证三步走确认配置生效1、验证14B主力OpenWebUI选local-coder发写个快排LiteLLM日志应走10.25.1.58:11434 qwen2.5-coder:14b。 2、验证9B独立节点选local-coder-vision发解释QKV注意力日志应走qwen3.5:9b-q4_K_M。 3、验证fallback关Windows Ollama再选local-coder发请求日志应切到10.25.1.71:11434 qwen2.5-coder:7b。六、坑与总结在实际操作过程中有几个常见的“坑”需要提前规避。首先是显存溢出OOM。这是最常见的问题。如果模型太大而显存不足程序会直接崩溃。解决方法是选择更低精度的量化版本如从 Q4_K_M 降到 Q3_K_S或者减小上下文窗口长度context window。在 Ollama 中可以通过创建 Modelfile 来调整这些参数。其次是生成速度过慢。如果发现模型像“挤牙膏”一样吐字可能是 CPU 负担过重或 GPU 未被正确调用。检查任务管理器或nvidia-smi确认 GPU 利用率是否上升。如果没有可能需要检查驱动版本或重新安装带有 CUDA 支持的推理后端。最后是模型幻觉与准确性。本地部署的小参数模型如 7B/8B在复杂逻辑推理上可能不如超大模型。不要指望它能解决所有数学难题或编写完美的大型系统架构。合理设定预期将其定位为“辅助助手”而非“全能专家”并通过 Prompt 工程引导其输出往往能获得更好的效果。总的来说本地部署大模型已经从“极客玩具”变成了“实用工具”。虽然硬件成本和调试难度依然存在但随着软硬件生态的完善门槛正在迅速降低。当你亲手搭建起这套系统看着数据在本地闭环流动那种掌控感和安全感是云端服务无法给予的。不妨现在就打开终端迈出第一步让你的电脑真正“聪明”起来。