抡锤者

@南亚阿东 我昨天也自己试了很多7900xtx的吐字速度测试，虽然跟并发无关。发现ai 自己测试时数字不太准，他自己说他没开mtp。 我最后总结出来的最有用的设置： MTP 设置你可以抄论坛的帖子， 减核心电压-50mv， 显存超频到1350（linux里显示这个数字好像和网上查的不一样，可能网上是windows）。 这样跑起来是又安静又快。 另外不知道为什么我的蓝宝石卡出厂默认功率限制在303w，我没动他，AI告诉我linux统计功率的方法不一样。

问题不在 N8N，在于你让应用层直接并发打 Ollama。单卡 24G 跑 27B dense 时本来就只有 1 路能做，多个请求同时进来会互相抢显存，谁都不够，最后一起超时。 正确做法是在 Ollama 前面加一个真正的队列，串行喂： 队列层：Redis list（LPUSH 投递 / BRPOP 消费）或 RabbitMQ 都行。N8N 两种接法： 简单版：一个触发器 + Redis 节点，worker 循环 BRPOP，天然 FIFO，一次只发一个 Ollama 请求； 正式版：N8N 开 Queue mode（主进程 + worker），把 worker 并发设为 1。 关键参数： OLLAMA_NUM_PARALLEL=1、OLLAMA_MAX_LOADED_MODELS=1，把显存留给单任务； OLLAMA_KEEP_ALIVE 调大（如 2h 或 -1），避免任务间隙反复加载 27B； 队列层设任务级超时。你的任务 10–240 分钟，别用 N8N 默认 5 分钟，会把长任务中间掐掉。 重试放在队列层做，别让模型层重试。你「模型重试几次后停止、两个任务都超时」就是重试风暴把队列打爆了。任务要幂等，失败能重入。 分工：YouTube 字幕抓取是网络/IO 任务，和推理分开两个 worker 队列，否则抓取卡住会占着推理位。推理队列并发=1，抓取可以多并发。 结果落盘 + 通知：每个 Goal 完成写结果文件（或发 Telegram/webhook），早上直接看目录。 想再省心，把 Ollama 换成 SGLang/vLLM 起服务，它们自带请求队列 + continuous batching，就是为多请求场景设计的；Ollama 在这块确实弱。

@Fan-Rex 这里有个概念要拆开，你说的"64K 最低要求"和我说"32-64K 就够"，其实讲的是两个不同的 context，不冲突： 我说的是 Ollama 侧的 num_ctx（KV cache 上下文），管的是"模型一次能吃多长的 prompt + prefill 要算多久"。这个值你设 128K，单卡 7900XTX prefill 一轮就是 5 分钟起步；砍到 32K，prefill 成本直接减半以上。它纯粹是本地推理的开销设置，没有"最低要求"这回事。 你说的 Hermes 的 context 是 Agent 框架侧自己的上下文窗口（context_length），默认 64K，但那是默认值不是最低值。Hermes 的 context.engine 是 compressor（压缩模式）：对话超限时它会把历史压缩掉再继续，而不是报错拒绝。所以 32K 的 context_length 一样能跑，只是历史更早被压缩。 真正要联动的是这两者：Hermes 的 context_length 必须 ≤ Ollama 的 num_ctx，否则 Hermes 发过来的长对话会被 Ollama 静默截断。所以正确姿势是——Hermes 端设 32K 或 64K（按任务需求），Ollama 端 num_ctx 跟着设到 ≥ 这个值，而不是无脑 128K。 回到你这组测试：128K 是压力测试场景，实际 Agent 干活根本用不满。把两边的 context 协调好，32-64K 的配置在 7900XTX 上能省掉大量 prefill 等待，这才是"够用"的准确含义。