内容来源：https://blog.n8n.io/token-prices-wont-increase-if-you-host-your-own-llms/

内容总结：

AI成本危机下，自托管大模型成企业新选择

大模型API成本持续攀升，企业面临“天价”账单

随着人工智能技术在各行各业的深入应用，一个不容忽视的问题正浮出水面——我们真的了解一个token（大模型计费单位）的真实成本吗？事实上，当前主流AI提供商的token价格都受到大型科技公司的补贴，多数AI服务商实际上处于亏损运营状态。一旦资金链收紧，服务商不得不回归正常商业模式运作，token价格势必将大幅上涨，而这一趋势已经开始显现。

据业内人士透露，即便是科技巨头微软，也因Claude Code使用成本过高而取消了相关许可证——尽管开发者对其的喜爱程度远超GitHub Copilot。

业务依赖加深，成本敏感度提升

当前，多数组织的业务流程逻辑正深度绑定大语言模型（LLM）。想象一下，一项已投入生产的在线客服智能体，不会因为成本上涨10%就被轻易下架。但如果成本连续上涨三到四次，财务压力就将迫使企业重新审视这一支出。

更为棘手的是，随着智能体逻辑日益复杂——包括工具调用、信息检索、推理过程，甚至智能体选择生成整个网页而非纯文本回复——token消耗量正呈指数级增长。

两条出路：优化用量还是自托管？

面对这一困境，企业面临两种选择：一是持续优化token使用效率以继续使用前沿模型；二是转向自托管开源大模型。

越来越多的技术专家倾向于推荐后者。正如Mitko Vasilev所强调的：“确保你拥有自己的AI。云端的AI并不与你对齐，它只与拥有它的公司对齐。”

开源社区在这一领域已走在前列，构建了多个高质量的LLM开源模型，为企业降低成本提供了可能。知名自动化平台n8n早在两年前便推出了自托管AI入门套件，并将可替换的AI组件作为工作流核心功能，使用户无需重写工作流逻辑即可轻松切换模型提供商。

自托管LLM的五大优势

减少故障点：2026年，Claude服务频繁宕机（截至撰稿时可用性仅为98.64%），而行业标准计算服务的可用性高达99.999%。自托管还能规避网络依赖带来的超时和限流问题。

增强控制力：当企业拥有模型终端时，可以自主决定每个层面的运行策略——控制模型版本、更新时间，不再受限于API提供方所暴露的有限控制选项。

数据隐私保障：提示词与输出结果不会离开自托管环境，除非明确导出，无需担心第三方数据处理条款变更。

可解释性提升：借助TransformerLens、SAEsto等工具，企业可以深入了解LLM内部运行机制，这是云端模型无法实现的。

模型定制与微调：QLora等技术支持模型针对特定任务的定制微调，在某些垂直领域，小型模型在特定任务上的表现可以媲美SOTA级模型，而体积和耗时仅为后者的一小部分。随着OpenAI逐渐弃用微调API，这一优势愈发显著。

自托管的挑战不容忽视

当然，自托管也意味着责任全揽——无法再将服务中断归咎于OpenAI或Anthropic。企业需面对以下挑战：

供应链安全：模型选择、部署和管理均由企业自行负责，存在引入被植入后门的模型的风险，运行时环境本身也伴随安全漏洞。

配置复杂度：无法简单“即插即用”完成基础设施部署。若需超越Ollama的基本功能或将LLM暴露给非n8n服务，就必须自行搭建完整基础设施。

版本更新管理：任何组件更新都可能导致不兼容问题。

性能差距：前沿模型始终代表当前最佳性能，新模型发布通常会在基准测试上超越旧版本。

资源消耗：LLM在模型和缓存之间消耗大量内存，可能引发内存溢出错误，进而影响共享计算层的其他进程。

自托管所需基础设施与工具

自托管并不意味着必须购买昂贵的本地硬件。企业仍可租赁云计算资源，按照自身需求部署LLM。目前市场上GPU即服务（IaaS）提供商包括：

• RunPod：提供GPU Pods（持久虚拟机）和无服务器（按秒计费的推理端点）两种模式
• Lambda Labs：稳定性强、无数据出口费用
• CoreWeave：企业级多节点集群优化，H100按需约4.76美元/小时
• Vast.ai：点对点市场，最低约0.17美元/小时即可使用旧款GPU

主流云服务商同样值得考虑。AWS的EC2实例同时支持CPU和GPU，企业可在现有云环境中直接部署LLM。

推理运行时的选择

其中，llama.cpp支持CPU与GPU架构，是CPU场景首选；vLLM实现连续批处理和PagedAttention技术，适合多工作节点并发调用；Ollama对开发者友好，是n8n自托管AI套件默认运行时；SGLang针对结构化约束生成优化，特别适合需要模型返回有效JSON的工具调用场景。

模型选择的艺术

对于大多数组织而言，在通用硬件上自托管3B-13B参数范围的模型（Q4量化级别）能在性能与资源消耗间取得良好平衡。该范围的模型可在单张消费级GPU或高性能CPU服务器上运行，输出质量足以满足绝大多数业务自动化需求。

目前市场上主流开源模型包括：

• Llama（Meta）：1B-70B参数，参考级开源权重模型家族
• Qwen（阿里）：0.8B-72B参数，代码生成和多语言任务表现突出
• Mistral：7B-22B参数，显存受限环境下的高效选择
• Google Gemma：2B-27B参数，Apache 2.0许可便于商业部署
• Llama 3.2（1B/3B）：专为边缘和CPU部署设计

结语

在token价格持续上涨的背景下，自托管开源LLM正从“可选项”变为“必选项”。这一转变不仅是成本考量，更是关于企业技术自主权的战略决策。正如n8n社区所倡导的：确保你真正拥有自己的AI。

中文翻译：

我们并不真正了解一个token的真实成本。它们由大型科技公司补贴，而且大多数AI提供商都在亏损运营。一旦资金枯竭，提供商不得不像正常企业一样运营，token成本很可能会上涨，就像最近一直在涨的那样。甚至连微软都觉得Claude Code太贵，取消了许可证，尽管开发者对它的喜爱程度超过Github Copilot。
大多数组织正在将业务逻辑依赖于大语言模型。你不会仅仅因为成本上涨了10%就停用生产环境中的聊天支持Agent。但如果成本涨了10%三次或四次，你就需要认真审视财务数据了。
Agent逻辑也越来越消耗token，原因包括工具调用、检索、推理、Agent决定写整个网页而不是用纯文本回复，等等。
接下来你有两个选择：

• 如果想继续使用前沿模型，优化token使用量
• 自行托管大语言模型
  我会主张第二个选择。Mitko Vasilev的标语把道理说得很清楚：
  确保你拥有自己的AI。云端的AI并不与你保持一致；它与其所属公司保持一致。
  n8n在这件事上走在了前列，主要有两个原因：两年前（！！！）就推出的自托管AI入门套件，以及可替换的AI组件是工作流中的核心功能。你可以在不重写这些组件周围工作流逻辑的情况下，替换模型提供商。
  不，但被低估的开源社区构建了多种大语言模型，这样你就可以降低成本。
  为什么自行托管大语言模型很酷
  除了不把支出决策外包给第三方提供商之外，自行托管大语言模型还有一些优势，即：
• 更少的故障点：在2026年，Claude一直在宕机（撰写本文时正常运行时间为98.64%），而你能做的很有限。行业标准的计算服务正常运行时间为五个九，即99.999%。除了对LLM提供商可用性的依赖之外，还存在相关联的网络依赖，你可能会遇到超时或速率限制。
• 更多控制权——当你拥有模型端点时，你可以决定每一层发生什么。你控制运行哪个模型版本以及何时更新，或者是否更新。你不受限于LLM提供商通过API暴露的控制选项。
• 隐私——除非明确导出，否则提示词和输出都不会离开自托管环境。不用担心数据子处理方或第三方提供商更改其数据处理条款。
• 可解释性——有一些工具如TransformerLens或SAEsto可以帮助更好地理解大语言模型的内部机制，这在云端模型上是无法实现的。
• 模型定制和微调——QLora及类似技术可以针对特定任务定制模型，在特定领域，小型模型可以以极小的一部分规模和时间达到与SOTA模型相同的性能。随着OpenAI弃用其微调API，这甚至是一个更大的优势。
  为什么自行托管可能令人头疼
  当服务宕机时，你不能把手指指向OpenAI或Anthropic，所以你必须承担模型基础设施所涉及的一切责任。一些坑可能是：
• 供应链安全：选择、部署和管理模型将成为你的责任，这意味着你有责任识别带后门的模型。运行时也自带一系列漏洞。
• 搭建和配置：你不能靠“氛围编程”来部署基础设施。例如，虽然AI入门套件很容易启动，但如果你想超越Ollama，或者想把LLM暴露给非n8n服务，你就需要搭建基础设施。这取决于你是在本地机器、组织硬件上自托管，还是使用云提供商的算力。
• 管理破坏性变更。更新任何组件后它可能就不再工作了。这里有一些破坏性变更的示例。
• 性能——前沿模型是当今性能最好的模型。迄今为止，新发布的模型在基准测试中总是优于旧模型。
• 资源利用——大语言模型在模型和缓存之间消耗大量内存，可能导致内存不足错误，从而杀死Agent以及其他共享计算层（没有隔离）的进程。
  你需要在本地运行大语言模型需要什么？
  假设你正在编写Agent并使用n8n暴露它们，你将管理的下方各层包括基础设施（及操作系统）、模型运行时和模型本身。
  基础设施
  仅仅因为自托管，并不意味着你必须在本地机器上运行，等六个月拿到H100，然后在办公室找个储物间，或者去Equinix租几个机架。你仍然可以租用计算和存储，按照自己的条件在云基础设施上部署大语言模型。
  对于基于GPU的IaaS，你可以从以下非穷尽列表中选择：
• RunPod同时提供GPU Pods（持久虚拟机）和Serverless（按秒计费的推理端点），覆盖从开发到生产部署的全谱系。
• Lambda Labs是稳定专用实例的首选，无数据出口费用——如果你的工作流需要将大量补全结果回传到本地n8n安装，这是一个显著优势。
• CoreWeave提供针对大型多节点集群优化的企业级基础设施。H100按需价格约为每小时4.76美元，承诺容量可享受批量折扣。

• Vast.ai通过点对点市场提供最低的标价，较老的GPU从约每小时0.17美元起。 超大规模云服务商也是很好的选择。如果你已经在超大规模云中运行n8n，你可以考虑在现有环境中托管LLM。例如，AWS的EC2同时提供CPU和GPU实例。 是的，你基本上只是把支出从一个提供商转移到另一个提供商，并承担运维负担，但请记住前提——token价格是随意的。Token没有市场价值，所以它们很容易暴涨。而基础设施即服务则是一个竞争激烈且成熟的空间。如果GPU租用价格上涨风险太大，你总还有在CPU上运行大语言模型的选项。 推理运行时 运行时提供不同的服务大语言模型机制，最值得注意的是它们是运行在CPU还是GPU上。其他考虑因素包括模型格式（如GGUF或safetensor），以及较新的模型是否会被所有现有运行时支持。Ollama是一个全能型运行时，你可以从它开始。	运行时	CPU	GPU	最适合
  llama.cpp	是	是	开发/低流量
  Ollama（封装llama.cpp）	是	部分	n8n默认
  vLLM	否	是	高并发
  SGLang	否	是	JSON/工具调用
  ExLlamaV3	否	是	显存受限
  Intel IPEX-LLM	是	部分	Xeon/Arc硬件
  LM Studio	是	部分	仅限评估/开发

• llama.cpp同时支持基于CPU和GPU的架构，但一直是CPU用例的首选。它是一个高度可移植的参考运行时。它支持AVX2、AVX-512和ARM NEON指令集，完全无GPU依赖即可运行，也是Ollama底层所使用的。它是开发环境和低流量部署的正确选择。
• vLLM是生产级、GPU优化的服务器。它实现了连续批处理和PagedAttention，当多个n8n工作线程同时触发AI Agent节点，且你需要GPU高效处理并发请求而不是串行化时，它是一个好的选择。
• Ollama是面向开发者的入口。它在干净的API后面封装了llama.cpp，负责模型生命周期管理，也是n8n自托管AI入门套件默认面向的运行时。它用一定的性能上限换取了显著更低的运维摩擦。
• LM Studio提供用于运行本地模型的桌面GUI。对于想在不用终端的情况下进行实验的内部团队来说很有用，但并非为无头服务器部署而设计。
• SGLang针对结构化约束生成进行了优化。它特别适用于需要模型返回有效JSON的n8n工具调用节点——这类失败在通用推理服务器上比应有的频率更高。
• ExLlamaV3在NVIDIA硬件上将量化效率推到了比大多数替代方案更高的水平。其主要价值在于将更大的模型装入有限的显存预算。
  模型选择
  高参数模型会更像Anthropic和OpenAI等提供的基础模型，但资源消耗大。大多数组织在通用硬件上自托管3B–13B参数范围、Q4量化的模型时，可以在性能和资源消耗之间取得良好平衡。该范围内的模型可在单块消费级GPU（或一台够用的CPU服务器）上运行，产出质量足以满足大多数业务自动化任务，并且上下文处理时间足够短，可在交互式工作流中实际使用。
  除了文本生成本身，模型大小还会影响函数或工具调用的质量，相关评估可在此处查看。
• Llama（Meta）（1B-70B）是参考性的开放权重模型系列。Llama 3.x模型是强大的通用选择，得到堆栈中每个运行时的良好支持，并且许可证允许大多数组织商业使用。8B和70B变体是部署最广泛的。
• Qwen（阿里巴巴）（0.8B – 72B）在代码生成和多语言任务方面特别强。Qwen2.5-Coder变体在工具调用Agent方面与更大的通用模型具有竞争力，Qwen3.5系列将范围扩展到适合路由和分类任务的亚1B模型。
• Mistral（7B – 22B）提供高效的7B–22B中尺寸模型。当GPU显存受限且你需要一个能力不错的通用模型而不想用到70B时，Mistral Nemo和Mixtral（专家混合架构）是不错的默认选择。
• Google Gemma 3 / Gemma 4（2B – 27B）——最小的Gemma 4变体（2B和4B有效参数）在现代硬件上以4-bit量化运行时大约占用5 GB内存。Apache 2.0许可证使商业部署非常直接。
• Qwen 3.5 Small（0.8B–9B）——Qwen3.5系列涵盖0.8B到9B参数，具有256K上下文窗口并支持201种语言。它提供思考和非思考模式，当你想为简单任务抑制思维链推理以节省token时非常有用。适合多语言n8n部署。
• Meta Llama 3.2（1B、3B）——专门为边缘和CPU部署设计。1B变体在Q4下占用不到1 GB，适合n8n工作流中的轻量级分类和路由任务——决定文档走哪个分支、提取少量结构化字段、标记传入记录。
• SmolLM3-3B（HuggingFace）——在3B规模上，它优于Llama 3.2 3B和Qwen 2.5 3B，同时在广泛的基准测试中与4B级替代品保持竞争力。HuggingFace发布了完整的工程蓝图，包括架构决策、数据混合和后训练方法论。
  使用n8n自托管
• 使用开源大语言模型（通过HuggingFace）
• 私有及本地Ollama自托管 + 动态LLM路由器
• 使用n8n和Ollama与本地LLM聊天
• 使用Ollama AI、Agentic RAG和PGVector进行本地文档问答
• 使用Ollama AI处理法律文档并生成HTML报告（100%本地）
• 使用检索增强生成（RAG）的本地聊天机器人

英文来源：

We don’t know how much a token really costs. They are subsidized by big tech and most AI providers are operating at a loss. Once funds dry up and providers will have to operate like a normal business, token costs will very likely increase, like they have been recently. Even Microsoft has found Claude Code to be too expensive and canceled its licenses, despite it being preferred by developers over Github Copilot.
Most organizations are getting their business logic dependent on LLMs. You won’t decommission your in-production chat support Agent just because costs went up 10%. But if they go up 10% three or four times, you will need to take a closer look at financials.
Agent logic is also increasingly token-heavy due to tool calls, retrievals, reasoning, agents deciding to write a whole webpage instead of responding in plain text, etc.
You’ve got two options going ahead

• Optimizing your token usage if you want to continue using frontier models
• Self-host LLMs.
  I would advocate for the second option. Mitko Vasilev’s tagline makes the case clear
  Make sure you own your AI. AI in the cloud is not aligned with you; it's aligned with the company that owns it.
  n8n was ahead of the curve with this one for two main reasons. The self-hosted AI starter kit that was launched over two years ago (!!!), and swappable AI components is a core functionality in a workflow. You can swap the model provider without rewriting the workflow logic that sits around those components.
  No, but the underappreciated open source community built multiple LLMs so you can reduce costs.
  Why self-hosting your LLMs is quite cool
  Besides not outsourcing your spend decisions to a third-party provider, you also have some advantages for self-hosing LLMs, namely:
• Fewer points of failure: in 2026, Claude’s been down all the time (98.64% uptime at the time of writing) and there isn’t much you can do about it. An industry-standard compute service has an uptime of five nines, 99.999%. Besides dependency on LLM provider’s availability, there is a correlated network dependency, where you may hit timeouts or rate limits.
• Additional controls - When you own the model endpoint, you decide what happens at every layer. You control which model version is running and when it gets updated, or whether it gets updated at all. You are not limited by which controls LLM providers expose via APIs.
• Privacy - neither prompts nor outputs will leave the self-hosted environment unless explicitly exported. There are no concerns about data subprocessors or third party providers changing their data processing terms.
• Interpretability - there are tools such as TransformerLens or SAEsto which can help better understand an LLMs internals, which cannot be achieved with cloud models.
• Model customization and finetuning - QLora and similar technologies allow to customize a model for a specific task to the point where, in specific domains, a small model can get to the same performances as SOTA models at a fraction of the size and time. This is even a bigger advantage as OpenAI has deprecated their finetuning APIs.
  Why self-hosting can be a headache
  You can’t point your finger at OpenAI or Anthropic when services are down, so you have to take responsibility for all the model infrastructure entails. Some gotchas can be:
• Supply chain security: it will be your responsibility to choose, deploy, and manage models, which means you are liable to pull backdoored models. Runtime also comes with its own set of vulnerabilities.
• Setup and configuration: You can’t really vibe code your infrastructure deployment. While, for example, the AI starter pack makes it easy to spin up, if you want to go beyond Ollama or want to expose the LLM to non n8n services, you need to set up the infrastructure. This differs if you self-host on your local machine, organization hardware, or use a cloud provider for the compute.
• Managing breaking changes. Update any component and it may no longer work. See examples of breaking changes here.
• Performance - frontier models are the best-performing models today. New model releases have so far always outperformed older ones on benchmarks.
• Resource utilization - LLMs eat a lot of memory between model and cache, which can cause out-of-memory errors that might kill agents and other processes that run share the compute layer (without isolation).
  What do you need to run LLMs locally?
  Assuming you are writing agents and exposing them using n8n, the layers below that you will manage include infrastructure (and operating system), model runtimes, and the model.
  Infrastructure
  Just because you’re self-hosting, doesn’t mean that you have to run it on your local machine, wait six months to get your H100s and then find some closet space in your office or go to Equinix and lease a couple of racks. You can still lease compute and storage, and deploy your LLMs on the cloud infrastructure on your terms.
  For GPU-based IaaS, you can choose from this non-exhaustive list:
• RunPod offers both GPU Pods (persistent VMs) and Serverless (pay-per-second inference endpoints), covering the full spectrum from development to production deployment.
• Lambda Labs is the go-to for stable, dedicated instances with no data egress fees — a significant advantage if your workflows push large volumes of completions back to an on-premises n8n installation.
• CoreWeave provides enterprise-grade infrastructure optimised for large multi-node clusters. H100s run at approximately $4.76/hour on-demand, with volume discounts for committed capacity.

• Vast.ai offers the lowest headline prices, from around $0.17/hour for older GPUs, through a peer-to-peer marketplace, Hyperscalers are also a great option. If you’re already running n8n in a hyperscaler, you may just explore hosting an LLM in your existing environment. AWS, for example, offers both CPU and GPU for EC2. Yes, you are essentially just moving spend from one provider to another and taking on the operation burden, but remember the premise - token prices are arbitrary. There is no market value for a token, so they can easily skyrocket. Infrastructure-as-a-service on the other hand is a highly competitive and mature space. If GPU rental increases pose too big a risk, you always have options for running LLMs on CPUs. Inference Runtimes Runtimes have different mechanisms for serving LLMs, most notably whether they run on CPU or GPU. Other considerations include model formats (such as GGUF or safetensor), and whether newer models will be supported on all existing runtimes. Ollama is an all-purpose runtime that you can start with.	Runtime	CPU	GPU	Best for
  llama.cpp	Yes	Yes	Dev / low-traffic
  Ollama (wraps llama.cpp)	Yes	Partial	n8n default
  vLLM	No	Yes	High concurrency
  SGLang	No	Yes	JSON / tool calls
  ExLlamaV3	No	Yes	VRAM-constrained
  Intel IPEX-LLM	Yes	Partial	Xeon / Arc HW
  LM Studio	Yes	Partial	Eval / dev only

• llama.cpp supports both CPU- and GPU-based architectures, but has been the preferred option for CPU-based use cases. It's a highly portable reference runtime. It supports AVX2, AVX-512, and ARM NEON instruction sets, runs with zero GPU dependency, and is what Ollama uses under the hood. It is the right choice for development environments and low-traffic deployments.
• vLLM is the production-grade, GPU-optimised server. It implements continuous batching and PagedAttention, making it a good choice when multiple n8n workers are firing AI Agent nodes simultaneously and you need the GPU to handle concurrent requests efficiently rather than serialising them.
• Ollama is the developer-friendly entry point. It wraps llama.cpp behind a clean API, handles model lifecycle management, and is what the n8n self-hosted AI starter kit targets by default. It trades some performance ceiling for considerably lower operational friction.
• LM Studio provides a desktop GUI for running local models. It is useful for internal teams who want to experiment without a terminal, but is not designed for headless server deployments.
• SGLang is optimised for structured and constrained generation. It is particularly relevant for n8n tool-calling nodes that require valid JSON back from the model — a category of failure that is more common than it should be with general-purpose inference servers.
• ExLlamaV3 pushes quantisation efficiency further than most alternatives on NVIDIA hardware. Its primary value is fitting larger models into a limited VRAM budget.
  Model Choices
  High parameter models will behave more like the foundational models provided by the likes of Anthropic and OpenAI, but are resource-intensive. Most organizations can achieve a good balance between performance and resource consumption when self-hosting on general-purpose hardware with 3B–13B parameter range models at Q4 quantisation. Models in this range run on a single consumer GPU (or a capable CPU server), produce output quality sufficient for the majority of business automation tasks, and have short enough context processing times to be viable in interactive workflows.
  Besides text generation itself, model sizes have an impact on the quality of function or tool calling, which is evaluated here.
• Llama (Meta)(1B-70B) is the reference open-weight family. Llama 3.x models are strong general-purpose choices, well-supported by every runtime in the stack, and available under a licence that permits commercial use for most organisations. The 8B and 70B variants are the most widely deployed.
• Qwen (Alibaba) (0.8B – 72B) is particularly strong on code generation and multilingual tasks. The Qwen2.5-Coder variants are competitive with much larger general models for tool-calling agents, and the Qwen3.5 series extends the range down to sub-1B models suitable for routing and classification tasks.
• Mistral (7B – 22B) offers efficient mid-size models in the 7B–22B range. Mistral Nemo and Mixtral (a mixture-of-experts architecture) are good defaults when GPU VRAM is constrained and you need a capable general-purpose model without reaching for a 70B.
• Google Gemma 3 / Gemma 4 (2B – 27B) — The smallest Gemma 4 variants (2B and 4B effective parameters) run at approximately 5 GB of RAM with 4-bit quantisation on modern hardware. The Apache 2.0 licence makes commercial deployment straightforward.
• Qwen 3.5 Small (0.8B–9B) — The Qwen3.5 series spans 0.8B to 9B parameters with a 256K context window and support for 201 languages. It offers thinking and non-thinking modes, which is useful when you want to suppress chain-of-thought reasoning for simple tasks to save tokens. Strong for multilingual n8n deployments.
• Meta Llama 3.2 (1B, 3B) — Designed explicitly for edge and CPU deployment. The 1B variant fits in under 1 GB at Q4 and is suitable for lightweight classification and routing tasks inside n8n workflows — deciding which branch a document goes down, extracting a small set of structured fields, tagging incoming records.
• SmolLM3-3B (HuggingFace) — At the 3B scale it outperforms Llama 3.2 3B and Qwen 2.5 3B while staying competitive with 4B-class alternatives across a broad set of benchmarks. HuggingFace published the full engineering blueprint including architecture decisions, data mixture, and post-training methodology.
  Self-host with n8n
• Use an open-source LLM (via HuggingFace)
• Private & local Ollama self-hosted + dynamic LLM router
• Chat with local LLMs using n8n and Ollama
• Local document question answering with Ollama AI, Agentic RAG & PGVector
• Process legal documents with Ollama AI & generate HTML reports (100% local)
• Local chatbot with retrieval augmented generation (RAG)