大模型本地部署模型推理服务人工智能AI 应用后端多模态【免费下载链接】lemonadeLemonade helps users discover and run local AI apps by serving optimized LLMs right from their own GPUs and NPUs. Join our discord: https://discord.gg/5xXzkMu8Zk项目地址https://gitcode.com/gh_mirrors/lemonade2/lemonade点击查看免费下载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 FoundationLemonade 是地基而不是房子用户可以从 GUI 入门再连接其他应用最终将 Lemonade 嵌入自己的应用——这与 Cloud Hybrid、Remote Use 工作组的智能路由和远程推理目标一脉相承。Prioritize the Happy Path高级功能不应给新用户增加摩擦这正好解释了 Auto-Tune 工作组开箱即用、自动获得良好性能的目标为什么是项目级优先事项。Standards are Intuitive尽量遵循 OpenAI API、VS Code GUI、Ollama CLI 等既有标准这也是各工作组在设计接口与 CLI 行为时的重要约束。治理与审批谁来批准章程工作组的章程由项目负责人jeremyfowers批准审批时按顺序考量两个主要因素确保本地 AI 软硬件生态的整体健康overall health of the local AI HW/SW ecosystem社区绝大多数成员的正面反馈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 管理员 学科领域组织例如jeremyfowersAdmin新端点、新后端、大型新功能、GUI 设计语言、新 CLI 命令、网站、治理、Lemonade MixLMXomni 模型、CIkenvandineAdminsnaps、Linux、新后端、硬件厂商支持、Nvidia CUDA、ARMramkrishna2910Admin新后端、新模态、vLLM、whisper、stable diffusion、智能路由与编排、云 API 集成、NPUbitgammathenoise、CLI、recipes、新后端、benchmarking、新模型同时是 Auto-Tune 工作组负责人Geramysockets、TCP/IP、UDP、命名管道、mac、安全、Nexus mesh compute同时是 Remote Use 工作组负责人。工作组是聚焦的路线图开发领域是上述端到端维护与支持的一个子集——贡献者应利用维护者的领域知识作为设计起点PR 也最好至少有该领域一名维护者深度评审。工作组总览当前活跃的 6 个工作组与 1 个已归档工作组如下信息来自 docs/dev/working-groups/README.md活跃工作组工作组LeadGitHubDiscord 联系人目标Auto-Tunebitgammamikkoph让 Lemonade 实例能够自我优化模型与后端Cross-Vendor SupportkenvandinekenvandineLemonade 支持所有大众市场硬件与操作系统平台Cloud Hybridramkrishna2910ramkrishna2910Lemonade 能智能地在本地模型与云端模型之间路由Remote UseGeramygeramylLemonade 能向任何位置、任何设备提供推理服务GUI AppkponielprimaL-用户能在内置 GUI 中愉快地探索本地 AIEnterprise Gradejeremyfowersjfowers_amd为 Lemonade 组件提供系统化测试与质量保障已归档工作组工作组LeadGitHubDiscord 联系人目标Omni Modelsjeremyfowersjfowers_amd让 Omni Models 成为本地 AI 应用与使用的支柱活跃工作组详解与路线图以下各节按 docs/dev/working-groups/ 下的章程文档逐一展开并结合仓库源码说明规划背后的既有技术基础。Auto-Tune 工作组让机器自己找到最佳运行参数负责人Michele BalistreriGitHub 上为 bitgammaDiscord 上为 mikkoph。背景与动机把模型跑得好需要选对后端并调优批量大小batch size、GPU 层卸载GPU layer offload、线程数thread count、上下文大小context size等性能参数。目前用户要么靠猜、要么翻 Reddit 帖子、要么问 LLM——这些方式容易出错而且往往因知识截止而过时。Lemonade 已经具备两样关键基础设施bench命令跨后端与参数组合测量 TTFT首 token 延迟、TPS每秒 token 数与 VRAM 占用recipe 系统定义每个模型的配置。缺少的是一种把基准测试数据转化为可自动应用的、感知硬件的默认值的机制。最终目标是用户安装 Lemonade 后无需理解后端参数、也无需手动跑基准拉取模型并加载即可获得良好性能——硬件感知的默认值降低了入门门槛也让 Lemonade 在与性能已被抽象掉的云方案竞争时不落下风。目标通过检测机器硬件画像hardware profile并应用社区验证过的性能参数让 Lemonade 实例自我优化模型与后端。终态是用户拉取模型并加载后Lemonade 自动为其硬件选出最佳后端与调优参数同时保留手动覆盖或微调的能力。贡献方式先阅读通用 contribution guidelines贡献指南然后通过 Discord 联系 mikkoph 讨论路线图后再开始。范围界定本工作组聚焦由硬件特性决定的性能参数批量大小、GPU 层数、线程数、上下文大小、后端选择。质量类参数temperature、top_p、chat template 等属于模型或用例相关明确不在范围内。五阶段路线图Phase 1Archetype 检测与 Profile Schema定义硬件原型archetype分类逻辑。Archetype 由 GPU 家族/架构、VRAM 容量分桶、内存带宽层级、内存是否统一unified或分立discrete来标识——这使 profile 空间有界两个 archetype 相同的机器得到相同的推荐。设计 profile JSON schemaprofile 将 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 3Profile 分发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_sizeresolve_auto_ctx_size()读取有效选项中的ctx_size若为-1则触发自动解析否则返回-2无需解析。get_available_memory_gb()按设备类型GPU/CPU/NPU计算可用内存GPU 用 VRAMiGPU 含 GTTCPU/NPU 用系统 RAMApple Silicon 用统一内存池virtual_gbAMD 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.mdlemonade 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 --submitPhase 3尚未在 docs/guide/cli.md 中列出属于规划中的能力。Cross-Vendor Support 工作组全平台支持负责人Ken VanDineGitHub 与 Discord 均为 kenvandine。背景与动机Lemonade 已支持多种硬件与操作系统合称平台但要覆盖所有大众市场平台还需要额外的编译目标、平台专属后端支持等。开发者更可能基于一个能让他们把应用部署到所有相关平台的 Lemonade 来构建。目标Lemonade 能在所有大众市场平台上工作并在每个平台上都提供优化性能。贡献方式先读通用 贡献指南再在 Discord 联系 kenvandine。维护分工见 contribute.md#maintainers。路线图按厂商技术 × 应用类型矩阵推进Vendor-Neutral VulkanLLMs via llama.cppWindows/Linux 的 x86 已完成标记表中为 xARM 待办WindowsLinuxx86xxARM图像生成与编辑 via stable-diffusion.cppx86 的 Windows/Linux 已标记ARM 待办WindowsLinuxx86xxARM实时转录 via whisper.cpp仅 Linux x86 已标记Windows x86 与 ARM 待办。WindowsLinuxx86xARMAMD ROCmLLMs via llama.cppx86 的 Windows/Linux 均已标记完成[x]图像生成与编辑 via stable-diffusion.cppx86 的 Windows/Linux 均已完成实时转录 via whisper.cpp仅 Windows x86 已标记Linux x86 待办。场景Windows (x86)Linux (x86)LLMs via llama.cppxxImage via stable-diffusion.cppxxTranscription via whisper.cppxNvidia CUDALLMs via llama.cppx86 的 Windows/Linux 已标记ARM 待办图像生成与编辑、实时转录尚未标记完成空表。WindowsLinuxx86xxARMIntel OpenVINOLLM、图像生成与编辑、实时转录三行均为待办x86。WindowsLinuxx86Qualcomm QNNLLM、图像生成与编辑、实时转录三行均为待办ARM。WindowsLinuxARMApple Silicon MetalLLM 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 等后端目录以及维护者表中 kenvandinesnaps、Linux、Nvidia CUDA、ARM、superm1ROCm、Linux 打包、Docker、pwilkinTrellis、OpenMOSS、ACE-Step、ThinkSound、llamacpp等分工可以推断跨厂商支持本质上是对后端 × 平台矩阵的持续补齐与项目的哲学准则Backends are Fungible后端是可互换的高度一致——Lemonade 不应抬举任何后端从后端 A 迁移到后端 B 应当只需一行代码或 GUI 一键。Cloud Hybrid 工作组本地与云端智能路由负责人ramkrishna2910Discord 同号。目标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 工作组随时随地推理负责人GeramyDiscord 为 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负责人kponielDiscord 为 primaL-。目标用户能在内置 GUI 中愉快地探索本地 AI。GUI 对应仓库中的Lemonade Appsrc/app/这是一个基于 Tauri React 的桌面应用src-tauri 目录含 Rust 代码与 tauri.conf.json。项目哲学对 GUI 有明确定位GUI 只用于两件事——展示可能性功能没有 GUI 展示就等于不存在于大多数人眼中以及帮助用户跨已连接应用管理模型与后端。哲学文档中VS Code 风格侧边栏的案例v9 GUI 布局不可扩展改为左侧面板在 Model/Backend 管理间切换正体现了 GUI App 工作组的迭代思路。Enterprise Grade 工作组企业级质量与自动化负责人Jeremy FowersGitHub 为 jeremyfowersDiscord 为 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 Fowersjeremyfowers / jfowers_amd。背景Lemonade Omni Models 将多个模型与后端组合起来呈现原本在本地 AI 中不易获得的 omni 模态能力例如在同一模型内聊天与图像编辑。动机Omni 模态让终端用户与本地 AI 系统之间的交互更自然是本地 AI 大规模采用的关键。路线图完成情况全部勾选完成开发面向应用场景如图像生成的 LMX 技能、system prompts 与工具注Halo Tales 是其中之一希望有更多更新 Lemonade 网站与顶层 README强调开发者旅程——嵌入 lemond 并集成 LMX 模型Lemonade MixLMXomni 模型在 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加入现有工作组大多数实质性贡献应落在现有某个工作组的范围内直接联系对应 LeadDiscord 是最佳入口即可。当前可加入的组包括 Auto-Tunemikkoph、Cross-Vendorkenvandine、Cloud Hybridramkrishna2910、Remote Usegeramyl、GUI AppprimaL-、Enterprise Gradejfowers_amd。直接提交 PR完全在章程范围内的 PR 无需额外 RFC在 PR body 中链接工作组即可。发起新工作组任何对 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 应用后端多模态【免费下载链接】lemonadeLemonade helps users discover and run local AI apps by serving optimized LLMs right from their own GPUs and NPUs. Join our discord: https://discord.gg/5xXzkMu8Zk项目地址https://gitcode.com/gh_mirrors/lemonade2/lemonade点击查看免费下载相关推荐Kubernetes 长期支持工作组WG LTS章程全解目标、调研路径与社区治理机制Kubernetes 长期支持工作组WG LTS章程全解目标、调研路径与社区治理机制 本文以 Kubernetes 社区仓库中的 WG LTS 章程 ht开源治理文档研发协作终极指南Kubernetes社区AI工作组2025路线图——三大工作组如何重塑AI基础设施终极指南Kubernetes社区AI工作组2025路线图——三大工作组如何重塑AI基础设施 Kubernetes社区AI工作组正通过三大专项工作组WG AI开源治理文档研发协作AltStore开源社区治理从个人驱动到社区参与的演进之路AltStore开源社区治理从个人驱动到社区参与的演进之路 引言非越狱iOS生态的治理挑战 你是否曾为iOS应用签名到期频繁重装而烦恼作为一款面向非越狱移动开发上一篇lo 迭代器 TakeWhile 使用指南从序列头部按条件取元素下一篇使用 lo 的 SeqToChannel 将 Go 迭代序列无缝转换为管道流创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
