文章目录
内容提要
第一步不是选 GPU，而是定义任务边界
同样叫本地大模型，实际可能是单人离线问答、部门知识库 RAG、代码辅助、视觉多模态推理，或少量 LoRA / QLoRA 微调。推理场景更关注显存容量、上下文长度和响应延迟；RAG 场景还要看文档切分、向量库、检索链路和并发访问；微调场景则会把 GPU 显存、训练数据缓存、框架版本和长期满载能力都纳入配置边界。
显存决定能选多大的模型和多长的上下文
模型参数量、量化精度、KV Cache、上下文长度和并发请求都会消耗显存。7B/14B 级模型和 32B/70B 级模型的配置逻辑不同；只看模型能不能加载，不能代表实际可用。若需要更长上下文、多用户同时访问或多模型常驻，显存余量要明显高于单次测试的最低占用。
RAG 的瓶颈经常在数据路径而不在模型本身
知识库问答需要文档解析、清洗、切分、Embedding、向量检索、权限过滤和结果重排。文档数量一多，内存、NVMe 数据盘、索引位置和备份策略会直接影响体验。系统盘、模型盘、向量库和原始文档混在一起，后期不仅慢，也不利于权限管理和数据恢复。
CPU 和内存负责把系统撑稳
本地 AI 工作站并不是 GPU 附属品。CPU 会参与数据预处理、服务编排、部分推理前后处理和多任务调度；内存则影响大文档处理、向量库构建、浏览器/开发环境/推理服务并行时的稳定性。面向日常使用的设备，应优先保证系统长期响应稳定，而不是只追求单次推理速度。
工作站还是服务器，取决于使用方式
单人或少数工程师本地开发、演示和知识库调试，通常适合高显存工作站；多人共享、长期在线、接口调用、权限隔离和远程访问，则更接近 GPU 服务器或小型平台需求。采购前应明确设备放在办公室还是机房、是否 7x24 运行、是否需要远程管理和后续多 GPU 扩展。
合理目标是“稳定可扩展”，不是“最低价能跑”
很多模型可以通过低比特量化、缩短上下文或降低并发勉强运行，但交互延迟、知识库更新、多人访问和后续升级会很快暴露问题。更稳妥的做法，是把模型规模、上下文长度、并发人数、响应目标、数据容量和半年到一年的扩展预期写清楚，再决定 GPU、内存、NVMe 和平台形态。
选型检查清单
- 明确推理、RAG、微调或多模态任务比例
- 确认模型参数量、量化方式和上下文长度
- 估算并发人数、响应延迟和模型常驻数量
- 规划原始文档、向量库、模型文件和备份路径
- 判断单人工位、共享工作站还是 GPU 服务器平台