SM120 LTX-2.5: E0M3 patch lost at module load; QFA INT32 workspace limit

#1
by Pengyifei - opened

Official loaded cubin loses E0M3 patch despite disk SASS; QFA3K typed workspace exceeds INT32 backing guard

Classification: supported repair/diagnosis pending. This is not a claim that the published binary is unpatched, that hardware cannot execute E0M3, or that QuantFunc is unsuitable. No official guard bypass or full-video promotion.

Environment: RTX5090Laptop24463MiB, CC12.0, Windows driver616.92/WSL Ubuntu24.04; Torch2.14.1+cu130/CUDA13.0/cuDNN92400; plugin0.0.07 commit8fce4fc5b14839f69922eb1fb3c4f8994dd6036a; engine0.0.17-sm120a-cu13.
Official kernel-library SHA813f34f3fab589cabc6e99d024bbc0ddfb0c9faf31fb6327fe5c4d3dd7da1058; host SHA102bee897d5f87fe5aa4dc712835d6ad6acfbbf71871310a02714c3c58e6760e; attention SHA86e1ac9419a3c3550f7498cc785b3d41f078af5cae59f4cc4a1975646b0a3c1c.
Model when used in retained sampling: QuantFunc/LTX-2.5-QuantFunc-4bit revisionb3ef9e8e8b2597f6593c2f31326ca8ef3b5d3397, int4-r128 SHA781356c78f7d40d3f9787e34eee5bba9c43cd20b4435f8de1090d7f6cfb97bc6.

Actual official native module evidence (no model): direct e0m3_int4_will_dispatch(dtype7,false,false) returnsFalse; native selfcheck reports E2M1. NVIDIA CUPTI MODULE_LOADED captured64,820,688bytes of the associated loaded cubin, SHAc92c806cae160d7e90c938ed71b533de7e7966f81bd166a80e78897e07b85429. The exact same runtime selfcheck symbol has64E0M3/0E2M1 instructions in disk SASS but0E0M3/64E2M1 in the actual loaded SASS. All4JIT aliases setFORCE=0/DISABLE=1 plusCUDA_CACHE_DISABLE=1 still reproduce. The actual native short model CUDA trace separately shows10848main gemm_w4a4 calls and only1E0M3 selfcheck call.

A public-author micro-only Driver API isolation first obtains a driver-finalized cubin and then changes only2format bits. E2M1 nibble1/7 gives16/2304; post-finalized E0M3 gives64/3136. Official engine unchanged; no bypass. Thus earlier generic hardware-decoding inference is superseded by actual disk-to-loaded patch loss. Binary finalization/off-target/capmerc is a candidate mechanism, not a proven exact explanation or definitive driver bug. Does the engine require a supported on-target/finalization-safe patch process or a different compatible binary? How should this be verified without overriding selfcheck?

Independent official QFA API issue: ABI1.1 typed workspace size function(API offset0xd8), raw args[8,1,32,32,178560,178560,128,0] returns2274530048; sequence256 returns3188224. Host VA0xdf36ff compares against0x7fffffff and branches to the exact workspace error before allocation. AtVA0xdf3b67/79 downstream allocates a32-bit1D backing shape. The actual frozen3K single-step request failed identically despite20.833GiB realCUDAfree after native release. It is not OOM. Please support64-bit allocation or multidimensional uint8 backing while preserving size_t; blindly removing guard would overflow. Portable SHA/ABI-pinned query-only script included below; inferred ABI roles are disclosed. No model/attention-forward needed for size reproduction.

NVIDIA primary references:

No private paths, network addresses, credentials or proprietary images included. Public workflow template replaces the image/prompt and has not been independently replayed. Expected main fast kernel and QFA3K remain unconfirmed; no full-video speed/quality verdict. Submitted through the official model discussion using an existing authenticated HF CLI session.

Portable query-only reproducer

"""Model-free QFA ABI1.1 workspace-size query; no attention forward or guard bypass.

ABI layout/signature inferred from the tested official0.0.17-cu13 binary,
not a public stable ABI guarantee. Do not use against an unknown ABI.
The script does not import Torch or explicitly initialize CUDA. The library
may initialize its runtime internally. Run on a compatible isolated host.
"""
import argparse
import ctypes
import hashlib
import json
from pathlib import Path


def main():
    parser = argparse.ArgumentParser(description=__doc__)
    parser.add_argument('libpath', type=Path, help='Path to matching official libquantfunc_attention.so')
    args = parser.parse_args()
    path = args.libpath.resolve(strict=True)
    digest = hashlib.sha256(path.read_bytes()).hexdigest()
    expected = '86e1ac9419a3c3550f7498cc785b3d41f078af5cae59f4cc4a1975646b0a3c1c'
    if digest != expected:
        raise SystemExit('Refusing unknown binary: this raw ABI reproducer is pinned to the verified SHA256')
    if ctypes.sizeof(ctypes.c_void_p) != 8:
        raise SystemExit('Requires 64-bit process')
    lib = ctypes.CDLL(str(path))
    api = ctypes.create_string_buffer(232)
    ctypes.c_uint32.from_buffer(api).value = 232
    lib.qfa_get_api.argtypes = [ctypes.c_uint32, ctypes.c_void_p]
    lib.qfa_get_api.restype = ctypes.c_int
    status = lib.qfa_get_api(1, ctypes.byref(api))
    header = list((ctypes.c_uint32 * 4).from_buffer(api))
    if status != 0 or header[:3] != [232, 1, 1]:
        raise SystemExit(f'Unsupported API status/header: {status}/{header}')
    pointer = ctypes.c_void_p.from_buffer(api, 0xd8).value
    if not pointer:
        raise SystemExit('Missing typed workspace-size query; refusing NULL call')
    query = ctypes.CFUNCTYPE(ctypes.c_size_t, *([ctypes.c_int] * 8))(pointer)
    results = []
    for seq in (256, 178560):
        raw = [8, 1, 32, 32, seq, seq, 128, 0]
        size = int(query(*raw))
        results.append({'raw_args': raw, 'workspace_bytes': size,
                        'exceeds_int32_max': size > 2147483647})
    print(json.dumps({'library_basename': path.name, 'sha256': digest,
                      'abi_status': status, 'abi_header': header, 'queries': results,
                      'model_loaded': False, 'attention_forward_called': False,
                      'guard_bypassed': False,
                      'interpretation': 'Raw query only. Argument roles inferred from binary; zero means unsupported/query unsuccessful.'}, indent=2))


if __name__ == '__main__':
    main()

Thanks for the detailed report and the reproducer — much appreciated. We're looking into both points on our side, and we'll follow up here once we have an update.

Sign up or log in to comment