估算整体足迹
权重、量化、上下文长度、缓存和并发请求都会影响内存。为操作系统和运行时留出余量。CPU 推理和 GPU 推理具有不同的成本和吞吐量特征；标准 VPS 并不意味着可访问 GPU。
保持模型 API 私密
诸如 Ollama 之类的运行时不应在没有适当安全层的情况下暴露于互联网。在可行时绑定到回环或私有接口，并在任何远程路由前放置经过身份验证的 TLS 访问。
带来源验证下载
审查模型许可证、来源、提供的校验和以及预期用途。不可信的模型格式或周边加载器代码可能扩大攻击面。保持运行时和依赖项的维护。
对真实请求进行基准测试
使用你的应用所用的上下文大小，测量首令牌延迟、每秒令牌数、内存压力和并发行为。添加请求大小限制、排队和超时，使单个大型提示无法耗尽机器资源。
证明 API 未公开
本地 Ollama API 访问不需要身份验证。如果只有您自己的应用调用它，请将监听器保持在回环地址上。对于远程使用，请添加经过身份验证的 TLS 网关或带有请求和并发限制的私有隧道。云 API 凭据不会自动保护本地监听器。请从无访问权限的设备进行测试，并要求其被拒绝。
- 检查监听地址
- 尝试从允许网络之外发起未认证请求
- 对上下文大小和并发生成应用限制
ss -lntp
curl --fail http://127.0.0.1:11434/api/tags官方文档：Ollama 身份验证模型
保留一个小型基准笔记本
记录确切的模型变体、量化方式、上下文长度、提示词和并行请求数量。测量运行时内存，而不是假设它等于模型下载大小。在配置更改后重复相同的请求，并保留质量检查以及速度测量。如果作业大量交换或挤占主应用程序，请降低并发数或使用更合适的机器。
在增加上下文之前先规划模型内存
用参数数量乘以量化位数再除以八，作为仅权重的粗略字节估算，然后加上运行时、上下文/KV 缓存、并发和操作系统余量。这不是容量保证。在 Ollama 中，并行请求和更大的上下文会增加内存占用，而排队工作可能让看似健康的服务变慢。先从一个模型和一个请求开始，记录峰值内存，只有在工作负载达到延迟目标后才提高并发。
- 每次基准测试都记录模型标签、运行时版本、量化方式、提示长度和输出上限。
- 将冷启动加载与热请求性能分开；它们回答不同的容量规划问题。
- 如果主机发生交换或进程被终止，请降低并发/上下文并检查内存事件，然后再购买 CPU 核心。
- 当首个请求很快但后续请求停滞时，检查已加载的模型和缓存增长情况。
# Inspect the model runner and host without changing its configuration.
ollama ps
free -h
df -h官方文档：Ollama：内存、并发和网络配置
将嵌入作为独立工作负载进行测试
嵌入模型将输入文本转换为用于检索的向量；它与长生成答案的资源需求并不相同。在索引和查询时，请一致地使用同一模型和预处理策略。Ollama 的嵌入端点接受文本或批次，当 truncate 为 false 时可能拒绝过长输入。请选择有意的分块策略，以免文档在不合适的边界处被静默截断。
- 分别对索引批处理和交互式查询进行基准测试，包括存储和向量数据库成本。
- 将模型名称和嵌入维度与索引一起保留。更改它们通常需要经过深思熟虑的重新索引计划。
- 使用小型检索评估集：已知问题、预期文档以及应返回无相关结果的案例。
- 将提示、索引文档和访问日志视为独立的数据存储，各自拥有访问和删除规则。
官方文档：Ollama：嵌入 API