Lemonade 工作组治理体系：社区驱动路线图的章程、分工与实施路径

• 大模型
• 本地部署
• 模型推理服务
• 人工智能
• AI 应用
• 后端
• 多模态

Lemonade 是一个社区驱动的开源项目，其技术路线图由一组**工作组（Working Groups）**共同定义和推进。本文以 docs/dev/working-groups/README.md 为核心，系统讲解工作组的章程（Charter）机制、审批治理规则、维护者分工，并逐一拆解 Auto-Tune、Cross-Vendor、Enterprise Grade 等活跃工作组与已归档的 Omni Models 工作组的目标与路线图，同时结合仓库源码（bench命令、auto_tune.h、system_info.cpp等）说明这些规划背后的既有技术基础，帮助读者理解 Lemonade 的演进逻辑并找到参与切入点。

工作组是什么：社区驱动路线图的组织单元

Lemonade 的路线图并非由单一团队自上而下制定，而是由一组工作组分别主导。每个工作组由一位维护者（maintainer）担任 Lead，在其**章程（Charter）**定义的范围内运作，并组织贡献者共同实现其目标。

工作组与项目整体维护的关系在 docs/dev/contribute.md 中有清晰界定：工作组的路线图开发是端到端项目维护与支持的子集。也就是说，工作组的重点在于路线图的前向开发，而整个项目的日常维护、问题响应、发布支持等仍然由全体维护者共同承担。

从开发流程看，docs/dev/spec-driven-dev.md 将 RFC 划分为三个层级，其中第一层级就是"工作组提案（Working group proposal）"：工作组定义了跨多个发布周期、由多人协作的大规模范围扩展，因此提议成立新工作组的 RFC 需要经过众多项目维护者的评审。反过来，一旦某个 RFC 被批准为章程，任何完全落在章程范围内的 PR 都无需再单独发起 RFC——这是工作组机制降低协作摩擦的核心设计。

Charter 章程机制：目标、对齐与变更

每个工作组的章程（Charter）遵循以下规则：

• 提出方式：章程首先在 RFC 讨论 中提出，随后提交到docs/dev/working-groups/目录固化。
• 内容要求：每份章程应有清晰的目标，并与项目整体的 project philosophy（项目哲学） 保持一致。理想情况下，章程应包含可衡量的目标和明确的"终态（end state）"，但由于 AI 领域变化极快，并非总能做到——维护者被要求在其推进过程中持续更新路线图以反映实际进展。
• 与 RFC 的关系：完全在章程范围内的 PR 不需要自己的 RFC；只有改变章程范围时才需要新的 RFC。

这里值得强调项目哲学中的几个设计准则，它们直接约束着工作组的章程制定：

• Lemonade is the Foundation：Lemonade 是"地基"而不是"房子"，用户可以从 GUI 入门，再连接其他应用，最终将 Lemonade 嵌入自己的应用——这与 Cloud Hybrid、Remote Use 工作组的"智能路由"和"远程推理"目标一脉相承。
• Prioritize the Happy Path：高级功能不应给新用户增加摩擦，这正好解释了 Auto-Tune 工作组"开箱即用、自动获得良好性能"的目标为什么是项目级优先事项。
• Standards are Intuitive：尽量遵循 OpenAI API、VS Code GUI、Ollama CLI 等既有标准，这也是各工作组在设计接口与 CLI 行为时的重要约束。

治理与审批：谁来批准章程

工作组的章程由项目负责人@jeremyfowers批准，审批时按顺序考量两个主要因素：

1. 确保本地 AI 软硬件生态的整体健康（overall health of the local AI HW/SW ecosystem）；
2. 社区绝大多数成员的正面反馈（positive feedback of a supermajority of the community）。

原文也明确说明：未来可能采用更成熟的治理模型（"We may adopt a more sophisticated governance model in the future"），当前机制是一个可持续演进的起点。

维护者（Maintainers）分工

完整的项目维护者名单及其维护领域见 docs/dev/contribute.md#maintainers。维护者表按"Admin 管理员 + 学科领域"组织，例如：

• @jeremyfowers（Admin）：新端点、新后端、大型新功能、GUI 设计语言、新 CLI 命令、网站、治理、Lemonade Mix（LMX）omni 模型、CI；
• @kenvandine（Admin）：snaps、Linux、新后端、硬件厂商支持、Nvidia CUDA、ARM；
• @ramkrishna2910（Admin）：新后端、新模态、vLLM、whisper、stable diffusion、智能路由与编排、云 API 集成、NPU；
• @bitgamma：thenoise、CLI、recipes、新后端、benchmarking、新模型（同时是 Auto-Tune 工作组负责人）；
• @Geramy：sockets、TCP/IP、UDP、命名管道、mac、安全、Nexus mesh compute（同时是 Remote Use 工作组负责人）。

工作组是"聚焦的路线图开发领域"，是上述端到端维护与支持的一个子集——贡献者应利用维护者的领域知识作为设计起点，PR 也最好至少有该领域一名维护者深度评审。

工作组总览

当前活跃的 6 个工作组与 1 个已归档工作组如下（信息来自 docs/dev/working-groups/README.md）：

活跃工作组

已归档工作组

活跃工作组详解与路线图

以下各节按 docs/dev/working-groups/ 下的章程文档逐一展开，并结合仓库源码说明规划背后的既有技术基础。

Auto-Tune 工作组：让机器自己找到最佳运行参数

负责人：Michele Balistreri（GitHub 上为 @bitgamma，Discord 上为 @mikkoph）。

背景与动机：把模型跑得好，需要选对后端并调优批量大小（batch size）、GPU 层卸载（GPU layer offload）、线程数（thread count）、上下文大小（context size）等性能参数。目前用户要么靠猜、要么翻 Reddit 帖子、要么问 LLM——这些方式容易出错，而且往往因知识截止而过时。Lemonade 已经具备两样关键基础设施：

1. bench命令：跨后端与参数组合测量 TTFT（首 token 延迟）、TPS（每秒 token 数）与 VRAM 占用；
2. recipe 系统：定义每个模型的配置。

缺少的是一种把基准测试数据转化为"可自动应用的、感知硬件的默认值"的机制。最终目标是：用户安装 Lemonade 后无需理解后端参数、也无需手动跑基准，拉取模型并加载即可获得良好性能——硬件感知的默认值降低了入门门槛，也让 Lemonade 在与"性能已被抽象掉"的云方案竞争时不落下风。

目标：通过检测机器硬件画像（hardware profile）并应用社区验证过的性能参数，让 Lemonade 实例自我优化模型与后端。终态是：用户拉取模型并加载后，Lemonade 自动为其硬件选出最佳后端与调优参数，同时保留手动覆盖或微调的能力。

贡献方式：先阅读通用 contribution guidelines（贡献指南），然后通过 Discord 联系 @mikkoph 讨论路线图后再开始。

范围界定：本工作组聚焦由硬件特性决定的性能参数（批量大小、GPU 层数、线程数、上下文大小、后端选择）。质量类参数（temperature、top_p、chat template 等）属于模型或用例相关，明确不在范围内。

五阶段路线图

Phase 1：Archetype 检测与 Profile Schema

• 定义硬件原型（archetype）分类逻辑。Archetype 由 GPU 家族/架构、VRAM 容量分桶、内存带宽层级、内存是否统一（unified）或分立（discrete）来标识——这使 profile 空间有界：两个 archetype 相同的机器得到相同的推荐。
• 设计 profile JSON schema：profile 将 archetype ID 映射到每个后端的推荐性能参数。示例：strix-halo-128gb→{ "llamacpp_backend": "vulkan", "llamacpp_vulkan_args": { "-b 2048 -ub 1024" }, "vllm_args": { ... } }。schema 与后端无关，可适用于 llama.cpp、FastFlowLM、vLLM、RyzenAI 及未来后端。
• 在lemond中实现 archetype 检测，复用system-info端点已收集的数据（GPU 名称、VRAM、带宽、统一/分立内存）。
• 发布一批手工整理（hand-curated）的常见硬件配置 profile（如 Strix Halo、Radeon 780M、Apple M3）。

Phase 2：加载时自动应用（Auto-Apply at Load Time）

• 启动时lemond检测机器 archetype 并缓存。
• 加载模型时，router 检查是否有 archetype 专属 profile 覆盖，并将其合并进模型的 recipe options。降级链保证优雅退化：精确 archetype + 模型 overlay → archetype 的后端默认值 → recipe 默认值（当前行为）。
• 可选的 per-model overlays 允许在全局 archetype 默认值之上做模型专属调优（同一硬件上某些模型需要不同参数的情况）。
• lemonade status显示检测到的 archetype 与任何生效的 auto-tune 覆盖。
• CLI 或配置选项可启用/禁用 auto-tune（默认启用）。

Phase 3：Profile 分发

• Profile 在运行时从远端源拉取，无需重装 Lemonade 即可更新；同时随 Lemonade 捆绑一组默认 profile 作为无网络时的回退。
• Profile 缓存本地存储并带版本号；过期 profile 定期重新拉取。
• lemonade bench --submit从本地基准运行生成结构化基准贡献；提交流程（上传端点、基于 PR 的贡献或其他方式）将根据基础设施研究来设计。

Phase 4：社区数据收集与策展

• 开发把社区提交的基准合并进策展 profile 的工具：按场景挑选表现最好的参数集、验证跨提交的一致性、检测离群值。
• 编写贡献流程文档，让社区成员能为自己的硬件跑基准并提交结果。
• 使 profile 覆盖所有受支持后端上的广泛硬件 archetype。

Phase 5：自适应调优（Adaptive Tuning）

• 运行时监控：若观测到的性能（TPS、TTFT）与 profile 预期显著偏离，lemond可建议重新基准或标记该 profile 待审查。
• "Learn from this run"：会话结束后，提供把本地观测到的好参数保存进用户配置以持久化。
• 其余内容待上述阶段的经验积累后继续定义。

仓库中的技术基础

Auto-Tune 的规划在仓库中已有部分落地。最直接的是 src/cpp/include/lemon/auto_tune.h，其中实现了上下文大小的自动解析（auto-resolve ctx_size）：

• resolve_auto_ctx_size()读取有效选项中的ctx_size；若为-1则触发自动解析，否则返回-2（无需解析）。
• get_available_memory_gb()按设备类型（GPU/CPU/NPU）计算可用内存：GPU 用 VRAM（iGPU 含 GTT），CPU/NPU 用系统 RAM，Apple Silicon 用统一内存池（virtual_gb），AMD iGPU 用vram_gb + virtual_gb近似，dGPU 用 GTT 代理——这与 Phase 1 中"统一 vs 分立内存"的 archetype 维度直接对应。
• compute_auto_context_size()优先读取 GGUF 元数据（block_count、head_count_kv、key_length，含滑动窗口注意力 SWA 的分层 KV head 细分），缺失时按模型参数量级估算每 token KV cache 字节（128KB/token 至 768KB/token），再由"可用内存 − 模型权重"推算最大上下文，并夹取到模型声明窗口或AUTO_CTX_UNKNOWN_MAX = 32768；嵌入模型有EMBEDDING_CTX_SIZE = 8192的下限，无解时回退到AUTO_CTX_FALLBACK = 4096。

该头文件被 src/cpp/server/server.cpp 与 src/cpp/server/router.cpp 引用；router 中还针对内存受限系统对 NPU 模型的 auto-tune 行为做了专门处理（见 router.cpp 第 1010 行附近注释），说明自动调优已进入实际的模型加载决策链路。

而bench命令是 Phase 3/4 数据收集的基础。其详细用法见 docs/guide/cli.md：lemonade bench MODEL_NAME...通过POST /api/v1/chat/completions请求测量 TTFT 与 TPS，支持--backend、--ctx-size、--runs、--warmup、--scenarios、--scenario-file、--json、--output、--compare、--llamacpp-args等参数；场景文件 JSON 支持 chat/coding/long-context/embed/vision 等类别（vision 场景需image_path且必须与场景文件同目录）。实现上，src/cpp/cli/bench.cpp 从服务端响应的decoding_speed_tps、predicted_per_second字段提取 TPS，从stats.vram_gb提取 VRAM，并提供 tps 的 mean/min/max/p50/p95 与vram_peak_gb()聚合——这些正是 Auto-Tune profile 所需的原始度量。lemonade bench --submit（Phase 3）尚未在 docs/guide/cli.md 中列出，属于规划中的能力。

Cross-Vendor Support 工作组：全平台支持

负责人：Ken VanDine（GitHub 与 Discord 均为 @kenvandine）。

背景与动机：Lemonade 已支持多种硬件与操作系统（合称平台），但要覆盖所有大众市场平台，还需要额外的编译目标、平台专属后端支持等。开发者更可能基于一个能让他们把应用部署到所有相关平台的 Lemonade 来构建。

目标：Lemonade 能在所有大众市场平台上工作，并在每个平台上都提供优化性能。

贡献方式：先读通用 贡献指南，再在 Discord 联系 @kenvandine。维护分工见 contribute.md#maintainers。

路线图：按"厂商技术 × 应用类型"矩阵推进

Vendor-Neutral Vulkan

• LLMs via llama.cpp：Windows/Linux 的 x86 已完成标记（表中为 x），ARM 待办；

• 图像生成与编辑 via stable-diffusion.cpp：x86 的 Windows/Linux 已标记，ARM 待办；

• 实时转录 via whisper.cpp：仅 Linux x86 已标记，Windows x86 与 ARM 待办。

AMD ROCm

• LLMs via llama.cpp：x86 的 Windows/Linux 均已标记完成（[x]）；
• 图像生成与编辑 via stable-diffusion.cpp：x86 的 Windows/Linux 均已完成；
• 实时转录 via whisper.cpp：仅 Windows x86 已标记，Linux x86 待办。

Nvidia CUDA

• LLMs via llama.cpp：x86 的 Windows/Linux 已标记，ARM 待办；
• 图像生成与编辑、实时转录：尚未标记完成（空表）。

Intel OpenVINO：LLM、图像生成与编辑、实时转录三行均为待办（x86）。

Qualcomm QNN：LLM、图像生成与编辑、实时转录三行均为待办（ARM）。

Apple Silicon Metal：LLM via llama.cpp、图像生成与编辑 via stable-diffusion.cpp、实时转录 via whisper.cpp 三项全部标记完成（[x]）。

从仓库后端目录结构（src/cpp/server/backends/ 下 llmacpp、sdcpp、whispercpp、vllm、fastflowlm、ryzenai、onnxruntime、openmoss、trellis、acestep 等后端目录）以及维护者表中 @kenvandine（snaps、Linux、Nvidia CUDA、ARM）、@superm1（ROCm、Linux 打包、Docker）、@pwilkin（Trellis、OpenMOSS、ACE-Step、ThinkSound、llamacpp）等分工可以推断：跨厂商支持本质上是对"后端 × 平台"矩阵的持续补齐，与项目的哲学准则"Backends are Fungible（后端是可互换的）"高度一致——Lemonade 不应抬举任何后端，从后端 A 迁移到后端 B 应当只需一行代码或 GUI 一键。

Cloud Hybrid 工作组：本地与云端智能路由

负责人：@ramkrishna2910（Discord 同号）。

目标：Lemonade 能智能地在本地模型与云端模型之间路由。这与项目的智能路由（smart router）能力直接相关——维护者表中 @ramkrishna2910、@eddierichter-amd、@fl0rianr、@SlawomirNowaczyk 的维护领域均包含 smart router。仓库中的 router.cpp、routing_policy.h 及其配套策略文件（routing_policy_parser、routing_policy_store）构成了该工作组的技术底座，测试方面则有 test/routing_conformance_corpus.cpp 等一整套路由策略测试。

Remote Use 工作组：随时随地推理

负责人：@Geramy（Discord 为 @geramyl）。

目标：Lemonade 能向任何位置、任何设备提供推理服务。@Geramy 的维护领域（sockets、TCP/IP、UDP、命名管道、mac、安全、Nexus mesh compute）暗示该组的工作重点是网络协议栈、认证与跨设备暴露推理服务，仓库中的 websocket_server.h、streaming_proxy.h、wrapped_server.h 以及 docs/server/server_spec.md 是理解相关能力边界的参考起点。

GUI App 工作组：让人愉悦地探索本地 AI

负责人：@kponiel（Discord 为 @primaL-）。

目标：用户能在内置 GUI 中愉快地探索本地 AI。GUI 对应仓库中的Lemonade App（src/app/），这是一个基于 Tauri + React 的桌面应用（src-tauri 目录含 Rust 代码与 tauri.conf.json）。项目哲学对 GUI 有明确定位：GUI 只用于两件事——展示可能性（功能没有 GUI 展示就等于不存在于大多数人眼中），以及帮助用户跨已连接应用管理模型与后端。哲学文档中"VS Code 风格侧边栏"的案例（v9 GUI 布局不可扩展，改为左侧面板在 Model/Backend 管理间切换）正体现了 GUI App 工作组的迭代思路。

Enterprise Grade 工作组：企业级质量与自动化

负责人：Jeremy Fowers（GitHub 为 @jeremyfowers，Discord 为 @jfowers_amd）。

背景：Lemonade 已在全球用户与商业实体中获得牵引，同时每天迎来大量新 PR 与 Issue。"速度 vs 稳健性"之间的张力成为许多利益相关者关注的重点。

目标：让 Lemonade 成为关键业务部署中值得信赖的推理编排层（trusted inference orchestration layer）。

• 不必在速度与稳健性之间二选一；
• 附带目标：尽可能用本地 AI 完成自动化工作，以证明 Lemonade 与本地 AI 可用于企业场景。

贡献方式：先读通用 贡献指南，再联系 @jfowers_amd；工作组条目见 工作组总览表。

技术路线图总纲：引入 agents、CI 增强与看板（dashboards），在保证 Lemonade 贡献与发布质量的同时提升维护者带宽。具体包含：

PR Review AgentPR agent 作为常规 CI 的一部分运行，调用一个基于 Lemonade 的 Pi agent 辅助维护者，核心职责：

• 结合 contribute.md 与 philosophy.md 审查 PR，指出任何不一致；
• 对照 documentation.md 确保 PR 文档完备；
• 分析 PR 是否引入重大新范围，若是则要求核心维护者二次评审；
• 分析 PR 是否含破坏性 API/UX 变更，确保其 1) 有文档 2) 经核心维护者批准；
• 根据 contribute.md 的维护者表为 PR 建议评审人。

PR agent 的目的是引导作者提交"可评审就绪"的 PR，并告知评审人评审时应关注什么，不替代人工评审。

Issue Review Agent分析所有 issue（包括已开未关的），用于：

• 识别是否与其他 issue 重复；
• 热门 issue（大量点赞/评论）通知到 Discord #dev 频道；
• 判断 issue 是否仍相关，或已被解决（如 bug 已在某版本修复）或已过时（如 gui3 发布后对 gui2 的反馈）；
• 评估 issue 是否"优质"：可复现、定义清晰、符合 philosophy.md。若不合格则自动回复引导，并指引作者前往 Discord；
• 将"优质" issue 按 contribute.md 的表自动指派给维护者，并在 Discord #dev 频道 @ 通知；
• 建议 issue 是否应标记为 Good First Issue。

性能回归套件（Performance Regression Suite）为 Lemonade 支持的每个引擎与后端，保存每个受支持 tagged release 的性能数据库，用于：

• 用户想为特定模型最大化性能时，精确指出最适合的引擎/后端/tag 组合；
• 升级 tag 时，确保热门模型没有性能回归。

该套件应利用lemonade bench测量受众关心的场景——这与 Auto-Tune 工作组复用同一基准基础设施（docs/guide/cli.md），并可借助--compare与--output建立可对比基线。

CI 增强在减少开发期不必要等待的同时提高测试覆盖：

• 利用性能数据库批准/拒绝引擎/后端升级；
• 用 Radeon 模拟扩大 AMD GPU 的 CI 覆盖；
• 向 self-hosted runners 池增加更多物理 Radeon 与 Nvidia GPU；
• 增加过滤，窄变更时减少 runner 调用——例如 GUI 变更无需运行 ROCm 推理测试。

发布流程提高发布自动化水平与质量：

• 从语义化版本转向基于日期的版本号，使发布版本号确定化；
• 每周自动创建带正确版本号的发布分支，发布后自动将 release tag 同步回 main；
• 允许每个 release 自动生成 release notes 的 GitHub issue 附加可置于发布页顶部的额外文案，省去打 tag 后的编辑工作。

社区看板（Community Dashboard）获取需要关注或建议关注的 Discord 活动告警，例如：

• 新用户发出第一条消息（便于欢迎）；
• 新用户大量涌入；
• 单一主题消息量过高。

已归档工作组：Omni Models 的经验沉淀

状态：该工作组已归档，因为维护者认为核心目标已达成。Omni 模态对项目仍很重要，将持续维护与扩展。

负责人：Jeremy Fowers（@jeremyfowers / @jfowers_amd）。

背景：Lemonade Omni Models 将多个模型与后端组合起来，呈现原本在本地 AI 中不易获得的 omni 模态能力（例如在同一模型内聊天与图像编辑）。

动机：Omni 模态让终端用户与本地 AI 系统之间的交互更自然，是本地 AI 大规模采用的关键。

路线图完成情况（全部勾选完成）：

• 开发面向应用场景（如图像生成）的 LMX 技能、system prompts 与工具（注：Halo Tales 是其中之一，希望有更多）；
• 更新 Lemonade 网站与顶层 README，强调开发者旅程——嵌入 lemond 并集成 LMX 模型；
• Lemonade Mix（LMX）omni 模型在 Open WebUI 中可用；发布解释 LMX 与用例的博客；
• 发布 Halo Tales——基于 LMX 模型的参考应用（注：HaloTales 最终成为专用 LMX 而非应用），并平滑 Lemonade 的毛边，随后发布 LMX 开发者旅程博客；
• 将 LMX 模型定义迁移到 Hugging Face 使其可作为模型搜索（子项：确保 Lemonade 显示在模型卡的 "Use This Model" 下——此项仍待办）。

如何参与：加入或发起一个工作组

参与路径清晰分层（综合 docs/dev/working-groups/README.md、docs/dev/contribute.md 与 docs/dev/spec-driven-dev.md）：

1. 加入现有工作组：大多数实质性贡献应落在现有某个工作组的范围内，直接联系对应 Lead（Discord 是最佳入口）即可。当前可加入的组包括 Auto-Tune（@mikkoph）、Cross-Vendor（@kenvandine）、Cloud Hybrid（@ramkrishna2910）、Remote Use（@geramyl）、GUI App（@primaL-）、Enterprise Grade（@jfowers_amd）。
2. 直接提交 PR：完全在章程范围内的 PR 无需额外 RFC，在 PR body 中链接工作组即可。
3. 发起新工作组：任何对 Lemonade 范围、表面面积（surface area）或用户体验的改变都需要走 spec-driven-dev 流程——在 RFC 讨论中提出工作组提案，被大量维护者评审后，由 @jeremyfowers 依据"生态健康优先、社区超多数正反馈次之"的两条准则批准，章程随后固化到docs/dev/working-groups/目录。

对希望快速建立信任的新贡献者，docs/dev/contribute.md 的建议是：提交小而清晰、易评审易验证、测试完备的 PR。

小结

工作组机制是 Lemonade 治理体系的骨架：它以 RFC 驱动的章程明确"做什么、边界在哪、谁负责"，以维护者表落实"谁评审"，以路线图分阶段推进"怎么做"。Auto-Tune 的硬件画像自动调优、Cross-Vendor 的平台矩阵补齐、Enterprise Grade 的 agent 化质量保障，以及已归档的 Omni Models 的 LMX 生态沉淀，共同勾勒出这个社区驱动项目的演进路径。对于开发者而言，无论是想在某个硬件平台上跑得更快、想贡献一个后端、还是想参与质量自动化，都能在相应工作组的章程与路线图中找到明确的切入点。

• 大模型
• 本地部署
• 模型推理服务
• 人工智能
• AI 应用
• 后端
• 多模态