# 在做一种让本地 LLM 共享上下文而不必集中化一切的方式 - 原标题：Working on a way for local LLMs to share context without centralizing everything - 类型：帖子 - 来源：Reddit - 发布时间：2026-10-29 - 首次精选：2026-10-29 09:33 - 分级：值得看 - 学习层级：进阶 - 主题：[ai-privacy-governance]()（第 11 位）、[agent-context-memory]()（第 21 位） - 原文链接：[https://reddit.com/r/LocalLLaMA/comments/1xhsj1i/working\_on\_a\_way\_for\_local\_llms\_to\_share\_context]() - 本站页面：[https://oplearnx.com/resources/pk\_8ca0b978268c]() ## 摘要 这是一篇 Reddit r/LocalLLaMA 社区帖子，作者描述多人或多台机器使用本地模型时共享上下文的困难（重复 embeddings 或向量库、手动搬运上下文、引入中心服务），并介绍他们正在试验的一个小型可移植上下文层，让有用的事实或决策能在本地环境之间转移而不必随带整个底层数据集。作者还提到目前仍处早期，正在讨论来源追溯、权限、过期上下文和模型可记忆范围等问题，并向读者询问在跨机器或团队场景下如何处理共享上下文。适合在多台机器或团队中部署本地模型、关心本地上下文共享方案的人阅读。 ## 原帖 > If you use local models across more than one machine or with a team, how are you handling shared context today? Do you even want models sharing memory or context between environments or is keeping every local setup completely isolated actually part of the appeal? — recent\_immunization · 2026-10-29 · [原帖]() ## 中文大意 发帖人观察到本地 LLM 在多机或多人协作时的痛点：模型和文件都是本地的，但一旦需要共享同一份上下文，就得复制 embedding/向量库、手动搬运上下文，或者引入集中服务，而后者违背了本地运行的初衷。他们正在试验一个可移植的“上下文层”，只让有用的事实和决策在本地环境间流动，而不搬运整个底层数据集，目前仍在争论溯源、权限、过期上下文以及模型该被允许记住多少。帖子附了一个 Kibu pod 供讨论构建。发帖人主要想问：在多机或团队里用本地模型的人现在怎么共享上下文？是否真的希望模型在环境间共享记忆，还是完全隔离本身就是本地化的吸引力所在。适合关注本地 LLM 部署、多机协作与上下文管理的开发者阅读。 ## 讨论区核心观点 依据 17 条评论。 - 用 git/gitea 做共享上下文的传输层效果不错，无需重造轮子；但合并冲突是主要痛点，有人因此转向带时间戳的单一 JSON 文件加人工审核。（[出处]()） - 发帖人追问 context 在机器间漂移时如何处理合并冲突，有人反问应先弄清漂移的成因。（[出处]()） - 有回复者已用 Pijul 补丁构建只追加的共享上下文图，节点带所有权标签控制可读可编辑，可按子树组织权限；代码变更还能顺流传播并标记过期内容待审。（[出处]()） - 用 Obsidian vault 加 MCP 接口替代 git：文档写入原子化、无合并冲突，并做插件按项目在启动时注入记忆索引、在提示到达模型前检索相关笔记。（[出处]()） - 认为共享上下文本质是数据库问题：若需共享，集中式单一事实源是唯一不会失控的方案，但集中不等于单点故障或买云服务；若要去中心化应先读分布式数据库文献。（[出处]()） - 主张节点式共享：每个本地环境发布带来源、时间戳和可见范围的小型签名声明，各自决定接受什么，过期需续期，撤销可阻止后续读取，溯源应最先做对；另一派做法是用 LMCache \+ vLLM 在同模型实例间共享 KV 上下文。（[出处]()） --- 来源：LearnMap · 学径（https://oplearnx.com）