FastGPT 部署要多少硬件：三个变量决定，别照抄配置表
「部署 FastGPT 需要什么配置」——这个问题没有单一答案，因为它取决于三个变量。照抄一份没说前提的配置表，要么买多了浪费，要么买少了返工。
这篇讲怎么自己估。
具体的最低配置要求、依赖组件和版本请以 FastGPT 官方文档为准。这篇讲的是估算方法和决策逻辑。
三个变量
变量一：跑不跑本地模型（影响最大）
这是最大的分水岭，两条路的硬件量级完全不同。
只部署应用本身（模型调在线 API）：资源需求相对温和。应用服务、数据库、向量存储这些组件，普通服务器就能跑。
同时部署本地大模型：需要 GPU，而且显存要够跑得动你选的模型。这是另一个量级的投入。
所以第一个要确认的问题不是「要多少配置」，而是「模型放哪」。 这个问题不定，后面全是空谈。
变量二：多少人同时用
注意是「同时」，不是「总共」。
一个五百人的公司，可能高峰期同时在问的只有十几个人。按五百人估硬件是浪费，按十几个估才是对的。
但要按峰值估，不是平均值。 有些场景有明显的高峰——招生季、报销截止日、政策发布后的第二天。这些时候的并发量可能是平时的好几倍。
变量三：知识库有多大
文档量决定了向量存储的规模和检索时的资源消耗。
几百份文档和几十万份文档，不是一个方案。前者用最小配置就行，后者要认真考虑存储和检索的性能。
要问清楚的是「最终会有多少」，不是「现在有多少」。 甲方经常是先传一个部门的试试，用得好了再把全公司的都传进来——如果按试点规模买硬件，三个月后就要重来。
怎么估：先搭最小的，用真实数据测
这是最实际的建议：别一上来就按想象中的峰值采购。
推荐顺序：
第一步，用最小可用配置搭一套。 目的不是上线，是摸清真实的使用模式。
第二步，导入真实文档，不是样例数据。 真实文档的大小、格式、复杂度和理想化的测试数据差很远。
第三步，找一批真实用户试用一段时间。 你会发现两件事：他们实际问的问题和你预想的不一样；实际的并发量和你估算的也不一样。
第四步，看实际的资源消耗曲线再定配置。
这个顺序省下来的钱，通常远超多花的那点时间。 我们见过按峰值采购、结果常年跑在一成负载下的项目，也见过按试点规模买、三个月后推倒重来的。
本地模型的额外考虑
如果确定要跑本地模型，还有几件事：
显存决定你能跑多大的模型。 这是硬约束——显存不够，模型加载不起来，没有折中方案。
模型大小和效果不是线性关系。 更大的模型效果通常更好，但提升幅度和成本增长不成正比。对知识库问答这类任务，中等规模的模型往往就够用——因为答案主要来自检索到的资料，模型负责的是组织语言，不是靠自己的知识回答。
embedding 模型也要算进去。 这一点经常被漏掉——建索引和检索时都要用它，如果要求数据不出网，那 embedding 模型也必须本地部署，同样占资源。详见 embedding 模型怎么选。
并发会显著影响显存需求。 一个人用和十个人同时用，需要的显存不一样。
给客户报价时怎么处理
第一，先问清「私有化」是哪一种。 这四个字在不同甲方嘴里至少有三种含义：
- 装在我们服务器上就行（模型可以调在线 API）
- 数据不能出我们的网（模型必须本地部署，要 GPU）
- 完全不能连外网（还要考虑离线安装、离线更新）
这三种的报价可以差好几倍。 在方案阶段问清楚，并且把差异写进方案让甲方签字确认。
第二，别在方案里写死具体的价格数字。 硬件价格会变，云服务的计费规则也会调整。写清楚影响成本的变量和结构，让甲方理解为什么是这个量级，比写一个会过期的数字有用。
第三，把扩容路径写清楚。 现在按试点规模配，将来全量上线要怎么扩、大概什么代价。甲方最怕的是「买了之后发现不够用还得全换」。
第四，明确硬件由谁采购。 甲方自采还是你代采，这直接影响报价结构和责任划分。
容易被漏算的四项资源
估配置时，大家的注意力都在「跑模型要多少显存」上，下面这几项经常被忘掉，然后在上线后成为瓶颈。
一、向量存储的增长。 知识库不是传完就不动了。文档持续增加、更新重传、切块策略调整后重建——这些都会占用存储。按最终规模的一到两倍留余量，比事后扩容省事。
二、对话记录的积累。 每次问答都会留下记录。用的人多、用得久，这部分数据增长很快。要定一个保留策略：留多久、超期怎么处理。不定的话，某天磁盘满了系统就挂了，而且这类故障的表现很迷惑——看起来像软件出问题。
三、文档处理时的临时开销。 批量导入几千份文档时，解析、切块、生成向量都是计算密集的。导入期的资源占用可能远高于日常运行，如果按日常负载配置，导入时会非常慢甚至失败。
四、备份占用的空间。 备份要存在某个地方，而且不能只存一份、不能和原数据放同一块盘。这部分空间也要算。
一个实际建议：把「日常运行」和「批量导入」当成两种工况分别评估。很多项目的资源峰值出现在初始导入阶段，而不是日常使用时。
一个反向的问题
如果你算下来发现硬件投入很大，值得回头问一句：这个项目真的需要私有化部署吗？
如果数据本身不敏感——产品手册、公开的规章制度、对外的服务指南——那用托管服务可能划算得多，省掉的不只是硬件，还有长期的运维投入。
私有化部署的成本不只是部署那一次：升级、排障、备份、安全补丁，每一样都要有人管。这些在托管服务里是别人的活。
判断依据见 Dify 本地部署前要想清楚的六件事——虽然以 Dify 为例，但决策逻辑对 FastGPT 完全一样。
顺带说一句：FastGPT 的许可明确允许作为应用开发平台交付给企业，这一点对做项目的人很关键，见开源 Agent 平台的许可证差别。
项目上要判断该走哪条路的，可以找我们聊聊——用托管能解决的，我们会直说。