模型文件能否运行，取决于显存或统一内存容量、带宽、量化格式和并发方式。Magnitude 把硬件分析、模型推荐和推理服务放在同一个流程里，试图让 Agent 根据真实设备选择可用配置，而不是让用户手动猜测参数。

这种封装对于代码 Agent 尤其重要。工具需要稳定的流式输出、较低的首 token 延迟和可预测的上下文容量；一个理论上更强但频繁换入换出的模型，实际体验可能不如稍小但持续运行的模型。

项目支持模型按请求加载，在空闲或内存紧张时卸载。这样同一台设备可以在不同任务间切换模型，避免所有权重长期占据内存，但代价是首次调用可能需要额外等待，调度器也要处理并发请求的资源竞争。

本地部署还带来隐私和运维优势：提示词、代码和文件可以留在设备内，不必为每次调用发送到远端服务。不过，模型缓存、日志和 Agent 插件仍可能保存敏感信息，不能只看推理进程是否离线。

根据规格推荐模型只是起点。代码修改、长上下文检索和多工具调用对延迟与内存的要求不同，用户还需要用自己的任务测量 token 速度、失败率、上下文截断和功耗。推荐结果如果没有可验证的基准，很容易变成另一种静态榜单。

中转查认为，本地 Agent 服务的核心竞争力会逐渐从“能运行”变成“知道如何在这台机器上稳定运行”。硬件画像、可回退模型和透明的资源指标应当成为默认能力。