本地 AI 开发工作站：按开发流程规划内存

1. 区分推理、适配与训练

列出代码助手、检索流程、图像生成、嵌入、适配器微调或完整训练等日常任务，记录框架、模型修订、量化、上下文、批量及同时用户。这些资源因素远比“能跑本地 AI”具体。

能服务量化模型的工作站，未必有足够内存训练同一模型。训练可能在权重之外需要梯度、优化器状态、激活和临时缓冲。应演示包含数据准备与检查点保存的真实流程，而非只演示加载。

2. 权重计算只能作为下限

例如八十亿参数，每参数四比特，原始权重数据为四十亿字节，约 3.73 GiB。该计算不含量化元数据、运行时分配、上下文缓存及其他开销，并不保证“8B”模型能装入 4 GB 显卡。

在最长预期提示和并发任务下测量峰值。Ollama 上下文文档明确说明更长上下文需要更多内存，其 FAQ 讨论并发。因此单个短请求演示不足以证明团队代码工具或长文档智能体的容量。

3. 选卡前核对软件栈

Ollama 提供硬件支持信息，应核对具体设备、操作系统和驱动组合。其他框架有各自要求。GPU 理论显存或算力足够，也不能让不受支持的运行时自动获得支持。

多 GPU 应核实框架实际切分方式、互连和主机配置，不要假设两张卡自动形成统一内存池。记录每卡驻留内容和是否发生 CPU 卸载，卸载后应实测响应，而非宣称等同于完全在 GPU 上执行。

4. 检查完整开发主机

5. 验收应模拟普通工作日

同时运行编辑器、浏览器、模型服务和代表性数据流程，测量冷加载、首个有用响应、持续生成和内存峰值。分别测试最长常规提示和典型提示；若日常会休眠或重启，也应在之后重复。

适配任务记录数据集、方法、批量、时长和检查点完整性；推理同时记录质量、延迟及每秒 token。机器卡顿或输出不合格时，单个速度数字不能证明开发体验有用。

6. 比较日常本地容量与偶发远程峰值

估计持续本地使用量和仍需远程执行的任务成本，加入电力、维护、软件管理及开发者时间。本地执行可支持特定隐私要求，但不会自动保护应用、备份或网络访问。

为日常流程购买经过验证的足够容量，另行评估罕见峰值。索取完整物料和明确扩展路径。仅承诺以后加卡，证据力度弱于受支持的目标配置与代表性验收结果。