最近我把团队里那笔每月一百美元的商业AI套餐停掉了。说实话决定之前犹豫了很久毕竟过去半年大家已经习惯了拿它做问答、写摘要、解释代码突然要断掉最怕的是效率崩掉。后来我在技术社区看到有人在讨论dots体系——一套用开源工具把商业AI助手能力整个搬到本地的方案集合覆盖日常对话、知识库、自动化流程三块甚至连手机端和桌面端入口都给你准备好了。我花了两周时间把社区里讨论最多的三个实现全部跑了一遍最终选了一套跑在自己办公室的旧电脑上24小时常驻数据全部留在本机。这篇就来说说我的选型对比、部署实录以及那三个一键脚本到底怎么用。1. 每月一百美元到底花在哪平替凭什么敢说能打1.1 商业套餐的钱袋子里都有什么很多人以为商业AI助手就是一个聊天框其实不是。你把付费服务拆开看它至少由四个模块组成对话交互界面、高性能模型推理、知识库托管、多端同步与团队权限。再加上背后的工具调用、插件生态和模板流程才构成你每个月看到的完整体验。本地开源平替要做的就是把这四层全部找到对应的替代品并且用一套脚本把它们串起来。我用一个表格把这笔账拆清楚模块商业服务做了什么本地开源怎么对应对话界面即时聊天式交互多端同步开源对话前端浏览器直接访问模型推理云端大模型效果强但不可控本地推理后端加量化模型知识库上传文档后按需检索回答嵌入模型加向量库工具与自动化插件、定时任务、工作流Agent编排与脚本调度权限与同步团队账号、多设备一致统一入口加设备配置看完这张表你就明白所谓“平替”不是单纯把模型文件下下来而是要把整条链路都补上。商业套餐的价值在于它把这些模块都集成好了你花钱买的是省心而开源方案的逻辑是每个模块都有成熟工具只是需要你自己把它们拼起来。dots体系在社区里被叫成“全套平替”就是因为有人把拼装这件事做成了模板拉下来就能用。1.2 平替的真正价值不止是省钱省钱当然是最直观的每月一百美元乘以十二个月就是一千多美元这还不算按人头收费的团队套餐。但我在实际跑完以后发现更值钱的其实是另外三点。第一数据不出本机。所有对话记录、上传的知识库文档、检索日志全都在自己硬盘上。对很多小团队来说这一点比省几百美元重要得多特别是涉及内部技术资料和客户信息时外传风险直接归零。第二模型和界面都可以改。商业套餐给你什么模型你就用什么模型本地方案里换个模型文件就是改一行配置的事界面布局、提示词模板、工具调用逻辑全部能按自己习惯调整。第三断网也能用。办公现场网络抖一下、出差到信号差的地方本地服务照样跑不受任何远端状态影响。但也要说清楚门槛。平替不是白来的你需要付出三样东西一台长期开机的机器、一点维护精力、以及接受模型效果和顶级商业模型之间的差距。适合切换的人群是常用场景固定、对数据敏感、愿意花一个周末折腾的人。不适合的是追求最新最强模型、完全不想碰运维、以及重度依赖商业生态原生功能的人。我的看法是先明确自己是哪类人再动手别盲目跟风。2. 三大实现横评两周跑完所有方案后的真实结论2.1 同是开源平替路数完全不一样社区里说“dots体系”的时候其实涵盖了多个差异很大的项目。我挑了被讨论最多的三个实现分别用方案A、方案B、方案C来代表因为它们的定位从一开始就不同。方案A是一个轻量对话套件。它的思路是让所有人最快速度跑起来界面做得像聊天软件模型加载、会话管理、历史记录都内置好适合把日常问答入口替换掉。方案B走的是另一个方向它本身不做界面而是提供一套兼容商业API风格的接口。你原来写的桌面端工具、脚本、集成逻辑只需要把请求地址改到本地代码几乎不用动就能切换过来。方案C则是一体化工作台对话、知识库、自动化流程、团队权限全部装在一个包里适合小团队一步到位。这三个实现表面都是AI助手实际选型逻辑完全不同。我建议你在看横评结果前先问自己三个问题你是只想自己要个聊天界面还是有一堆现成代码要改造还是团队需要一套统一平台答案不同适合你的方案直接不同。2.2 横评表我从八个维度各跑了三天为了做对比我在同一台机器上把三个方案都部署了一遍每个方案连续用了三天。机器配置是8核CPU、32GB内存、没有独立GPU基本模拟了小团队办公室旧电脑的典型情况。部署耗时从拉取代码、下载模型到跑通第一轮对话计算资源占用取的是日常使用24小时后的平均值。维度方案A方案B方案C部署耗时约30分钟约1小时2小时以上内存占用1.5GB到2GB约1GB8GB起步对话体验界面好日常够用依赖后端模型综合体验最完整内置知识库无或靠插件无需外部搭配内置且效果好自动化扩展较弱强适合改造强流程编排完善二次开发难度中等低接口兼容中等适合人群个人快速上手开发者小团队一站式实际跑下来我的感受是方案A像是一辆好开的家用车上手就能走方案B更像一套乐高积木本身不起眼但它能和所有既有零件咬合方案C是精装房搬进去就能住但户型改起来费劲。没有绝对的优劣只有和你需求合不合。2.3 我最意外的三个细节第一方案A看起来最轻量但如果你后续想加知识库改造量反而大。它的对话模块和知识检索模块是松耦合的加装插件不算难可用起来总觉得像是两块东西硬拼在一起检索结果和对话上下文之间的衔接不如一体化方案顺滑。第二方案B的接口兼容做得很好但配置项实在太多。连接参数、模型映射、并发限制、超时策略散落在不同文件里新手很容易卡在某一个参数上。我在第二天就踩了一次连接超时排查半小时后发现只是超时阈值设小了。第三方案C全家桶体验确实最完整但升级要格外小心版本一致性。有一次我更新了前端组件结果发现后端接口版本不匹配登录页面都打不开最后不得不回滚备份。所以方案C我建议跑通后尽量不要频繁升级除非你已经做了完整备份。如果让我给建议我会这么说个人单机使用先跑方案A跑通对话再考虑加知识库手里有存量代码的开发者直接上方案B省掉改代码的麻烦小团队想省事就直接选方案C但控制住折腾的欲望。这个顺序能让你每一步都有回退空间。3. 本地24小时驻场实战从零部署到日常管理3.1 硬件和系统准备本地部署第一步不是敲命令而是把硬件和系统环境想清楚。我的主力机是办公室一台淘汰下来的品牌机配置不算高但跑这些开源组件绰绰有余。下面是我整理的配置参考你可以直接对照评估。项目最低配置推荐配置说明CPU4核8核推理和向量检索都吃CPU内存16GB32GB16GB能跑32GB才从容系统盘50GB200GB SSD系统、代码、日志分开数据盘50GB200GB SSD模型和向量库都放在这里GPU可选8GB显存没有GPU也能用只是回答慢一些没有GPU完全不用慌。我这次部署的机器就没有独显跑的是量化后的模型单用户日常提问大约两三秒出结果完全能接受。所谓量化简单说就是把模型里的参数精度降低一点换体积和内存占用的大幅下降效果损失在可接受范围内。系统层面建议直接装一个主流Linux发行版的64位版本我不在这里写具体发行版名称因为你用的是哪个发行版影响不大只要带桌面环境或者纯命令行都行后面全都走容器编排。3.2 容器编排一起拉起来我坚持用容器方式部署原因有三个隔离、可升级、好回滚。所有服务和依赖被打成一个独立运行单元系统怎么折腾都不影响宿主机升级时拉新镜像重启一下就行出了问题把旧版本容器重新拉起五分钟就能恢复。这在24小时常驻场景里非常重要。部署目录我放在/opt/ai-stack下所有配置和数据都集中在一个地方方便备份和迁移。先准备一个环境变量文件内容大概是这样的# .env # 镜像地址建议用你自己构建或核对过哈希的可信镜像源 IMAGE_UIyour-registry.example.com/chat-ui:latest IMAGE_LLMyour-registry.example.com/llm-service:latest IMAGE_VDByour-registry.example.com/vector-db:latest # 端口 UI_PORT8080 LLM_PORT8081 VDB_PORT8082 # 数据目录 DATA_DIR/opt/ai-stack/data MODEL_DIR/opt/ai-stack/models容器编排文件我做过精简核心就是把三个服务串起来# docker-compose.yml version: 3.8 services: chat-ui: image: ${IMAGE_UI} ports: - ${UI_PORT}:8080 environment: - LLM_BASE_URLhttp://llm:8081 - VDB_BASE_URLhttp://vdb:8082 volumes: - ./data:/app/data depends_on: - llm llm: image: ${IMAGE_LLM} ports: - ${LLM_PORT}:8081 volumes: - ${MODEL_DIR}:/models environment: - MODEL_PATH/models/chat.gguf - CONTEXT_LENGTH8192 vdb: image: ${IMAGE_VDB} ports: - ${VDB_PORT}:8082 volumes: - ./data/vectors:/data/vectors拉起服务的命令很简单三行搞定cd /opt/ai-stack docker compose up -d docker compose ps第一次启动会拉镜像耐心等几分钟。看到三个服务状态都是运行中之后打开浏览器访问http://本机IP:8080能看到对话界面就算部署成功了。如果页面打不开先检查系统防火墙有没有放行8080端口这是最常见的坑我后面会在问题排查里再讲。3.3 模型接入与知识库初始化对话界面起来只是第一步真正决定体验的是模型和知识库。模型文件我建议用量化好的GGUF格式这种格式把模型打包成了一个文件下载后放入/opt/ai-stack/models目录就行不需要自己装一堆依赖。量化等级里Q8效果最接近原版但体积大Q5是性能和体积比较均衡的日常选择Q4更省内存但效果会肉眼看出来差一点。以7B参数量的模型为例Q5文件大概4GB多16GB内存的机器可以跑得很顺畅。我在没有GPU的机器上用Q5日常对话体验已经足够写稿、改文案、做代码解释了。模型接入后下一步是把知识库跑起来。这部分很多人会忽略但恰恰是平替体验拉开差距的地方。知识库的工作逻辑是把上传的文档切片、用嵌入模型转成向量、存进向量数据库用户提问时再把问题转成向量在库里做相似度检索把最相关的片段拼进提示词交给大模型作答。# config.yaml model: path: /models/chat.gguf context_length: 8192 threads: 8 embedding: model: /models/embedding.bin dimension: 768 vector_store: path: /opt/ai-stack/data/vectors top_k: 5配置里context_length是上下文窗口长度设成8192意味着模型能一次看到约五六千字的上下文日常够用top_k是每次检索返回几个相关片段设成5就是取最相关的5段太多反而会引入噪音。初始化知识库时要跑一遍嵌入任务把准备上传的文档全部过一遍这一步耗时取决于文档量几百页的资料大约十几分钟。跑完以后在对话界面里上传一份PDF问一个里面才有的细节能答上来就说明链路通了。注意启动后先做一轮“预热提问”随便问个问题让模型加载进内存后面响应速度会明显变快。3.4 远程访问与日常运行部署在本机自己用当然没问题但要实现手机端和桌面端都能访问就得解决网络问题。最稳妥的起步方案是局域网访问只要手机和电脑连同一个路由器直接访问http://主机IP:8080就能用。为了让地址不经常变我给这台机器在路由器里设了固定内网IP省得每天查地址。如果你人在外面也想访问我建议优先用端口映射也就是在办公网络出口把某个公网端口映射到内网的8080端口。这个操作要小心除非你有把握做好访问控制否则不要直接把服务裸奔到公网。我的做法是开启强密码登录、关闭开放注册接口、限制访问来源IP并且只开放必要的端口。日常管理上给容器设置开机自启、把日志按天轮转、数据目录定期备份这三点做到位24小时常驻就不是负担。4. 三端一键全自动脚本部署、接入、备份全包4.1 脚本体系总览说完了部署接下来是这篇的重头戏三端一键脚本。我把它分成服务端、PC端、移动端三条线外加备份和更新两个辅助脚本。整个目录结构是这样的/opt/ai-stack/ ├── docker-compose.yml ├── .env ├── config.yaml ├── models/ ├── data/ └── scripts/ ├── install_server.sh ├── pc_client_sync.sh ├── mobile_link.sh ├── backup_rotate.sh └── update_check.sh脚本设计遵循一个原则交互尽量少、参数尽量集中在环境变量里、每跑一步都要输出明确的成功或失败信息。这样哪怕三个月后不用了再捡起来也能一眼看懂是干嘛的。下面我把最重要的三个脚本拆开讲。4.2 服务端一键部署脚本服务端脚本负责从零初始化整个环境包括检查基础命令、创建目录、生成环境变量文件、拉取容器编排文件、启动服务和健康检查。代码如下#!/usr/bin/env bash set -euo pipefail BASE_DIR/opt/ai-stack DATA_DIR${BASE_DIR}/data MODEL_DIR${BASE_DIR}/models UI_PORT${UI_PORT:-8080} echo [1/6] 检查基础依赖 for cmd in curl jq docker; do if ! command -v $cmd /dev/null 21; then echo 缺少命令 $cmd请先安装 exit 1 fi done echo [2/6] 创建目录结构 mkdir -p ${DATA_DIR}/vectors ${MODEL_DIR} ${BASE_DIR}/scripts echo [3/6] 准备环境变量 if [ ! -f ${BASE_DIR}/.env ]; then cat ${BASE_DIR}/.env EOF IMAGE_UI${IMAGE_UI:-example/chat-ui:latest} IMAGE_LLM${IMAGE_LLM:-example/llm-service:latest} IMAGE_VDB${IMAGE_VDB:-example/vector-db:latest} UI_PORT${UI_PORT} DATA_DIR${DATA_DIR} MODEL_DIR${MODEL_DIR} EOF fi echo [4/6] 写入容器编排文件 if [ ! -f ${BASE_DIR}/docker-compose.yml ]; then cat ${BASE_DIR}/docker-compose.yml YAML version: 3.8 services: chat-ui: image: ${IMAGE_UI} ... YAML fi echo [5/6] 启动服务 cd ${BASE_DIR} docker compose up -d echo [6/6] 健康检查 for i in $(seq 1 30); do if curl -sf http://127.0.0.1:${UI_PORT}/api/health; then echo 部署成功访问 http://本机IP:${UI_PORT} exit 0 fi sleep 5 done echo 健康检查超时请查看容器日志 docker compose logs --tail50 exit 1脚本里最关键的是健康检查循环最多等150秒服务起来但还没完成初始化时不会误报失败日志输出也能直接定位问题。另外我把镜像地址都放在环境变量里不在脚本里写死这样换机器部署时不用改脚本内容。执行方式很简单chmod x /opt/ai-stack/scripts/install_server.sh /opt/ai-stack/scripts/install_server.sh跑完看到“部署成功”四个字就可以进下一步了。我建议第一次跑的时候人守在终端前因为下载模型和镜像比较耗时心理预期按10分钟起步算。4.3 PC端接入脚本PC端脚本解决的是“怎么让桌面电脑快速接入本地服务”。方案B走接口兼容路线在桌面客户端里只需要改一个请求地址但我做脚本的时候还希望连令牌都能自动配好于是写了这样一个脚本#!/usr/bin/env bash set -euo pipefail # 从配置文件读取服务端地址和访问令牌 SERVER_URL${SERVER_URL:-http://192.168.1.100:8080} TOKEN_FILE/opt/ai-stack/data/client_token.txt CONFIG_DIR${HOME}/.config/ai-stack TOKEN if [ -f ${TOKEN_FILE} ]; then TOKEN$(cat ${TOKEN_FILE}) else echo 未找到令牌文件请先在服务端生成客户端令牌 exit 1 fi mkdir -p ${CONFIG_DIR} cat ${CONFIG_DIR}/client.yaml EOF server: ${SERVER_URL} token: ${TOKEN} timeout: 30 model: local EOF echo 已生成客户端配置${CONFIG_DIR}/client.yaml curl -sf ${SERVER_URL}/api/health /dev/null 21 \ echo 服务端连接正常 \ || echo 警告服务端暂时无法连接请检查网络令牌文件里的内容是一串随机字符在服务端通过一条命令生成。PC端接入后你原来用的那些客户端、脚本只要支持自定义请求地址都能直接指到本地服务上。我特别想强调一点电脑端不要折腾原生应用安装包很多时候使用终端工具反而更省事。4.4 移动端一键接入移动端听起来复杂其实最简单。手机浏览器访问那个地址后就可以用“添加到主屏幕”功能把页面变成一个独立图标使用体验和原生App非常接近本质是PWA方式不需要装额外软件。我的mobile_link.sh脚本做的事情就是在服务端生成一个带配置参数的短链接用二维码工具打印出来手机扫一扫自动填入服务器地址和令牌。#!/usr/bin/env bash set -euo pipefail SERVER_IP$(hostname -I | awk {print $1}) UI_PORT${UI_PORT:-8080} TOKEN$(cat /opt/ai-stack/data/client_token.txt) # 生成带参数链接 LINKhttp://${SERVER_IP}:${UI_PORT}/m?token${TOKEN} echo 手机端访问链接${LINK} echo 请用任意二维码工具将以上链接生成二维码实际使用中我会把这个链接复制到在线二维码生成页里生成一张二维码图片贴到办公室显示器旁边。手机扫一扫浏览器打开再添加到主屏幕以后点图标就是本地AI助手。令牌要保管好它等同于你访问服务的钥匙发到群里被其他人拿到是个隐患。移动端不做原生App是我尝试之后觉得最不折腾的方案更新和配置都在服务端手机端永远是零维护。4.5 定时更新与备份24小时常驻服务最怕的不是慢而是升级出问题后找不到恢复点。所以我单独写了备份和更新脚本并用系统定时任务管理它们。定时任务配置0 4 * * * /opt/ai-stack/scripts/backup_rotate.sh 0 3 * * 1 /opt/ai-stack/scripts/update_check.sh备份脚本的核心逻辑是先停数据相关服务压缩数据目录按日期命名备份文件只保留最近7个备份。更新脚本的逻辑则是拉取最新镜像清单和当前运行版本对比发现有新版本时只输出提示不自动重启。为什么要提示而不是自动升级因为我在方案C上吃过亏版本不同步导致的兼容问题比想象中多。自动备份加手动确认升级这个组合我用下来最安心。5. 翻车现场部署与使用中的高频问题5.1 常见问题速查表跑了两周我前前后后遇到七八个问题有些是配置疏忽有些是版本兼容还有纯粹是环境差异。整理成速查表方便你对照排查症状可能原因排查方法解决办法页面打不开端口没放行curl 127.0.0.1:8080放行防火墙端口首次对话极慢模型量化等级太高查看内存占用换Q5或Q4量化知识库检索结果为空文档还没完成嵌入看索引任务日志重新跑嵌入流程容器反复重启数据目录权限不对看容器日志修正目录属主手机端访问不了主机内网IP变化查当前IP路由器设置固定IP登录后提示令牌失效令牌文件权限被改检查文件内容重新生成客户端令牌升级后前端连不上后端版本不一致查看前后端接口版本回滚备份或统一升级这里面的共性规律是大部分问题不是代码有问题而是环境细节没对齐。路径、端口、权限、版本这四个词几乎覆盖了所有翻车现场。你在排查时不要急着改动配置先看日志日志里通常会直接告诉你答案。5.2 资源占用与性能调优没有GPU的环境下资源优化直接决定了体验。我第一次把上下文窗口设到16384结果内存直接不够用服务频繁重启。后来我把上下文调回8192内存占用立刻降了三分之一日常使用几乎感觉不到变笨。几个实用调优点模型线程数根据物理核心数设置8核机器设成8不是越大越好。上下文窗口按实际需求量设置不要盲目拉满。向量库的检索结果数量top_k默认5就够设太大会让回答变得啰嗦。模型文件放在SSD上机械硬盘加载时间会明显拖慢首轮响应。日志如果膨胀可以用按天轮转的方式控制避免把数据盘塞满。有GPU的机器尽量把模型放到显存CPU会释放出来处理其他任务。还有一个容易被忽略的点部署完成后一定要做一次预热让模型先加载到内存里否则真到用的时候第一句话要多等十几秒。5.3 我踩过的坑和独家建议最后说几条用真金白银换来的经验。第一条默认密码和权限要在第一天就改完。某一次我图省事部署完直接用了系统默认的管理员账号结果没两天日志里出现一堆异常登录尝试幸好服务只在局域网内不然后果不堪设想。第二条数据目录千万别默认放在系统盘根目录。我一开始把模型和向量库放在系统盘默认路径后来升级系统时差点被格式化亏得提前做了软链。第三条升级前一定要先跑备份升级后一定要做一次健康检查。这句话我重复很多次了因为它是所有坑里性价比最高的一条习惯。第四条移动端老老实实用浏览器主屏入口就够了别花时间做原生App一个是维护成本高另一个是你的需求根本没到那一步。我现在每天上班打开浏览器点一下收藏夹里的本地地址就能完成过去要依赖商业套餐的所有日常操作。模型可以随时换知识库可以随时加日志全在我手里这种感觉确实比付费服务踏实。如果你也想从零跑一套我的建议是别一开始就追求全家桶先拿轻量方案跑通对话再逐步加知识库和自动化每一步都能回滚永远不要把自己逼到没有退路。这大概就是开源平替最实在的价值钱省下来了掌控感提上去了而且还多了一整条可以反复折腾的技术栈。