如果你已经在用自建 API，但每次测试都要手写一段请求代码，那确实有点低效。Open WebUI 是一个可以自己部署的聊天界面，装好之后你就有了一套私有的 AI 工作台：对话、多模型切换、上传文档、保存历史，全都在自己的服务器上。这篇讲清从部署到接入的完整流程。
它解决的是什么问题
最直接的价值是把「调 API」变成「用产品」。你不需要再为每个模型单独写调用脚本，也不用把 API Key 散落在各个工具里。一个界面接一个地址，所有模型都在同一个下拉框里，切换只改一个名字。
第二个价值是私有。对话记录、上传的资料、提示词模板都留在你自己的机器上，不会同步到第三方平台。对处理内部文档或者客户资料的人来说，这一点往往比功能本身更重要。
第三个价值是可扩展。它支持接入自定义的 OpenAI 兼容接口，也就是说任何遵循这套协议的服务都能挂上去。你自建的网关、中转服务、本地跑的模型，都能统一到同一个界面里管理。
判断标准很简单：如果你已经有一套自己的 API，且不想把对话数据放在别人的平台上，那这个方案就适合你。
部署：一条命令的事
最省事的方式是用容器跑。准备好一台能联网的机器，把官方镜像拉下来，把它的 8080 端口映射到你想要的端口，再挂一个数据卷用来持久化对话记录，启动即可。整个过程不需要装其他依赖。
第一次访问会要求你注册一个管理员账号，这个账号是本地账号，只存在你自己的数据库里。注册完成后进入设置页，找到「连接」相关的配置区域，把接口地址填进去——这里是整个流程的关键点。
接口地址填写 https://api.aigcbreeze.cn/v1，注意结尾的 /v1 不能省，也不要多写一层路径。填错地址的典型表现是保存时报连接失败，或者在模型列表里什么都拉不出来。
填完地址和密钥后，点一下拉取模型列表。如果配置正确，下拉框里会直接出现可用的模型名。这一步成功了，后面基本就没有障碍了。
三个最容易卡住的地方
第一个是地址写错。常见错误是只填了域名没带 /v1，或者把接口地址和网页控制台的地址搞混。这两者是不同的入口，控制台是用来充值和管理密钥的，接口地址才是程序要连的地方。
第二个是容器之间互相访问不到。如果你把界面和网关都跑在容器里，填 localhost 是不通的，因为容器里的 localhost 指的是容器自己。这种情况下要么用宿主机的内网地址，要么让两个容器加入同一个网络，用容器名互访。
第三个是把管理权限当成普通功能开放。首次注册的账号是管理员，拥有查看所有对话和修改系统配置的权限。如果打算给团队用，务必先把注册关掉或者改成邀请制，再分享访问地址，否则任何人都能注册成管理员。
还有一个细节值得提前配：把默认模型设成你日常用得最多的那个。否则新人进来第一个动作往往是对着一个不合适的模型问问题，然后得出「这个工具不好用」的结论。
常见问题
需要什么配置的机器？
它本身只是一个界面层，不做模型推理，所以对机器要求不高。1 核 2G 的小机器就能跑起来，主要占用取决于你上传了多少文档。真正消耗算力的是背后的模型服务，那些在别人的机器上跑。
对话记录存在哪里？
存在你挂载的数据卷里，也就是你自己的磁盘上。这意味着删掉容器不会丢数据，但反过来也要注意：这个数据卷需要你定期备份，它不会自动同步到任何云端。
能不能多个人一起用？
可以，它自带多用户体系，每个账号的对话记录互相隔离。给团队用的话，建议给每个人单独开账号，而不是共用一个，这样既能分清记录，也方便在出现异常用量时定位到人。