“给二十个人用，配多大显卡”还无法回答。二十人偶尔查制度，与二十人同时处理长文、批量导入扫描件，负载完全不同。先把任务、模型、资料量、并发、响应要求和运维条件写成测试场景，再决定是单台工作站、服务器还是专有环境。

先区分四类负载

知识问答通常包含文档检索和模型生成；长文处理会占用更长上下文并持续更久；批量入库还要解析、OCR、切分和建立索引；多人并发关注排队与资源隔离。它们可能由不同组件承担，不能只看模型推理速度。

把每类任务写成测试用例：输入长度、期望输出、一天多少次、峰值同时多少人、可接受等待时间和是否允许排队。没有这些条件的“每秒多少字”很难转成真实体验。

  • 短问答：典型问题、引用数量和响应等待

  • 长文：文件长度、上下文范围和输出长度

  • 批量入库：文件数、格式、扫描件占比和更新时间

  • 并发使用：峰值用户、排队策略和单任务上限

模型、文件和索引要放在一张容量表里

模型参数规模、数值精度、上下文长度和推理框架都会影响内存或显存占用；检索还需要嵌入模型、索引和重排组件；OCR和文件解析可能占用CPU、内存和临时存储。具体数值随模型与版本变化，应以拟用组件的官方要求和现场压测为准。

不要先买固定设备再勉强塞任务。可先在临时环境用代表性资料运行候选方案，观察峰值资源、响应、错误和稳定性，再决定是否量化模型、限制上下文、拆分服务或升级硬件。

原文件、解析文本、页面图像、向量索引、版本副本、日志和备份都会占空间。扫描件解析还可能产生大量临时文件。估算时记录文件数量、平均与最大尺寸、扫描件比例、更新频率、保留版本和备份周期。

资料更新方式影响算力：每天少量增量和一次性导入多年档案不同。删除文件时还要同步删除索引和派生数据；否则界面上看不到，模型仍可能检索到旧内容。

并发、许可和运维决定方案能否长期用

同一时刻的活跃请求比账号总数更重要。应测试高峰排队、超时、任务取消和大任务占满资源时普通查询是否仍可用。还要核对模型、嵌入、OCR、数据库和管理组件的许可是否覆盖当前使用方式。

本地部署需要有人负责驱动、补丁、模型升级、知识备份、账号、监控和故障恢复。若组织没有维护条件，专有托管环境可能更合适；反之，资料边界和网络要求也可能决定必须本地。选择是条件判断，不是安全等级排名。

压测和采购验收清单

压测使用经过授权的代表性资料，分别测冷启动、连续运行、峰值并发、批量入库和故障恢复。结果记录组件版本和日期，避免软件更新后继续沿用旧结论。

  • 四类任务是否都有输入、并发和等待目标

  • 峰值内存、显存、CPU、存储和临时空间是否实测

  • 批量入库是否影响日常问答并有调度策略

  • 模型与第三方组件许可是否逐项核对

  • 备份恢复、账号停用、更新回退是否有人负责

  • 误区：只按账号数配机器；只测单次问答；本地设备买完就无需持续运维

常见问题

能否直接给出通用的显存配置表？

不建议脱离具体模型、精度、上下文、并发和框架给固定答案。先选候选组件，用代表性任务压测，再按峰值与升级余量确定配置。

用户不多，是否一台普通电脑就够？

要看任务。少量短问答与长文、OCR、批量入库差别很大，还需考虑等待时间、数据量和可用性。小规模可以先做样机测试。

硬件验收只看响应速度吗？

还应看连续运行稳定性、并发排队、入库吞吐、资源峰值、错误恢复、噪声与能耗条件，以及软件许可和运维责任。