在低内存VPS上部署Open WebUI，内存压力主要来自三部分：后端模型服务、RAG/Embedding相关进程、以及每次请求携带的历史上下文。关闭Embedding功能和限制历史消息数量，都是在模型服务之外削减常驻内存和请求内存开销。如果VPS内存已经低到连模型本身都加载不了，这两项配置不能救场，需要先更换更小的模型或量化版本。
在低内存VPS上，Open WebUI 可以按「关闭RAG/Embedding + 限制历史消息长度 + 设置容器内存上限」组合调整。最快路径是在UI里关掉文档问答，并把聊天历史长度调到3-6轮；接管服务的Docker容器再加mem_limit限制。这套操作能降低持续内存占用，但不会缩小模型文件体积；需要在浏览器里观察UI响应和docker stats确认效果。
为什么这两项配置最直接
Open WebUI 本身只提供网页界面和API转发，真正的内存大头来自后端推理服务。但 Embedding 功能会额外加载一个文本向量化模型，并在上传文档时持续驻留；历史消息则决定每次聊天请求携带多少上下文，消息越长，请求体越大，后端需要更长时间处理，内存占用也随之上升。
所以关闭 Embedding 能直接移掉一个常驻模块；限制历史消息则能把单次请求的上下文控制在固定范围。这两项操作都不改动模型权重，适合在低内存机器上优先尝试。
关闭Embedding功能
如果你只用Open WebUI做普通聊天，不需要上传PDF、Word等文档然后提问，可以直接关闭RAG/Embedding。在Open WebUI的管理面板或设置页面中，找到“文档检索”、“RAG”或“Embedding”相关区域，关闭“启用文档问答”或类似开关，并清空Embedding模型配置。保存后刷新页面，通常不会再出现“上传文档并提问”的入口。
如果通过docker-compose部署，也可以尝试用环境变量覆盖，例如下面这个片段：
services:
open-webui:
image: ghcr.io/open-webui/open-webui:main
ports:
- "3000:8080"
volumes:
- ./data:/app/backend/data
environment:
- ENABLE_RAG=false
- RAG_EMBEDDING_ENGINE=off
mem_limit: 1g
restart: unless-stopped注意：不同版本Open WebUI对环境变量的支持并不相同。上述变量名是常见写法，但不保证每个镜像生效。建议先进入容器执行 env | grep -i rag，能看到容器实际加载了哪些RAG相关变量，再按其中的变量名修改。
限制历史消息数量
历史消息数量的设置入口一般不在环境变量里，而是登录Open WebUI后，进入用户设置（头像菜单）的“聊天”或“对话”选项卡。找到“历史消息长度”、“上下文消息数量”或类似的输入框，把数字从默认的较大值调整到6以内。保守一点可以先设为4到6轮，既能保持多轮对话的基础记忆，又不会让请求体越来越大。
部分镜像也支持通过环境变量限制，例如 CONTEXT_HISTORY_LENGTH，但同样需要以实际镜像为准。可以用下面的方式排查：
docker exec -it open-webui env | grep -i context如果找不到相关变量，就直接在UI里设置。UI里的设置会持久化到后端数据库中，不需要每次启动都改。
验证调整是否生效
启动Open WebUI后，在VPS上执行 docker stats，观察容器的MEM USAGE列。确认内存没有持续上涨。如果关闭Embedding后，仍然能看到额外的embedding进程，说明关闭可能没生效，需要回到UI检查是否仍有文档上传入口。
限制历史消息后，进入一个多轮对话，发送一条消息，观察请求响应时间和内存曲线的变化。通常消息轮数超过设定值后，模型只会根据最近几轮回复，但UI中不会直接显示截断，需要你自己感知对话上下文是否被“遗忘”。
边界与注意事项
关闭Embedding后，文件上传和基于文档的问答会不可用；如果你的使用场景必须包含PDF或知识库问答，就不能简单关闭。限制历史消息则会在多轮对话中截断上下文，可能让模型忘记更早的信息，所以不能把数值压到1，否则对话体验会很差。
另外，容器内设置 mem_limit 后，如果内存不足，Open WebUI进程会被OOM Killer杀掉。建议根据VPS总内存减去系统占用后，给容器留一个合理上限，不要设置过小。比如1GB内存的VPS，容器限制到768MB，再观察稳定性。
最后，这类配置调整不改变后端模型本身的加载。如果模型权重超过VPS内存，仍然需要换更小的模型或使用量化版本。