【免费下载链接】local-studioControl panel for VLLM, Sglang, llama.cpp, exllamav3项目地址https://gitcode.com/gh_mirrors/vl/local-studio点击查看免费下载Local Studio 是一款本地优先的 LLM 推理控制台统一管理 vLLM、SGLang、llama.cpp、MLX 等推理引擎的启动、驱逐与监控。深入它的 controller 源码会发现一个有趣的结构同时维护着engines和compute两套引擎栈。这不是重复造轮子而是一次典型的旧世界兼容 新世界重构分层设计——本文带你快速看懂两者的分工以及 ComputeBridge 如何把它们无缝桥接起来。双栈分工engines 是用户视角compute 是调度视角先明确一个背景Local Studio 的 controller 是一个 Bun Hono 后端承担模型生命周期、OpenAI 兼容代理、GPU 状态与 SSE 事件流。它的模块划分可以对照 controller/README.md 的架构图。两套栈的定位截然不同engines/模块旧栈用户视角面向 API 与 UI。它负责配方Recipe管理、引擎安装与运行环境探测venv / Docker / 系统二进制、模型下载、启动失败预算连续失败熔断以及/launch/:recipeId、/evict、/wait-ready这些前端一直在调用的生命周期路由。compute/模块新栈调度视角面向机器。它把如何启动一个推理进程抽象成纯粹的调度问题GPU 租约分配、端口探测、健康检查、进程回收支持 process 与 docker 两种运行时。为什么要拆源码注释里给出了最直接的回答旧世界里的协调器coordinator需要维护大量易失的内存状态而新世界里实例记录本身就是租约状态永远是从进程存活性推导出来的不会过期。compute 层的三大设计契约进入 controller/src/modules/compute/contracts.ts 的文件头注释作者用三条规则概括了整个新栈的设计哲学引擎是纯函数plan()是请求的完全函数——不读时钟、不读环境变量、不碰文件系统。这使得整条启动路径可以被黄金测试golden test覆盖5 个引擎vllm / sglang / llamacpp / mlx / exllamav3各自只需要声明自己如何拼写同一组标准参数。以 vLLM 为例vllm.ts 里tensorParallel对应--tensor-parallel-size、memoryFraction对应--gpu-memory-utilization一张映射表就把配方参数翻译成了命令行参数。实例记录就是 GPU 租约设备被占用当且仅当有一个存活记录InstanceRecord声明了它。没有独立的注册表就不会出现注册表和现实失步的问题。记录以先写临时文件再 rename的方式持久化为 JSON见 instances/store.ts崩溃中途写入只会读成未运行而不是垃圾数据。状态是推导出来的从不存储stateOf按存活 → 健康 → 截止期限三级判定得出reserving / starting / ready / unhealthy / exited系统中不存在一个会过期的status字段实现见 lifecycle.ts。配合 2 秒一次轮询的监督循环 supervisor.ts删掉记录就等于释放 GPU——没有需要忘记的释放调用也没有需要失效的缓存。ComputeBridge把旧世界接到新世界的桥那么问题来了前端和代理层一直在调用旧的单模型语义——推理端口上现在跑的是谁帮我驱逐它。新栈却是一个多实例调度器。ComputeBridge就是解决这个阻抗失配的桥。它的接口非常克制只有 7 个方法bridge.ts方法旧世界的含义findInferenceProcess推理端口上正在服务谁pid、后端、模型路径、端口getCurrentRecipe/launchingRecipeId当前/正在启动的配方launchRecipe/cancelLaunch启动与取消evict驱逐当前模型waitForHealthy轮询直到实例 ready桥的核心技巧只有一行常量export const LLM_INSTANCE llmbridge.ts#L32。它给活跃模型固定了一个实例名并让它服务在旧的推理端口上portOverride。于是一次只跑一个模型的旧语义被完美保留——代理、指标采集、语音模块一行代码都不用改却全部从新栈的实例记录中拿到答案。launchRecipe则演示了桥的完整转换链解析配方里的 GPU 选择器 → 组装ComputeLaunchInput二进制解析、extra_args序列化、MoE 专家并行的默认策略→ 交给compute.launch。注意 lifecycle-routes.ts 里的注释模型生命周期经由 compute bridge失败映射是 compute 联合类型 → HTTP绝不靠字符串匹配错误信息。组装点见 app-context.tsmakeCompute产出调度服务createComputeBridge把它与配方存储缝合成桥两者一起挂到AppContext上供所有路由使用。一条启动链路从点击启动到 GPU 租约把两个模块串起来一次完整启动是这样的前端调用POST /launch/:recipeIdengines路由先查启动失败预算连续失败过多则 429 熔断bridge.launchRecipe把配方翻译成调度输入校验 GPU 选择器能否解析到真实设备compute.launch检查主机档案平台 / 加速卡 / 统一内存 / Docker GPU 直通先reserve抢占放置锁、分配 GPU 与端口再写下一条ref: null的预留记录引擎规格生成LaunchPlanapplyDevices统一翻译设备寻址引擎从不需要知道CUDA_VISIBLE_DEVICES长什么样进程/Docker 启动器拉起实例waitReady先查存活再查健康直到就绪或触发失败清理并回收租约。整条链路上唯一有状态突变的地方就是 compute 层的lifecycle.ts——它是计算层中唯一的修改者其余一切只读记录。小结分层不是冗余而是演进 Local Studio 的双引擎栈给中大型项目一个很好的示范**旧栈engines**守住 API 兼容与用户体验新栈compute可以自由演进设计**桥ComputeBridge**只暴露最小接口把语义转换收敛在一个文件里避免两套世界互相污染纯函数引擎 记录即租约 状态即推导让5 个推理引擎 × 2 种运行时 × 3 类加速卡的组合空间依然可控可测。如果你想继续深挖可以从 controller/src/modules/compute/ 的contracts.ts入手——它是所有 compute 文件唯一允许依赖的模块读懂它就读懂了整个新栈的骨架。赞分享【免费下载链接】local-studioControl panel for VLLM, Sglang, llama.cpp, exllamav3项目地址https://gitcode.com/gh_mirrors/vl/local-studio点击查看免费下载相关推荐为什么现代Web应用都需要这个强大的提及引擎为什么现代Web应用都需要这个强大的提及引擎 在当今社交媒体和协作工具盛行的时代用户期望在输入框中能够像在Twitter或Slack中那样轻松地提及他人Babel Monorepo 架构解析为什么一个编译器要维护在同一个代码仓库中Babel Monorepo 架构解析为什么一个编译器要维护在同一个代码仓库中 Babel 是一个将下一代 JavaScript 编译为当前环境可运行代码的编编译器开发工具NumPy 1.22.1 发布说明深度解读维护版修复了什么、为什么重要NumPy 1.22.1 发布说明深度解读维护版修复了什么、为什么重要 NumPy 1.22.1 是一个典型的“维护版maintenance release科学计算数据分析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考