Skip to content

建议支持将 MiniCPM-o 推理部署到远程模型主机 #5

Description

@zycaskevin

背景

当前 jarvis-native-worker 会在桌面端本机加载 MiniCPM-o。模型会占用较多显存,使用户很难同时运行游戏、浏览器或其他 GPU 工作负载。

希望增加一种 远程推理模式:桌面端继续采集当前电脑的屏幕与系统音频,但把真正的 MiniCPM-o 推理放到同一局域网/Tailscale 内的另一台模型主机上。

初始验证环境计划为:

  • 客户端:Windows 10/11
  • 模型主机:NVIDIA GB10(DGX OS / Linux ARM64 / CUDA 13)
  • 网络:同一 Wi-Fi,Tailscale direct path

建议架构

保留现有本地控制面和采集逻辑:

  • Electron、FastAPI、Windows named pipe 仍只在客户端本机运行;
  • DXGI 屏幕采集、WASAPI 音频采集、隐私模式、画面变化检测与 LatestOnlyScheduler 留在客户端;
  • IOmniRuntime 边界增加 RemoteOmniRuntime
  • 客户端仅在需要推理时发送最新的压缩画面、16 kHz mono 音频和 prompt;
  • 模型主机运行独立的 jarvis-model-server,加载现有 RealOmniRuntime
  • 不把当前仅用于本机的 named-pipe protocol 直接暴露到网络。

建议第一版通过 Tailscale/WireGuard 提供传输加密,并额外使用应用层 token 验证。断线时 fail closed,不自动上传云端,也不静默切回本机模型。

媒体与延迟策略

  • 画面:JPEG 压缩,但不固定缩小为 448×448,避免 4K 小字在传输前丢失;后续可增加 overview + ROI/tile。
  • 音频:PCM16、16 kHz、mono;一秒约 32 KiB,第一版没有必要引入 Opus。
  • 使用持久连接与 latest-only queue,禁止积压过期画面。
  • Tailscale relay 时降低单工感知频率;全双工默认要求 direct path。

分阶段实现

  1. 抽离 runtime load config,并建立独立 remote protocol 与 fake loopback tests。
  2. 先实现单工 infer/result/cancel/ping,支持主动提问和结构化场景感知。
  3. 再实现 duplex_start/frame/result/stop
  4. 加入 4K overview + ROI、性能指标、Linux ARM64 packaging 与 systemd/container。

验证计划

  • 现有 Python、Electron、native 测试保持通过;
  • GB10 上完成 ARM64/CUDA 13 编译、模型加载及 image + audio + prompt smoke test;
  • 两机持续运行、断线重连、隐私暂停、过期结果丢弃测试;
  • 记录 JPEG 大小、RTT、encode/decode、queue、模型推理与端到端延迟 p50/p95;
  • 确认远程模式下客户端不会下载或加载模型。

想确认的问题

  1. 维护者是否愿意接受以 IOmniRuntime 为边界的远程推理实现?
  2. 第一版先提交单工 MVP,再单独提交全双工,是否更容易审查?
  3. 对网络协议、配置格式或 Linux model-server 的发布方式是否有偏好?

如果方向可以接受,我愿意先提交一份保持本地模式兼容的单工 MVP PR。

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions