GLM-5.3 Flash TP2 misidentifies decoded blue video as black

[FujitsuPolycom]

This was generated by AI during triage.

Problem

The GLM-5.3 Flash NVFP4-Spark two-node profile labels a solid-blue H.264 video as black. The same runtime recognizes a solid-blue PNG as blue. Video decoding returns blue pixel values, so the observed error occurs after initial frame decoding; its cause in preprocessing or model interpretation is unresolved.

Status: research-only. Video input processing is implemented, but blue-video color recognition is not qualified. This issue does not assert that all videos fail or that the packaging step introduced the behavior.

Conditions

• Hardware: two NVIDIA DGX Spark GB10 computers, ARM64/SM121, direct RoCE fabric.
• Runtime image: ghcr.io/fujitsupolycom/sparkring@sha256:d431841cd9adb75ec40777eeb435f7f72af5995018219fa3556d7b5c7f56c2d5.
• Checkpoint: local-inference-lab/GLM-5.3-Flash-NVFP4-Spark, revision df116c4fb16b1d37ae43d2cfd624de26ffbc832e.
• Tensor parallel degree 2; decode-context parallel degree 1; native adaptive multi-token prediction with up to 3 draft tokens; Humming draft MoE.
• Maximum concurrent sequences 8; batch token budget 8192; prefill interval 2; KV pin 5 GiB per rank; context limit 524288; image/video prompt limits 1/1.
• Public installation and response evidence: qualification record, raw observations.

Reproduction

Install the profile using docs/GLM53_FLASH_SPARK_TP2_EXPERIMENTAL_QUICKSTART.md and the image digest above. On the API node, create the video fixture and call the public smoke client:

docker exec sparkring-glm53-tp2-r0 ffmpeg -hide_banner -loglevel error \
  -f lavfi -i 'color=c=blue:s=224x224:r=8:d=1' \
  -c:v libx264 -pix_fmt yuv420p /tmp/blue-smoke.mp4
docker cp sparkring-glm53-tp2-r0:/tmp/blue-smoke.mp4 ./blue-smoke.mp4
python3 runtime/profiles/glm53-flash-spark-tp2/smoke.py \
  --phase video --video-file blue-smoke.mp4

The fixture contains eight frames over one second, at 224×224 pixels. The client sends a base64 video_url to /v1/chat/completions, asks for the dominant color, uses temperature 0 and a 256-token output limit, and expects blue in the final content. The input file must not already exist at the FFmpeg output path, or it must be explicitly replaced by the operator.

Measurement and result

• Blue-video inference returned final content Black twice. API usage reported 72 video tokens.
• FFmpeg decoding of the first frame produced mean RGB [0, 0, 253].
• The runtime's Glm5NextVideoBackend selected frames 0 and 7 through OpenCV and returned a uint8 array of shape [2, 224, 224, 3], mean RGB [0, 0, 255].
• The generated blue PNG was recognized as blue.
• Red and green MP4 probes were recognized. Those probes used a different diagnostic question, so they are not a controlled color-only comparison.

Conclusion and investigation scope

The blue fixture is valid and initial video decoding preserves its color. Trace the processor tensors, temporal patch layout, vision encoder inputs and model response before attributing the result to a specific component. Compare image and video paths with matched pixels and prompt wording; retain positive and negative controls. An MTP-on/off comparison may help separate speculative execution from vision processing but has not been performed.

Acceptance criteria: reproduce and localize the discrepancy; add a regression test at the actual failing boundary; repeat blue still-image and blue/red/green video checks under matched conditions; record exact source/image identities and any remaining recognition limits. Do not close this issue solely because a request succeeds or a different color is recognized.

No full video-accuracy benchmark or general multimodal qualification is claimed by these checks.