Make AI 本地模型运行教程：模型下载、路径设置与性能优化指南

为什么要让 Make AI 跑本地模型

Make 是常见的自动化编排工具，适合把表单、文档、消息、工单和各类业务系统串成流程。把 Make AI 接入本地模型后，常见任务如文本分类、摘要生成、字段抽取、客服草稿、知识库问答等，可以在本机或自有服务器完成推理，减少对外部服务的依赖，也便于控制数据留存范围。需要注意的是，本地模型并不等于“零成本”或“完全可靠”，它对硬件、模型选择、路径配置、接口连通性都有要求，前期配置越规范，后续自动化流程越稳定。

适合本地部署的场景包括：数据不便外发的内部文档处理、批量内容清洗、低频但需长期运行的自动化任务、对输出格式有强约束的流程节点。若任务需要超大上下文、极高准确率或复杂多轮推理，本地小模型可能需要搭配规则校验、人工复核或更强硬件。

准备工作：硬件、软件与模型运行器

运行本地模型前，先确认机器配置。轻量级 7B 或 8B 模型的 4bit 量化版本通常需要 8GB 到 16GB 内存；如果希望速度更快，建议使用带有 8GB 以上显存的显卡。13B、14B 及更大模型对内存和显存要求明显提高，不建议在普通办公电脑上直接承载高并发自动化任务。磁盘方面，建议把模型放在 SSD，单个模型文件可能从数 GB 到数十 GB 不等。

软件层面可选择 Ollama、LM Studio、llama.cpp 等运行器。Ollama 的优势是命令简单、接口稳定，适合自动化调用；LM Studio 界面友好，适合先测试模型效果；llama.cpp 灵活度高，但参数较多，更适合有经验的用户。Make AI 侧通常通过 HTTP 接口或兼容 OpenAI 格式的接口调用本地模型，因此运行器是否提供稳定 API 是优先考虑项。

模型下载：优先选择合适而不是最大

下载模型时不要盲目追求参数规模。中文办公、摘要、分类、改写等任务，可优先测试 Qwen、DeepSeek、Llama 系列中体积适中的指令模型。若使用 Ollama，可通过其模型库选择对应标签；若使用 LM Studio，可在内置模型搜索中下载 GGUF 格式模型。建议优先选择 Q4_K_M、Q5_K_M 等量化版本，它们在速度、内存占用和效果之间比较平衡。

下载前要查看模型许可说明、适用语言、上下文长度和推荐硬件。企业环境中不要随意使用来源不明的权重文件，避免夹带异常脚本或不清楚的授权限制。模型下载完成后，先用几条真实但脱敏的样例进行测试，确认它能稳定输出 JSON、表格字段或指定格式，再接入 Make 流程。

路径设置：模型目录要固定、清晰、可备份

模型路径设置是很多故障的来源。建议新建统一目录，例如 Windows 可使用 C:AIModels，macOS 或 Linux 可使用 /Users/用户名/AI/models 或 /opt/ai/models。目录名尽量不要包含中文、特殊符号和过长层级，避免运行器识别异常。若使用 Ollama，可以通过环境变量 OLLAMA_MODELS 指定模型存放位置；修改后需重启服务或终端会话，才能让新路径生效。

LM Studio 通常可以在设置中修改模型目录，修改后需要重新扫描模型文件。若手动移动 GGUF 文件，要确保文件完整，名称不要随意改得过于复杂。服务器环境还要检查目录权限，运行模型服务的用户必须具备读取模型文件和写入缓存的权限。对于团队使用，建议建立“模型名称、版本、量化类型、下载来源、测试日期”的登记表，避免多人重复下载或误删正在被流程使用的模型。

连接 Make AI：先本机验证，再接入流程

连接前应先确认模型服务可用。以 Ollama 为例，默认接口通常在 127.0.0.1:11434；部分运行器也会提供兼容 OpenAI 的地址，例如 /v1/chat/completions。先在本机用运行器自带界面或简单请求测试模型响应，再到 Make 的 HTTP 模块或 AI 相关模块中配置接口地址、请求头和请求体。

如果 Make 流程运行在云端，云端无法直接访问你电脑上的 127.0.0.1。此时有三种思路：一是使用本地执行环境或自建自动化服务，让 Make 与模型处于同一网络；二是把模型服务部署在自有服务器，并开启身份校验和访问白名单；三是通过中间服务转发请求，但必须限制来源、启用加密传输并记录调用日志。不要把本地模型接口直接公开到公网，更不要使用无鉴权地址处理内部数据。

性能优化：从模型、参数和流程三处入手

第一，选对模型。自动化流程追求稳定和吞吐，很多场景用 7B 或 8B 量化模型已经够用。若只是做分类、标签、字段抽取，可用更小模型配合明确提示词；若需要长文总结，再考虑更大上下文模型。第二，控制上下文长度。把无关文本、重复历史和格式说明压缩掉，能明显降低等待时间。第三，设置合理并发。本地模型并发过高会导致响应变慢、内存溢出或服务卡死，建议先从单并发开始，逐步增加。

参数方面，temperature 可设为 0 到 0.3，适合抽取、分类和结构化输出；需要创意改写时再提高。max tokens 不要设得过大，能输出 300 字就不要给 2000 字空间。若运行器支持 GPU layers、threads、batch size，可根据硬件逐步调整：显存足够时增加 GPU 承载层数，CPU 推理时线程数一般不宜超过物理核心过多。流程层面可加入缓存机制，相同输入不重复请求模型；对大文件先分段，再汇总，避免一次性塞入过长内容。

常见问题与排查方法

问题一：Make 提示连接失败。先检查模型服务是否启动、端口是否正确、防护软件是否拦截、本地地址是否被云端流程误用。问题二：模型显示已下载但无法调用。检查模型名称是否与接口请求中的名称一致，路径修改后是否重启服务。问题三：输出不是 JSON。提示词中要明确“只输出合法 JSON，不要解释”，同时在 Make 后续节点增加解析失败重试或兜底分支。问题四：速度太慢。优先换更小量化模型，缩短输入文本，关闭不必要并发，再考虑升级硬件。问题五：运行一段时间后卡住。查看日志和内存占用，给服务设置定时健康检查，必要时让流程在失败后等待数秒重试。

安全边界与维护建议

本地模型并不会自动保证数据安全。应避免把账号密钥、证件原文、未脱敏合同等直接写入日志；Make 的每个节点也要检查是否保存了完整请求与响应。接口密钥、访问地址、模型目录权限都应单独管理，离职或设备更换时及时更新。模型输出可能出现事实错误、格式偏差或遗漏，涉及审批、报价、合同、医疗建议等高风险内容时，应设置人工确认环节。

维护上建议固定一套“测试集”，每次更换模型、修改提示词或调整参数后都跑一遍，比较准确率、速度和失败率。生产流程不要频繁切换模型版本，确需升级时先复制一条测试流程，确认稳定后再替换。只要把模型下载、路径设置、接口连接和性能参数四件事理顺，Make AI 与本地模型的组合就能成为可靠的自动化组件，而不是一次性的实验配置。