同样是“100 个用户”，如果每天只有少量制度查询，与同时处理长文档、专家检索、录音和大篇幅写作，硬件需求完全不同。采购前先定义工作负载和服务目标，通常比直接询问“要几张卡”更能避免配置不足或长期闲置。
需要收集的输入
模型与质量目标
计划使用的主模型、视觉模型、向量与精排模型，参数规模、量化精度、最大上下文和可接受的回答质量。
交互负载
总用户、峰值同时请求数、问题长度、期望首字时间、平均输出长度，以及标准、深度、专家检索的使用比例。
批处理负载
每日新增文档页数、扫描件占比、表格复杂度、批量重解析需求、录音时长和高峰导入窗口。
数据与恢复
历史文件规模、年增长率、版本与处理产物、备份保留周期、恢复时间目标和可接受的数据丢失窗口。
硬件资源分别承担什么
| 资源 | 主要负载 | 常见约束 |
|---|---|---|
| GPU 显存与算力 | 大模型、视觉 OCR、向量 / 精排、语音相关模型 | 模型权重、KV Cache、并发批处理、上下文长度与精度 |
| CPU | PDF 渲染、Office 转换、文档抽取、服务与数据库 | 扫描件并发、压缩解压、旧格式转换和后台任务 |
| 系统内存 | 服务进程、数据库缓存、文档处理和模型辅助组件 | 大文件、并发解析、数据表处理与缓存策略 |
| 本地磁盘 | 数据库、对象文件、容器镜像、模型和临时文件 | 容量增长、随机 IOPS、顺序吞吐、冗余与故障域 |
| 网络 | 上传、对象存储、节点间模型与服务流量、备份 | 大文件并发、跨节点流量、备份窗口和网络分区 |
建议的测算步骤
- 定义服务目标。写清峰值并发、可接受响应时间、每日处理量、维护窗口和故障恢复要求。
- 选模型候选。在代表性问题、文档和音频上比较不同模型与精度，不先按最大模型锁死硬件。
- 做单链路基准。分别测量问答 token 吞吐、OCR 每页耗时、文档 CPU 时间、录音处理倍率和存储增长。
- 组合压力测试。模拟交互问答与后台解析同时发生，观察排队、显存、CPU、数据库和磁盘，而不是只测单请求峰值。
- 留出运维余量。为升级、重建索引、批量导入、节点故障和数据增长预留容量，并记录扩容触发指标。
为什么这里不给固定型号表
硬件与模型版本变化快，GPU 型号、量化方式、上下文长度和推理引擎都会改变容量。固定写“某卡支持多少并发”很容易脱离输入长度、输出长度与服务级别。更可靠的交付物应是：候选模型与版本、测试数据集、推理参数、并发曲线、资源监控、瓶颈说明和容量余量。
已有服务器也可以评估，但“能启动模型”不等于满足业务负载。应同时验证驱动、显存、CPU、磁盘、网络、散热与持续高负载稳定性。