想在自己机器或公司服务器上跑 RAGFlow，第一个要定的不是用哪个模型，而是先用哪种部署形态、机器底线能不能撑住。RAGFlow 官方提供的是容器化部署路径，用一份编排文件把后端服务、任务队列、向量库和关系库一起拉起，这条路对单人和多人都通用。区别在于：单人试用只看“能不能跑通”，多人共用要看“账号怎么分、解析并发顶不顶得住、数据会不会串”。建议先把最小可用部署跑起来，拿真实的容器资源占用数据判断机器能不能长期挂，再决定是不是要加机器或换部署方式。
先从容器化最小部署入手，跑通后用 docker stats 和日志观察一两天的 CPU、内存、磁盘增长，再决定去留。单人试用对账号、并发、隔离几乎没有要求；多人共用必须提前确认账号体系、同时解析数量和知识库可见范围，否则后面拆数据会很麻烦。模型接入先按问答延迟和是否能连外网来定，本地推理吃显存和内存，外部服务省硬件但依赖网络。硬件底线没有统一数字，以实际观测为准，先按最小配置跑一周再加机器更稳。
用容器方式拉起服务，确认默认端口和依赖组件都就位
RAGFlow 的部署入口是仓库里的 docker 编排文件，通常在 docker/ 目录下，包含 docker-compose.yml 以及一份环境变量文件（常见命名是 .env 或 docker-compose-base.yml 拆分基础组件）。启动前先确认宿主机装了 Docker 和 Compose 插件，然后按下面的顺序执行，把最小可用基线建立起来。
# 进入部署目录
cd RAGFlow/docker
# 首次部署，先生成/检查 .env 里的镜像地址、端口和密码项
# 常见的可调项：SVR_HTTP_PORT、MYSQL_PASSWORD、MINIO_PASSWORD、ES_PORT
# 拉起全部服务（后台运行）
docker compose -f docker-compose.yml up -d
# 查看容器状态，确认没有反复重启
docker compose ps需要一起起来的基础组件通常包括：RAGFlow 自身的 server 与 task executor、MySQL（元数据）、MinIO（对象存储，放原始文件和解析产物）、Elasticsearch 或 Infinity（检索层）、Redis（缓存与队列）。这些组件缺一个，控制台可能能打开，但上传解析或检索会报错，所以 docker compose ps 里应该是全部 Up，而不是只有一两个在跑。
控制台初始化成功的验证点，建议按这几条逐个确认，可以作为后续所有验证的基线：
- 浏览器访问宿主机 IP 加
SVR_HTTP_PORT（默认常见是 80 或 9380，以.env实际值为准），能看到登录/注册页。 - 用注册的账号能登录进主界面，左侧能看到知识库、对话等菜单。
- 建一个空知识库，能正常保存，说明 MySQL 写入没问题。
- 上传一个小的纯文本文件，任务能进入解析队列并最终显示完成，说明 task executor、MinIO、检索层都通了。
docker compose logs `--tail`=100里没有持续报错或反复重连。
如果卡在某一步，先看对应容器的日志再改配置，不要一上来就改一堆参数。基线没建立之前做的调优，后面很难区分是配置问题还是硬件问题。
看容器资源占用随时间的变化，判断机器能不能长期挂
“能不能跑”和“能不能长期挂”是两件事。最小部署刚起来时占用往往偏低，真正的压力来自解析任务和检索请求。建议跑通后先观察一到两天，用下面的命令拿实际数据，而不是凭印象估算。
# 实时看每个容器的 CPU、内存、网络、磁盘 IO
docker stats
# 只看 RAGFlow 相关容器，按内存排序
docker stats `--no-stream` `--format` "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"
# 看容器日志尾部，判断是否有反复重试
docker compose logs `--tail`=200 -f
# 看磁盘占用，重点是镜像层、卷和容器可写层
docker system df
du -sh /var/lib/docker/volumes/* 2>/dev/null
# 看宿主机整体内存和磁盘余量
free -h
df -h观察并发时的占用峰值，做法是：在控制台里一次上传若干个文档，或让多个人同时提问，同时另开一个终端跑 docker stats，记录任务 executor 和检索层容器在这一段时间内的 CPU、内存曲线。峰值通常出现在文档解析阶段，尤其是解析较长 PDF 或扫描件时。这里不预设具体数值，以自己机器上看到的为准；如果内存已经贴近宿主机上限，或者出现容器被 OOM 杀掉，就说明这台机器不适合长期挂当前规模的解析。
磁盘增长的主要来源通常是三类：MinIO 里存的原始文件和解析后的切片、检索层索引、MySQL 元数据与日志。文档删掉后如果只是软删除，底层对象和索引可能还占着空间，所以磁盘规划要按“长期只增”的保守思路留余量，别按单次上传的量来算。
单人试用和多人共用，差距在账号、并发和数据隔离
单人试用时，控制台里的团队、成员、权限这些页面基本不用碰，注册一个账号就够了，知识库也只有一个视角。多人共用则要在搭建阶段就确认几件事，否则后期调整成本很高。
账号与团队相关的界面项，通常包括成员邀请或添加、角色权限（比如是否允许上传、是否允许删除、能否看到全部知识库）、以及知识库的可见范围设置。先去这些页面确认能不能满足你团队的分工方式，再决定要不要让多人共用一个实例。
多人同时解析时，表现会明显不同于单人：多个文档一起进队列，task executor 的 CPU 和内存会同时抬升，解析完成时间被拉长；如果检索层资源不够，提问的响应也会变慢。建议在共用前做一次小规模并发测试，记录同时上传三到五份文档、以及三到五个人同时提问时的表现，作为容量参考。
共用场景下还需要额外确认的项：
- 数据隔离方式：是每人一个知识库，还是共用同一批知识库靠权限控制。前者更干净，后者管理简单但要注意越权访问。
- 账号来源：是本地注册管理，还是对接已有的登录体系。对接会增加部署复杂度，要确认清楚再动手。
- 备份范围：多人共用时数据量更大，MinIO、MySQL 和索引的备份策略要在上线前定好。
- 资源配额：是否需要对单个账号或单个知识库限制上传量，避免某个人把磁盘写满。
模型走本地还是走外部服务，先看问答延迟和网络条件
模型接入在模型设置页配置。需要填的字段类别通常包括：模型提供商类型、接口地址、密钥、模型名称，以及对话模型和向量模型分开选择。向量模型决定文档怎么被向量化，对话模型决定回答质量，两者可以来自不同来源。
本地推理和外部服务的取舍，先看两点：问答延迟和网络条件。本地部署的好处是不依赖外网、数据不出机器，代价是要占显存或内存，机器底线直接受模型规模影响，小机器只能跑较小的模型。外部服务的好处是省本地算力，代价是每次问答都要走网络，延迟取决于链路质量，而且需要确认网络能稳定访问对应接口。
观察响应时间的方法很直接：在对话页面提一个固定问题，感觉从发送到出字的时间；也可以看 server 容器的日志里关于模型调用的耗时行。本地推理如果机器不够，会出现明显的首字延迟；外部服务如果网络不稳，表现为请求长时间没响应或直接超时。网络不通时的典型表现是：聊天报接口错误、知识库完成向量化后检索正常但问答失败、日志里出现连接超时或解析域名失败。遇到这类情况先确认模型设置页里的接口地址和密钥，再用命令测试宿主机到目标地址的连通性，不要先怀疑 RAGFlow 本身。
按最小可用配置先跑一周，再决定要不要加机器
扩容决策最好基于一周的真实使用数据，而不是第一天的空载表现。这一周建议记录：每天提问次数和上传解析的文档量、docker stats 里内存和 CPU 的峰值、df -h 看磁盘每天净增多少、有没有出现请求超时或任务失败。这些都可以从命令输出和页面行为里直接拿到。
判断是否需要扩容的阈值思路，是看趋势而不是看单点：如果内存峰值经常贴近宿主机上限、磁盘按当前增速在可预见的时间内会满、或者多人同时用时问答明显变慢且任务排队变长，就说明该加资源了。反过来，如果一周内各项占用都留有余量，说明当前配置够用，可以先不动。
真要扩容，有两种方向。加机器适合 CPU、内存、磁盘同时吃紧的场景，直接把整套服务迁到更大配置的机器上，操作简单但成本一次性上升。拆库适合瓶颈集中在检索或存储的场景：把检索层、对象存储或数据库分到独立机器上，RAGFlow 主服务和任务执行仍在一台，通过网络连过去，这样能分别扩容，但配置和排障都会变复杂，需要先确认各组件地址在编排文件里怎么改。选哪种，取决于你这一周记录到的瓶颈出现在哪个组件上。