不写代码也能跑 AI：Flowise 自托管 + Ollama 搭建 RAG 机器人实测

2026-08-16 · DevCraft Studio

不想写一行 LangChain 代码，也想拥有自己的私有 AI 助手？本文用一台 2 GB 内存的小机实测，靠 Docker Compose 把 Flowise 和 Ollama 跑起来，拖拽搭一个能读你文档的 RAG 问答机器人，并暴露成 API。顺便算清它和云端按量计费到底差多少。

延伸阅读

更多相关攻略推荐：【知识库自托管 02】2026 实测：VPS 自托管 Anythin、抢补货/盯降价不求人：changedetection.io 自托管监、【知识库自托管 03】2026 实测：搬瓦工/RackNerd 上自、老牌但能打：Huginn 自托管自动化代理，RSS 聚合+网页监控实、为什么你的 VPS 账号会被突然封禁？避开 TOS 违规陷阱与退款坑。

为什么要在便宜小机上自托管 Flowise

Flowise 现在 GitHub 上已经 54k+ stars，v3.x 版本相当稳定。它本质上是一个「可视化搭 LLM 应用」的画布：左边是一堆节点（大模型、文档加载器、向量库、记忆模块、工具），你拖到中间连上线，就拼出一个能跑的 AI 工作流。底层其实还是 LangChain.js，但对你来说完全不用碰代码。

很多人卡在第一步：是不是一定得租 GPU 服务器、是不是一定得接 OpenAI 按 token 烧钱？其实不是。把 Flowise 和 Ollama 一起丢到一台几十块钱一年的小 VPS 上，本地跑量化模型，你就能拥有一个「数据不出服务器、调用不要钱」的私有 AI 助手。这正是 2026 年自建 AI 应用需求爆发的原因——大家不想再被云端按会话计费绑着。

它的价值不止省钱。对独立站长来说，你可以用它给博客挂一个「读得懂你所有文章」的答疑机器人；对做 SaaS 的小团队，它可以变成面向客户的私有知识库，且客户数据完全留在你自己的机器上，合规上更省心。难点只在运维那一小段，而这恰恰是本文想帮你跨过去的坎。

顺带澄清一个常见误解：Flowise 不是「只能玩具级玩玩」。它底层编译出来的就是正经的 LangChain 管道，能直接当一个稳定的 REST 服务长期跑。你省掉的是写胶水代码和反复调试依赖的时间，而不是能力。所以别被「低代码」三个字劝退——它对付八成「读文档→切块→向量化→检索→回答」的需求，又快又稳。

机器怎么选：2 GB 内存到底够不够

先说结论：只跑 Flowise 本身，官方和社区都确认 2 GB 内存 + 5 GB 硬盘是底线，Node 后端很轻。但一旦你把 Ollama 也塞进去跑本地模型，内存就是真瓶颈了。我的实测建议是：

  • 2 GB 机型：能跑 Flowise，但 Ollama 只能勉强带 0.5B 级别超小模型（比如 qwen2.5:0.5b），应答慢、质量一般，属于「能跑通证明可行性」的玩票档。
  • 4 GB 机型：舒服甜点区，能跑 llama3.2:1b 或 qwen2.5:1.5b，配合 embedding 模型做 RAG 基本可用。
  • 8 GB 机型：真正能打，llama3.1:8b 都不在话下，多客户并发也没压力。

如果你预算紧，像 RackNerd、Cloudcone 这种常年打折的高内存机型很香，年付二三十美元就能拿到 3–4 GB 内存；Bandwagon 的 CN2 GIA 线路对国内访问更稳；想要按小时弹性、随时升配就选 Vultr。一台 20 美元/年的机器，跑 5 个以上客户的文档问答机器人，边际成本几乎为零，这就是自托管相对云端的最大底气。

还有个隐藏要点：别只看内存标价，要看清是「共享 CPU」还是「独占核」。Flowise 启动时吃一阵 CPU，Ollama 推理时更是 CPU 大户，共享核在晚高峰会被邻居挤，响应明显变慢。预算允许就挑给的 vCPU 多、且承诺不超售的机型。另外硬盘优先选 SSD，模型加载和向量检索都吃 IO，机械盘会让首次应答慢到怀疑人生。

用 Docker Compose 一键拉起 Flowise + Ollama

最省事的方式是直接用官方镜像 flowiseai/flowise，再配一个 Ollama 容器。下面这份 compose 是我压过的小机版，去掉了 Postgres，用 SQLite 省内存，向量库先走内存版够用：

version: "3.8" services: ollama: image: ollama/ollama:latest container_name: ollama ports: - "11434:11434" volumes: - ollama_data:/root/.ollama restart: unless-stopped flowise: image: flowiseai/flowise:latest container_name: flowise ports: - "3000:3000" volumes: - flowise_data:/root/.flowise environment: - FLOWISE_USERNAME=admin - FLOWISE_PASSWORD=换一个强密码 - APIKEY_PATH=/root/.flowise - SECRETKEY_PATH=/root/.flowise - LOG_LEVEL=info depends_on: - ollama restart: unless-stopped volumes: ollama_data: flowise_data:

保存为 docker-compose.yml 后直接 docker compose up -d 拉起。然后给 Ollama 灌模型：聊天用 docker exec ollama ollama pull qwen2.5:1.5b，做 RAG 还需要一个 embedding 模型 docker exec ollama ollama pull nomic-embed-text。注意，聊天模型和 embedding 模型是两套东西——前者负责「说话」，后者负责把你的文档变成向量好让机器「检索」。

拖拽搭一个文档问答 RAG 流

打开 http://你的服务器IP:3000，用上面设的账号登录，点「Add New」新建一个 chatflow，然后开始搭积木：

  • PDF File 节点（在 Document Loaders 里）：上传你的产品手册或知识库 PDF。
  • Recursive Character Text Splitter 节点：把长文档切成小块，建议 chunk size 设 1000、overlap 设 200，避免句子被切断。
  • Ollama Embeddings 节点：Base URL 填 http://ollama:11434，模型选 nomic-embed-text。
  • In-Memory Vector Store 节点：接住上面的输出，先把向量存内存里（要持久化就换 Chroma）。
  • ChatOllama 节点：Base URL 同样填 http://ollama:11434，模型填 qwen2.5:1.5b。
  • Conversational Retrieval QA Chain 节点：把向量库、聊天模型、记忆全连上来，再拖一个 Chat 界面节点收尾。

连完点 Save，再点 Chat 试一句「这个产品支持退款吗」。如果它真的从你的 PDF 里掏出答案，恭喜，你的第一个私有 RAG 机器人就活了。整个过程一行代码没写。

这里有个调优小技巧：RAG 的回答质量高度依赖「切块大小」和「检索条数」。块切太大，单个向量涵盖太多无关内容，模型容易被噪声带偏；块切太小，一句话的上下文又会被切碎。新手先照 1000/200 起步，再根据实际问答效果微调。检索条数（Top K）一般设 3–5，太多会灌进噪音，太少又漏掉关键信息。如果你发现它答非所问，八成是切块或嵌入模型没选对，而不是 Flowise 不行。另外给 ChatOllama 加一句 System Message（比如「你是某公司技术支持，不知道就说不知道，不要编造」），能明显压住模型瞎编的毛病。

把机器人暴露成 API 给别人用

Flowise 最爽的一点是：每一个 chatflow 自动带一个 REST 端点。在界面里点「API」或「Use as API」就能拿到 chatflow id，然后这样调用：

curl -X POST http://你的服务器IP:3000/api/v1/prediction/你的CHATFLOW_ID -H "Content-Type: application/json" -d '{"question": "退款政策是怎样的？"}'

想嵌到网站上，Flowise 还给你一段 embed 脚本（flowise-embed），几行就能挂个聊天窗口。对外暴露时记得在反代（Nginx/Caddy）上加 HTTPS 和访问限制，别把 3000 端口裸奔到公网。

如果你要对外提供 API 给别的程序调用，强烈建议再套一层你自己的鉴权（比如反代上做 key 校验），而不是把 Flowise 原生 API 直接放公网——原生端点没有细粒度限流，被人刷起来小机直接躺平。多客户场景下，给每个客户分配独立 chatflow 和独立 API key，既好排查也好转卖。实测一台 4 GB 机在本地模型下，单流应答 2–5 秒，并发三五个客户完全扛得住，这可是云端按量计费怎么都给不了的固定成本优势。

小机避坑指南（中文教程常漏的点）

  • Docker 内不能写 localhost：Flowise 容器和 Ollama 容器是两张「岛」，节点里 Base URL 必须填服务名 http://ollama:11434，写 localhost 会一直连不上。
  • 内存爆了先加 swap：2 GB 小机跑 Ollama 极易 OOM 被杀。建个 2 GB swap 文件能救命，但速度会掉，权当兜底。
  • 磁盘要先留 5 GB：拉镜像 + 下载模型很快吃满空间，/var/lib/docker 所在分区不够会启动失败。
  • 没设密码等于裸奔：FLOWISE_USERNAME/PASSWORD 一定要改，否则任何人都能进你画布乱搭。
  • embedding 模型别忘了拉：很多人只 pull 了聊天模型，RAG 一跑就报「no embedding model」，其实少拉了 nomic-embed-text。

自托管 vs 云端按量计费，差多少

云端方案（比如直接调各家大模型 API）看着便宜，但文档问答这类场景是按对话次数滚动计费的，客户一多、问答一频繁，月账单就上去了。而自托管是一次性固定成本：一台 20 美元/年的小机，模型本地跑不花 token 钱，多服务几个客户边际成本接近零。代价是要自己管更新、备份和稳定性——适合「不想被按次收费绑死、又懒得写代码」的独立站长和开发者。如果你只是偶尔玩票，云端更省心；要长期服务、且重视数据私有，自托管明显更划算。

小机长期跑：备份与升级别偷懒

跑通只是开始，长期稳定才是真功夫。Flowise 的数据（chatflow、凭证、API key）都在 /root/.flowise 这个卷里，Ollama 的模型在 /root/.ollama。定期把这两个目录打包备份，是防止「辛苦搭的机器人一夜回到解放前」的最低成本保险。

  • 备份：用 docker compose stop 停服后 tar 打包两个卷，再 docker compose up -d 拉起，几分钟搞定，比事后重搭省几小时。
  • 升级：Flowise 更新频繁，docker compose pull 拉新镜像再 up -d 即可；但大版本跨 v2 到 v3 有数据结构变化，升级前务必先备份。
  • 监控：小机最怕内存漏光，装个轻量监控或定时 free -h 看一眼，Ollama 进程吃满内存时及时重启。

顺带一提，如果你想把多个客户的机器人隔离开，最干净的做法是给每个客户起一套独立 compose（不同端口、不同卷），虽然占点内存，但一处出问题不会拖累全部，对客户负责也更安心。