为什么要让 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。此时有三种思路：

1. 使用本地执行环境或自建自动化服务，让 Make 与模型处于同一网络。
2. 把模型服务部署在自有服务器，并开启身份校验和访问白名单。
3. 通过中间服务转发请求，但必须限制来源、启用加密传输并记录调用日志。

安全警告：不要把本地模型接口直接公开到公网，更不要使用无鉴权地址处理内部数据。

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

第一，选对模型

自动化流程追求稳定和吞吐。很多场景用 7B 或 8B 量化模型已经够用。若只是做分类、标签、字段抽取，可用更小模型配合明确提示词。若需要长文总结，再考虑更大上下文模型。

第二，控制上下文长度

把无关文本、重复历史和格式说明压缩掉，能明显降低等待时间。

第三，设置合理并发

本地模型并发过高会导致响应变慢、内存溢出或服务卡死。建议先从单并发开始，逐步增加。

参数调优

参数方面，temperature 可设为 0 到 0.3，适合抽取、分类和结构化输出。需要创意改写时再提高。

max tokens 不要设得过大。能输出 300 字就不要给 2000 字空间。

若运行器支持 GPU layers、threads、batch size，可根据硬件逐步调整：

• 显存足够时，增加 GPU 承载层数
• CPU 推理时，线程数一般不宜超过物理核心过多

流程层面优化

可加入缓存机制，相同输入不重复请求模型。对大文件先分段，再汇总，避免一次性塞入过长内容。

常见问题与排查方法

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

安全边界与维护建议

数据安全

本地模型并不会自动保证数据安全。应避免把账号密钥、证件原文、未脱敏合同等直接写入日志。Make 的每个节点也要检查是否保存了完整请求与响应。

接口密钥、访问地址、模型目录权限都应单独管理。离职或设备更换时及时更新。

模型输出可能出现事实错误、格式偏差或遗漏。涉及审批、报价、合同、医疗建议等高风险内容时，应设置人工确认环节。

维护建议

维护上，建议固定一套“测试集”。每次更换模型、修改提示词或调整参数后都跑一遍，比较准确率、速度和失败率。

生产流程不要频繁切换模型版本。确需升级时，先复制一条测试流程，确认稳定后再替换。

总结：只要把模型下载、路径设置、接口连接和性能参数四件事理顺，Make AI 与本地模型的组合就能成为可靠的自动化组件，而不是一次性的实验配置。