部署智能体时，第一个问题不该是买哪台服务器，而是哪些环节由你负责运行。智能体应用接收请求、保存状态、调用工具，再向模型询问下一步。模型推理是另一种工作负载。你完全可以自己托管应用，同时通过 API 购买推理服务。
对于规模小、使用间歇性强的任务，我们建议先考虑调用模型 API 的应用，并严格限制工具权限。如果有明确的数据要求、离线要求，或者实测工作负载足以支持额外投入，再评估自托管推理。这是一套编辑部的决策框架，不是性能测试结论。我们没有对这些架构执行端到端部署验证。
先区分三个位置
写清楚以下三部分分别在哪里运行：
- 智能体运行环境： Web 应用、调度器、任务队列和工具执行器
- 模型运行环境： 接收模型输入、生成输出的推理服务
- 数据与工具： 数据库、上传的文档、浏览器会话和连接的外部服务
VPS 位于某个国家，并不代表所有模型请求和日志都留在该国。同样，即使模型运行在笔记本上，只要搜索、邮件或文档工具会向外部发送信息，整个智能体就不能算完全在本地运行。请画出真实的请求路径，把监控和备份服务也包括进去。
真正有用的隐私问题是：“哪些字段会被发送给哪个服务，用来做什么，保留多久？”OpenAI 的 API 文档分别说明了训练用途、滥用监控日志和应用状态。默认不用于训练，不等于完全不保留数据；具体端点行为和已获准的数据控制措施都很重要。发送敏感材料之前，请阅读适用的数据控制说明。
什么时候适合调用模型 API
调用 API 的服务器可以把资源用于应用本身，不必同时维护模型权重和推理服务。但它仍然需要为并发工作进程、文档解析、浏览器和数据库准备足够的内存。“只是调用 API”不是容量估算：大量操作浏览器的智能体，可能比简单的聊天接口更消耗应用内存。
从工作负载描述开始，而不是寻找适用于所有项目的最低配置。记录最多同时运行多少个任务、典型附件多大、用户能接受的最长等待时间，以及用户断开连接后任务是否还要继续。如果任务可能超过单次请求的生命周期，就需要队列和恢复策略。Vultr 的实例配置参考提供地区、资源套餐、镜像和网络等选项，但不能证明某个套餐一定适合你的智能体。
代价是你需要依赖外部服务。模型接口不可用、配额耗尽、请求被拒绝，以及工具只完成了一部分操作时，都应该有明确处理方式。请求超时后重试，不能再次发送同一封邮件或重复创建工单。保存任务记录、为操作分配唯一标识，往往比立刻升级服务器更有价值。
什么时候值得试验自托管推理
如果所选模型已经达到你的质量要求，而你需要掌控其运行环境、能够维持足够的有效使用率，或者必须在没有模型 API 的情况下工作，自托管就值得评估。这里的自托管既包括自有设备，也包括由你管理的云端硬件。租用 GPU 仍然是在依赖外部基础设施。
容量估算应覆盖完整请求，而不仅是模型下载文件。上下文长度、并发请求、推理运行时开销和其他进程都会影响容量。Ollama 的常见问题说明，并发请求需要额外内存，容量不足时可能进入队列。因此，单人演示能够成功，并不足以证明系统已经适合多用户使用。
用自己的代表性任务做试验：一个简短回答、一份长文档、一次工具选择，以及一个故意无法完成的请求。记录任务成功率、首次有用输出的等待时间、总完成时间、峰值内存和人工介入次数。比较不同方案时，保持测试提示和评分规则一致。不要根据模型参数规模或供应商的硬件名称推断生产质量。所选模型的许可证与计划用途，也应单独核对。
安全要求不因模型位置而降低
改变模型的位置，并不会消除软件获得操作权限后的风险。拥有广泛文件系统权限的本地模型，可能损坏本地文件；通过范围狭窄的只读工具调用 API 模型，反而可能拥有更小的可操作范围。OWASP 的过度代理权限指引将功能过多、权限过大和自主程度过高列为不同问题。
容器便于打包应用，但强大的宿主机接口可能破坏原本的隔离效果。Docker 的安全文档解释了为什么控制守护进程和挂载宿主机文件系统需要格外谨慎。不要因为某篇教程图方便，就把宿主机 Docker 套接字交给处理不可信内容的工具工作进程。
做一个可以调整的决定
正式投入之前，用一页纸记录：
- 工作负载、允许处理的数据，以及禁止执行的操作
- 初始架构，以及它解决的具体约束
- 支出范围和最长队列等待时间
- 一组小型评估任务，以及改变方案需要什么证据
- 谁负责更新、事故处理、备份和密钥轮换
- 如何导出应用状态，以及如何更换模型供应商
把模型适配层与业务规则、工具授权分开。用量、质量要求或数据义务发生变化时，重新评估。适合首次部署的方案，应该是你能理解、观察并安全替换的方案。