Jetson 上 OpenClaw + Ollama + llama.cpp 的联动配置模板部署大模型

Jetson 上我建议的联动方式是:OpenClaw -> Ollama(主模型,原生 API)+ llama.cpp(备用/低资源模型,OpenAI 兼容 API)+ Ollama embeddings(memorySearch) 这样做的原因是,OpenClaw 官方把 Ollama + openclaw onboard 作为最低冲突的本地方案;同时它也支持把 vLLM / LiteLLM / 自定义 OpenAI-compatible 本地代理 作为额外 provider 接进来。Ollama 这边,OpenClaw 明确推荐走原生 http://host:11434,不要给它配 /v1,否则工具调用会变差;而 llama.cppllama-server 则原生提供 OpenAI-compatible chat completions / responses / embeddings 路由,适合当第二套本地后端。([OpenClaw][1])

另外,OpenClaw 的本地模型指南也明确提醒:它默认期待大上下文和较强的提示注入防护,小硬件上的强量化/小模型更容易丢上下文或降低安全裕量。所以在 Jetson Orin NX 16G 上,更稳的策略是把 Ollama 设为主模型,把 llama.cpp 设为 fallback 或专用模型,而不是反过来。([OpenClaw][1])

下面给你一份推荐版模板
特点是 Ollama 走自动发现,你不用手工维护本地模型清单;llama.cpp 作为一个显式自定义 provider 接入;memorySearch 用 Ollama 的 /api/embeddings。OpenClaw 的文档说明,只要设置了 OLLAMA_API_KEY 且没有显式写 models.providers.ollama,它就会从本地 http://127.0.0.1:11434 自动发现模型memorySearch.provider = "ollama" 也是官方支持的,只是不会自动选中,所以这里显式打开。([OpenClaw][2])

先准备环境变量:

exportOLLAMA_API_KEY="ollama-local"exportOPENCLAW_GATEWAY_TOKEN="replace-with-a-long-random-token"

把下面保存为 ~/.openclaw/openclaw.json

{ identity: { name: "Jetson-Claw", theme: "local edge agent", emoji: "🦙", }, gateway: { bind: "loopback", port: 18789, auth: { token: "${OPENCLAW_GATEWAY_TOKEN}", }, }, agent: { workspace: "~/.openclaw/workspace", }, agents: { defaults: { model: { // 主模型:走 Ollama(自动发现) primary: "ollama/qwen2.5:7b-instruct", // 备用:先退到 llama.cpp,再退到另一个 Ollama 小模型 fallbacks: [ "llamacpp/qwen2.5-7b-instruct-gguf", "ollama/llama3.2:3b", ], }, models: { "ollama/qwen2.5:7b-instruct": { alias: "Ollama 主模型" }, "llamacpp/qwen2.5-7b-instruct-gguf": { alias: "llama.cpp 备用" }, "ollama/llama3.2:3b": { alias: "Ollama 小模型" }, }, memorySearch: { enabled: true, // 用 Ollama embeddings,而不是 OpenClaw 的 local(node-llama-cpp) 模式 provider: "ollama", // 换成你本机实际装好的 embedding 模型 model: "YOUR_OLLAMA_EMBED_MODEL", // Jetson 上先不要再级联更多 embedding fallback,保持简单 fallback: "none", cache: { enabled: true, maxEntries: 50000, }, sync: { watch: true, }, }, }, }, models: { // 保留合并模式,未来你还可以叠加云端 provider mode: "merge", providers: { // llama.cpp 作为自定义 OpenAI-compatible provider llamacpp: { baseUrl: "http://127.0.0.1:8080/v1", apiKey: "llama-local", api: "openai-completions", models: [ { id: "qwen2.5-7b-instruct-gguf", name: "Qwen2.5 7B Instruct GGUF", reasoning: false, input: ["text"], cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 }, contextWindow: 4096, maxTokens: 1024, }, ], }, }, }, } 

这个模板的关键点有三个:

第一,Ollama 不写 models.providers.ollama。因为官方文档说,一旦你显式写了 models.providers.ollama自动发现会被关闭,你就得自己维护模型列表;不写则会自动从本地 Ollama 实例发现模型。([OpenClaw][2])

第二,llama.cpp 走 /v1,并用 api: "openai-completions"。OpenClaw 官方对“其他 OpenAI-compatible 本地代理”给的标准接法,就是 models.providers.<id> + baseUrl + api + models 这一套;而 llama.cpp 官方文档确认 llama-server 提供 OpenAI-compatible 路由。([OpenClaw][1])

第三,memorySearch 用 Ollama,不用 local。因为 OpenClaw 文档里写得很清楚:memorySearch.provider = "local" 走的是 node-llama-cpp,可能需要额外的 pnpm approve-builds / pnpm rebuild;而 memorySearch.provider = "ollama" 是官方支持的本地/self-hosted embeddings 路径,更适合先把 Jetson 跑稳。([OpenClaw][3])


启动顺序

先起 Ollama。Ollama 官方 API 默认就在 http://localhost:11434/api。 ([Ollama Docs][4])

ollama serve ollama list 

然后起 llama.cpp

~/src/llama.cpp/build/bin/llama-server \-m ~/models/base/model.gguf \--host127.0.0.1 \--port8080\-c4096\-np1\-ctk q8_0 \-ctv q8_0 

再检查两个后端:

curl http://127.0.0.1:11434/api/tags curl http://127.0.0.1:8080/v1/models 

最后让 OpenClaw 读配置:

openclaw gateway restart openclaw models list openclaw health openclaw gateway status 

如果你想把 Ollama 也改成“显式配置”

只有在这几种情况下才建议这么做:
你要连远程 Ollama、你想强制指定 contextWindow/maxTokens、或者你想完全手工管模型列表。官方文档明确说,远程 Ollama 时应使用 baseUrl: "http://host:11434",不要加 /v1,并把 api 设成 "ollama" 以保证原生工具调用行为。([OpenClaw][2])

对应模板是:

{ models: { mode: "merge", providers: { ollama: { baseUrl: "http://127.0.0.1:11434", apiKey: "${OLLAMA_API_KEY}", api: "ollama", models: [ { id: "qwen2.5:7b-instruct", name: "Qwen2.5 7B Instruct", reasoning: false, input: ["text"], cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 }, contextWindow: 8192, maxTokens: 2048, }, { id: "llama3.2:3b", name: "Llama 3.2 3B", reasoning: false, input: ["text"], cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 }, contextWindow: 8192, maxTokens: 2048, }, ], }, }, }, } 

远程控制这台 Jetson 的模板

OpenClaw 官方建议把 Gateway 绑在 loopback,然后通过 SSH 隧道 从笔记本连进去;默认网关端口是 18789。如果你希望本地电脑上的 OpenClaw CLI 默认连这台 Jetson,可以把 gateway.mode: "remote"gateway.remote.url/token 写进去。([OpenClaw][5])

先在你的笔记本上开隧道:

ssh-N-L18789:127.0.0.1:18789 user@jetson-host 

然后在本地电脑的 OpenClaw 配置里加:

{ gateway: { mode: "remote", remote: { url: "ws://127.0.0.1:18789", token: "your-token", }, }, } 

这样之后本地的 openclaw healthopenclaw status 之类就会默认走这个远程 Gateway。([OpenClaw][5])


两个最容易踩的坑

不要把 OpenClaw 连 Ollama 时写成 http://127.0.0.1:11434/v1 官方文档明确说,这会切到 OpenAI-compatible 模式,工具调用会变得不可靠,模型可能把工具 JSON 当纯文本吐出来。([OpenClaw][2])

不要一开始就把 memorySearch.provider 设成 local 这条路走的是 node-llama-cpp,本地编译和依赖更重;Jetson 上先用 ollama embeddings 更省心。([OpenClaw][3])

后面会陆续加入openclaw gateway安全模式下与ros联动配置。

参考链接:
[1]: https://docs.openclaw.ai/gateway/local-models “Local Models - OpenClaw”
[2]: https://docs.openclaw.ai/providers/ollama “Ollama - OpenClaw”
[3]: https://docs.openclaw.ai/reference/memory-config “Memory configuration reference - OpenClaw”
[4]: https://docs.ollama.com/api/introduction “Introduction - Ollama”
[5]: https://docs.openclaw.ai/gateway/remote “Remote Access - OpenClaw”

Read more

Llama-Factory与LangChain集成:构建智能化Agent工作流

Llama-Factory与LangChain集成:构建智能化Agent工作流 在企业级AI应用的落地过程中,一个反复出现的问题是:为什么通用大模型在实际业务场景中总是“差点意思”?比如客服系统里答非所问、工单处理时无法调用内部API、面对专业术语频频“幻觉”……归根结底,问题不在于模型不够大,而在于它缺乏领域知识和行为规范。 这时候,开发者往往面临两难:要让模型懂业务,就得微调;但传统微调流程复杂、资源消耗大,动辄需要多卡A100集群。更麻烦的是,即使模型训练好了,如何让它真正“动起来”——主动思考、调用工具、完成任务?这正是LangChain这类Agent框架的价值所在。而Llama-Factory的出现,恰好补上了从“静态模型”到“动态智能体”之间最关键的一环。 想象这样一个场景:你正在开发一款面向医疗行业的智能助手。用户提问:“我最近头晕乏力,血压140/90,该吃什么药?”如果直接交给未微调的LLM,答案可能泛泛而谈,甚至推荐错误药物。但如果这个模型已经在数万条真实医患对话上做过指令微调,并且被封装成LangChain Agent,它的行为会完全不同: 首先,它识别出

【Copilot配置避坑手册】:90%新手都会犯的7个致命错误

第一章:Copilot配置的核心认知 GitHub Copilot 不仅是一个代码补全工具,更是一种基于上下文理解的智能编程助手。其核心价值在于通过深度学习模型理解开发者意图,提供精准的代码建议。要充分发挥 Copilot 的能力,首先需建立对其配置机制的正确认知。 身份验证与环境准备 在使用 GitHub Copilot 前,必须确保已完成以下步骤: 1. 登录 GitHub 账户并启用 Copilot 订阅(个人或企业计划) 2. 在本地 IDE(如 VS Code)中安装官方插件 3. 执行身份验证命令以激活服务 # 在终端运行以下命令完成登录 npx @github/copilot-cli login 该命令会打开浏览器页面,引导用户完成授权流程。成功后,Copilot 将在支持的语言环境中自动启动。 编辑器配置优化 为提升建议质量,可在编辑器设置中调整关键参数: 配置项推荐值说明copilot.suggestOnTriggerCharacterstrue在输入特定字符(如

探寻学术纯净新路径——paperxie降重复|AIGC率引领论文优化新潮流

探寻学术纯净新路径——paperxie降重复|AIGC率引领论文优化新潮流

paperxie-免费查重复率aigc检测/开题报告/毕业论文/智能排版/文献综述/aippt https://www.paperxie.cn/checkhttps://www.paperxie.cn/checkhttps://www.paperxie.cn/check 在学术创作的领域中,论文的重复率和AIGC(人工智能生成内容)率问题日益受到关注。无论是学生为了顺利通过学术检测,还是学者追求研究成果的原创性和独特性,降低论文重复率和AIGC率都成为了至关重要的任务。而paperxie降重复|AIGC率功能的出现,宛如一盏明灯,为学术创作者们在追求论文质量与原创性的道路上指明了方向。 一、洞察需求,精准定位功能方向 在当下的学术环境中,论文重复率过高是一个普遍存在的问题。随着互联网信息的爆炸式增长,大量的学术资料、研究成果在网络上传播,学生在撰写论文时,难免会参考和借鉴前人的成果,从而导致论文重复率上升。同时,随着AI技术在写作领域的应用越来越广泛,AIGC内容也逐渐增多。虽然AI生成的内容在一定程度上可以提高写作效率,但过高的AIGC率可能会使论文缺乏原创性和深度,

AIGC 与艺术创作:机遇

AIGC 与艺术创作:机遇

目录 一.AIGC 的崛起与艺术领域的变革 二.AIGC 在不同艺术形式中的应用 1.绘画与视觉艺术 2.音乐创作 三.AIGC 为艺术创作带来的机遇 1.激发创意灵感 2.提高创作效率 总结 在当今数字化时代,人工智能生成内容(AIGC)正以惊人的速度重塑着艺术创作的格局,为艺术家们带来了令人振奋的新机遇。 一.AIGC 的崛起与艺术领域的变革 随着人工智能技术的不断进步,AIGC 逐渐在艺术领域崭露头角。它依托强大的机器学习算法和深度学习模型,能够分析大量的艺术作品数据,并从中学习各种风格、技巧和表现形式。 例如,OpenAI 的 DALL・E 2 是一款强大的图像生成模型。艺术家可以输入描述 “一只穿着太空服的猫在月球上漫步”,DALL・E 2 就能生成一幅非常逼真且富有创意的图像。这一技术突破使得艺术创作不再局限于传统的手工绘制,而是可以通过算法来实现。艺术家们可以利用这些工具来快速探索不同的创意方向,