场记 / Continuity

A DeepSeek Harness plugin that gives an agent local image / speech / music / SFX generation and remembers what it made — the same character stays the same character across every call, and a failed generation is never allowed to pass as a success.

Runs locally. Models are lazy-loaded per request and released when idle, so when you are not using it the GPU is untouched — 0.21 GiB resident, measured. You can play a game on the same card.

场记 is the continuity supervisor on a film set. Their entire job is two things: make sure the costume, hair and props match between takes, and catch the mistake on set before it is cut into the film. That is exactly this plugin's job.

Install

uvx --from continuity-mcp continuity-setup      # preflight → build engines → fetch weights → start
dsh plugin --profile <your-profile> add dsh-plugin-continuity

continuity-setup checks the machine before it downloads anything, and sizes the install to what it finds. Run continuity-setup --check first to see what it would do — that reads hardware and changes nothing:

体检结果:
  GPU     AMD Radeon RX 7800 XT (RADV NAVI32)  (16.0 GiB, 此刻可用 15.8 GiB, DISCRETE_GPU, vulkan device 1)
          未选 AMD Radeon RX 7900 XTX (RADV NAVI31) (24.0 GiB, 此刻可用 1.4 GiB)
          跳过 llvmpipe —— 软件渲染, 不是真显卡
  内存    30.9 GiB
  磁盘    3118.4 GiB 可用 / 需要 30 GiB
  生图    启用
  抠图默认档  best
  参考音上限  30s (每秒约 0.19 GiB 显存)

Two details in there that exist because the naive version is wrong:

• It skips llvmpipe. The software rasterizer advertises 30.9 GiB of "VRAM" (it is your system RAM) and would win any "pick the biggest card" contest. Everything would then run on the CPU — working, looking completely normal, and unusably slow.

• It picks by free VRAM, gates by total VRAM. On the machine above the 24 GiB card has 1.4 GiB actually free because another process holds it; picking by size would select it and then OOM. But "is this card good enough" is a hardware question, so that one uses the total — otherwise a 16 GiB card would be rejected for having a game open.

Minimum requirements

Audio-only installs (see below) need 20 GiB during install, 9.5 GiB after.

All VRAM/RAM figures on this page are GiB (2³⁰ bytes), which is what rocm-smi and vulkaninfo report. An earlier version of this README labelled them GB; that was wrong and made the headroom look tighter than it is.

Vulkan instead of CUDA is not a preference — it is why this runs at all. ROCm miscomputes VAE decode on this GPU class (ROCm#6633): five decodes of identical input returned five mutually uncorrelated results. Vulkan/RADV compiles SPIR-V at runtime instead of looking up a per-arch kernel table, and is correct and faster here. The side effect is portability across all three vendors.

GPU vendors

I only have AMD cards, so I will not claim more than that. Nothing in the code is AMD-specific — no CUDA, no ROCm, no HIP, no /dev/kfd, no gfx targets — and ggml's Vulkan backend is widely run on NVIDIA. But "widely run" is not "I verified it".

The NVIDIA path is a genuinely different wiring, not just a different card: NVIDIA's Vulkan ICD lives in the host driver and must be injected by nvidia-container-toolkit, with NVIDIA_DRIVER_CAPABILITIES including graphics — the default compute,utility gives you working CUDA and an empty device list in Vulkan. continuity-setup detects NVIDIA, uses the right compose overlay, and tells you the path is unverified. Reports either way are welcome.

Host RAM in detail

Idle is negligible; the peaks are what sizes the machine.

Background removal is the ceiling, and its cost is independent of input size — 256 / 512 / 1024 px all peak at ~6.8 GiB, because BiRefNet runs at a fixed internal resolution.

On 16 GiB everything works. Below 12 GiB, continuity-setup sets the default to quality="fast" (u2netp): peak drops to 1.33 GiB and it runs in 0.6 s instead of 7.2 s. On a typical game sprite the two are hard to tell apart by eye — checked side by side over a magenta backdrop with the edges zoomed. best remains the default where there is room, because the models do differ in principle on fine edges (hair, semi-transparent fringes), but treat fast as a legitimate choice rather than a degraded fallback.

What adapts to your VRAM, and what cannot

Three things scale with the card. All three thresholds are measured, not guessed:

The audio-only tier is a real product, not a consolation prize: casting voices, dialogue, music, SFX and cutout all work, and it fits comfortably in 4 GiB.

What does not adapt: the image model. Quantizing it does not move VRAM at all — Q4_0 (2.29 GiB of weights) peaks at 6.60 GiB, Q8_0 (4.01 GiB) at 6.59 GiB, identical. Lowering resolution does not help either (512 / 768 / 1024 all peak the same; only time changes). The bottleneck is the 8 GiB unquantized 4B text encoder, not the diffusion model. So there is no "medium" image tier to offer, only installed or not. (Q4_0 ships anyway — same VRAM, 1.7 GiB less disk.)

Going below 8 GiB for images means changing the text encoder or the model family. That is possible, but it moves identity pinning from native ref_images to IP-Adapter, which is not verified here — and identity pinning is the whole point.

Zero residency

Measured on an RX 7800 XT with nothing else on the card:

Images are free: the engine streams weights per request and never keeps them resident. Audio is released by an idle timer (AUDIO_IDLE_UNLOAD_S, default 120 s) — not immediately, because someone voicing ten lines in a row should not pay a reload each time. Reload costs nothing measurable: the same TTS request took 3.0 s both cold and warm, because weights are mmap'd and sit in page cache.

Requests are serialized, so peak = the single largest model. Closing the agent releases the VRAM too — the MCP server unloads on exit rather than leaving the engines holding it.

Two things it actually does

1. Identity survives across calls. Generation backends are stateless: ask for the same character twice and you get two people who merely resemble each other. Measured on Qwen3-TTS, four lines from one voice description:

Under greedy decoding the seed is provably inert — seeds 5 / 99 / 777 produced one identical sha256 — so randomness was fully eliminated, and it still drifted 242 Hz. Identity is a function of the input text, not of the random draw. temperature=0 and top_k=1 cannot fix it. Only pinning to a reference artifact can.

create_actor(name, voice)          -> audition clip; listen before you commit
actor_tts(actor, text)             -> same timbre every line

create_character / create_animal / create_object (name, appearance)
subject_image(subject, scene)      -> same look, new scene / angle / outfit

Identity and wardrobe are separate: pin the face and build, then change clothes in the scene prompt. A reference in an indigo robe, asked for wearing heavy red armor, comes back in armor with the same face.

Already cast your character somewhere else? import_actor and import_subject pin an artifact you supply — a real voice recording, an ElevenLabs clip, a character sheet from another tool — and everything downstream behaves identically. Audio is normalized to 24 kHz mono for you (44.1 kHz stereo in, verified: reference f0 identical, and an imported actor tracks a natively-cast one to 11 Hz).

2. Degenerate output is refused. A backend that miscomputes returns a perfectly well-formed all-zero WAV, or a flat grey PNG, with HTTP 200. Every artifact is checked (image standard deviation, audio RMS, non-finite samples) and the call fails loudly rather than reporting success over garbage. Cutouts additionally get a quality report — mostly transparent, nothing removed, subject shattered into fragments, holes eaten through the subject — each with a specific warning instead of a silent pass.

Plus remove_bg: diffusion models draw "transparent background" as an opaque checkerboard; this turns it into a real RGBA cutout, which sprites require. And gen_sfx, which synthesizes sfxr-style game SFX procedurally — bit-identical for a given seed, milliseconds, no GPU — because a diffusion model is the wrong instrument for a 40 ms coin pickup.

Tools

19 tools. Everything returns absolute local file paths, not URLs — the agent and the engines are on the same machine, so a path can go straight into your game project without a download step, and there is no file server to run or misconfigure.

generate_image と generate_speech は単発利用のために存在し、それぞれの説明にもその旨が明記されています。それらが生成したものは次の呼び出しでは戻ってこないことをエージェントに明示的に伝え、繰り返し使うものについてはピニングツールを指し示します。

制限値と、それぞれの存在理由

ここにある数値はすべて、ポリシーではなく実測された障害境界です。

24 kHz 未満のインポート音声は受け付けられますが、フラグが付けられます。アップサンプリングでは失われたオクターブを復元できないため、クローンは元のファイルよりもくすんだ仕上がりになります。これは黙って通すのではなく警告に値します。このプラグインが捉えようとしている他のすべての障害と同じ形だからです。

過大な入力は、意図的に種類ごとに異なる方法で処理されます。 大きすぎる画像はリサイズされ、その結果が報告されます（原图 2400x1600 → 存为 1024x682）。縮小された画像も同じ内容を表しているからです。長すぎる参照音声は切り詰めではなく拒否されます。音声の末尾を切り取ると、トランスクリプトが音声にもはや含まれていない内容を指すことになり、クローニングが依存するのはまさにその対応関係だからです。黙って切り詰めれば、インポートは成功しても、別人のように聞こえるアクターを渡すことになります。

独自バックエンドの利用（任意）

ローカルエンジンがデフォルトですが、すべてのバックエンドは URL です（SD_SERVER、AUDIO_SERVER）。これらを自分のサーバーに向けると、ローカルモデルは一切読み込まれません。その場合の制約が 1 つあります。音声エンジンは参照音声のパスを自身で解決するため、同じ actors ディレクトリ（同じマシン、または共有マウント）を参照できる必要があります。

画像バックエンドは参照画像を受け付ける必要があります（FLUX.2 スタイルのネイティブ ref_images、IP-Adapter、または顔向けの PuLID など）。これがないと、アイデンティティのピニングは機能しません。プラグインは黙って劣化する代わりに、その旨を明示します。

先行事例

現在の MCP エコシステムの調査 — MiniMax-MCP、openrouter-mcp-multimodal、AtlasCloud、dsh の vision/draw プラグイン、および 4 つのゲームアセットサーバー — では、音声クローニングは複数の実装で見つかりましたが、視覚的な被写体のピニングはどこにもなく、出力検証もどこにもありませんでした。

レイアウト

bundle/   dsh bundle (npm) — one plugin row; dsh spawns and supervises the MCP server
src/      the MCP server: pinning, guardrails, verification, cutout, VRAM lifecycle
src/continuity_mcp/deploy/   compose + engine Dockerfile + weight manifest

ライセンス

MIT