StreamDQ: A Guide to Streaming Data Techniques

• StreamDQ is a multi-domain term that denotes systems for online processing, including near-memory dequantization in LLM inference, streaming aggregation, and data quality monitoring.
• It encompasses specialized hardware and software frameworks designed to optimize real-time processing under resource constraints, achieving significant speedups and energy efficiency.
• The term’s diverse applications necessitate careful contextual disambiguation to clarify differences in system design, performance metrics, and domain-specific trade-offs.

StreamDQ is an overloaded label in recent arXiv literature rather than a single canonical system. Its most direct current usage denotes a near-memory dequantization architecture for weight-only quantized LLM inference, but closely related uses in the literature refer to streaming aggregation over unstructured data, stream-first data quality monitoring, heavy-hitter per-item quantile estimation, and stream-query-based temporal modeling. Across these usages, the common denominator is online processing under resource constraints, but the underlying abstractions, guarantees, and target systems are largely unrelated (Jeong et al., 9 Jul 2026).

1. Terminological scope and major usages

The label appears in several technically distinct research contexts. In some cases it is the actual system name; in others it is a compact reference used to describe a stream-oriented problem setting.

Usage	Domain	Core idea
StreamDQ	LLM inference acceleration	Near-memory weight dequantization in custom HBM (Jeong et al., 9 Jul 2026)
InQuest for StreamDQ-style queries	Unstructured stream analytics	Proxy-guided approximate aggregation over video and text streams (Russo et al., 2023)
Stream DaQ / “StreamDQ”	Data quality monitoring	Continuous windowed quality assessment over unbounded streams (Papastergios et al., 6 Jun 2025)
StreamDQ as per-item quantile monitoring shorthand	Stream algorithms	Heavy-hitter quantile estimation via SQUARE, QUASI, and SQUAD (Shahout et al., 2022)
Stream Query Denoising	Autonomous driving HD-map construction	Training-time denoising of previous-frame map queries (Wang et al., 2024)

This distribution matters because the same surface form can refer to hardware architecture, database-style query processing, data quality systems, or temporal perception models. A plausible implication is that any technical discussion of “StreamDQ” requires immediate disambiguation by domain, since the associated assumptions range from HBM pseudo-channel locality to windowed quality meta-streams to Chamfer-distance-based temporal matching.

2. StreamDQ as near-memory weight dequantization

In its most literal form, StreamDQ is a near-memory dequantization architecture for scalable LLM inference under weight-only quantization such as W4A16 and W8A16. The underlying problem is that quantized weights must be dequantized before GEMM, and on current GPUs this dequantization is typically executed on CUDA cores rather than tensor cores. The standard equations are

$$Quant(x) = \mathrm{round}\Big(\frac{x}{s} + z\Big), \quad Dequant(x) = (x - z)\cdot s,$$

where $s$ is the scaling factor and $z$ is the zero-point. The paper reports that dequantization can take 40–80% of total inference latency in LLaMA-3.1-8B-Instruct W4A16 across batch sizes, making it a first-order throughput bottleneck (Jeong et al., 9 Jul 2026).

The architecture moves this step into custom HBM. StreamDQ integrates compact DeQuantization Blocks (DQBs) into the HBM base die, specifically on the read path of each pseudo-channel memory controller. The GPU still issues ordinary loads, but a lightweight 3-bit sideband tag on each memory read request selects bypass or one of several conversion modes, including INT4 $\rightarrow$ BF16, INT8 $\rightarrow$ BF16, FP8 $\rightarrow$ BF16, INT4 $\rightarrow$ FP16, INT8 $\rightarrow$ FP16, and FP8 $\rightarrow$ FP16. The DQB decodes the tag, fetches any needed $S/Z$ metadata, performs on-the-fly dequantization on the read path, and returns converted data through the standard load response path. This preserves conventional GPU load semantics while removing CUDA-core-based dequantization from the GPU-side execution path.

The design is specialized to per-group quantization, where each output channel is partitioned into groups of size $s$0 and each group shares one $s$1 pair. Because modern GPUs interleave memory accesses across HBM pseudo-channels, StreamDQ reorganizes layout at deployment so that each weight group and its corresponding $s$2 metadata are co-located in the same pseudo-channel; when a group spans multiple pseudo-channels, the metadata can be replicated. The DQB microarchitecture comprises a tag parser, an $s$3 request generator plus $s$4 buffer, and a data processing block. For per-group metadata lookup, the group index is computed as

$s$5

The reported metadata-read fraction is only 7.25% / 4.48% for group size 64 at 4-bit / 8-bit, dropping to 1.92% / 1.16% for group size 256, so metadata overhead is amortized effectively in large-batch regimes.

The quantitative results are architectural rather than purely algorithmic. StreamDQ achieves up to $s$6 speedup and 90.23% lower energy for mixed-precision GEMM, and for end-to-end LLM inference it reduces latency by up to 54.68% while improving decode throughput by up to $s$7. The synthesized per-DQB overhead is 0.127 $s$8 area and 0.355 W power in a 12 nm CMOS process. The main tradeoffs are batch-size dependence, deployment-time layout preparation, GPU-side region lookup and tag generation, and dependence on custom HBM base dies.

3. StreamDQ-style streaming aggregation over unstructured data

A different usage of the term arises in streaming query processing over unstructured streams. In this line of work, the concrete system is InQuest, which targets streaming aggregation queries over video, audio, and text, with expensive computation performed by an oracle model and cheap approximation by a proxy. The supported query class includes COUNT, SUM, and AVG with an optional predicate computed by the oracle, using a Flink-SQL-like syntax with TUMBLE(...), [ORACLE](https://www.emergentmind.com/topics/oracle) [LIMIT](https://www.emergentmind.com/topics/limit) o, optional DURATION, and USING proxy. The output is produced in real time, segment by segment (Russo et al., 2023).

The motivation is the inadequacy of prior batch or video-specific systems. Methods such as NoScope, Tahoma, ABae, SUPG, and ExSample often require access to the full dataset before query execution, global knowledge of proxy-score distributions, or entire-stream buffering for model training and validation. Streaming systems that do operate online are frequently specialized to video and do not generalize cleanly to text or arbitrary proxy/oracle pairs. InQuest is positioned precisely at this gap: real-time approximate query processing over multiple modalities of large unstructured streams with statistical guarantees.

Formally, if $s$9 is the stream, $z$0 is the oracle predicate, $z$1 is the query expression value, and $z$2 is the per-segment oracle sampling budget, the mean case estimates

$z$3

with quality measured by mean squared error $z$4. InQuest combines four mechanisms: proxy scoring on all records, pilot sampling on the first segment, stratified sampling with defensive allocation, and online reservoir sampling within strata. The stream is divided into $z$5 strata by proxy-score quantiles. The total oracle budget is split into a defensive budget $z$6, spread evenly across strata, and a dynamic budget $z$7, allocated according to estimated stratum variance and predicate positivity. After each segment, stratification and allocation are updated using EWMA, and the latest estimate $z$8 is available continuously.

Theoretical analysis is provided for stationary streams with sub-Gaussian oracle-sampled values and at least one stratum with nonzero predicate-positive rate. With $z$9, the allocation estimate converges to the optimal allocation at rate

$\rightarrow$0

and if $\rightarrow$1, the expected MSE satisfies

$\rightarrow$2

Empirically, on six real-world video and text datasets, InQuest achieves the same RMSE as two streaming baselines with up to $\rightarrow$3 fewer oracle invocations, and up to $\rightarrow$4 lower RMSE than ABae at fixed oracle budget. This usage of “StreamDQ” therefore denotes a statistically grounded approximate query-processing setting rather than a named system.

4. Stream DaQ as stream-first data quality monitoring

Another explicit usage is Stream DaQ, where “StreamDQ” is simply a compact reference to a stream-first data quality framework for unbounded data streams. The premise is that static data-quality tooling and incremental batch-style checking are poorly matched to streams that never become complete, where recent data often matters most and short-lived errors can be operationally significant (Papastergios et al., 6 Jun 2025).

The formal model begins with a stream element

$\rightarrow$5

and a stream window

$\rightarrow$6

Measurement, assessment, and monitoring are then separated. Stream quality measurement computes a numeric value

$\rightarrow$7

stream quality assessment evaluates that measurement against a constraint

$\rightarrow$8

and continuous monitoring emits the sequence

$\rightarrow$9

The framework’s central output is a quality meta-stream,

$\rightarrow$0

which makes data quality itself a streaming artifact that downstream systems can consume.

A major novelty is dynamic constraint adaptation. Instead of comparing a current window against a fixed global threshold, Stream DaQ can evaluate

$\rightarrow$1

where $\rightarrow$2 is a configurable horizon. This makes quality assessment contextual and time-local rather than diluted by full-history aggregates. The framework supports time-based tumbling and sliding windows, count-based windows, and session-based windows, as well as keyed, reference-based, tuple-at-a-time, and compositional constraints. The paper states that it unifies and adapts more than 30 quality checks fragmented across Apache Griffin, dbt Core, Deequ, Evidently, Great Expectations, MobyDQ, and Soda Core.

The implementation is an open-source Python framework built on Pathway. In evaluation on the Reddit Comments Dataset, replayed as a timestamped stream with 100K to 500K records, Stream DaQ is compared primarily with Amazon Deequ. The reported pattern is that small windows show the largest gains, reaching up to $\rightarrow$3, with higher throughput and lower latency for 1-minute and 5-minute tumbling windows, while larger 30- and 60-minute windows are more comparable. This suggests that in this usage, “StreamDQ” denotes continuous quality-awareness infrastructure rather than query acceleration or hardware offload.

5. Other research usages of the label

The term also appears as shorthand in several adjacent areas of stream algorithms and temporal modeling. In per-item quantile estimation for heavy hitters, the problem is to track quantiles over a stream of $\rightarrow$4 tuples without allocating a full quantile sketch per item. The relevant algorithms are SQUARE, QUASI, and SQUAD. SQUAD combines background reservoir sampling with a Space Saving structure and per-item quantile sketches, using a sample size

$\rightarrow$5

and

$\rightarrow$6

Space Saving entries, yielding space

$\rightarrow$7

rather than the $\rightarrow$8 dependence of SQUARE and QUASI (Shahout et al., 2022).

In autonomous-driving HD-map construction, Stream Query Denoising is a training strategy layered onto StreamMapNet. Instead of learning temporal propagation only implicitly, it perturbs previous-frame ground truth, constructs denoising queries, and trains the model to reconstruct current-frame ground truth. It uses Adaptive Temporal Matching based on bidirectional Chamfer distance,

$\rightarrow$9

with a scale-adaptive threshold

$\rightarrow$0

and a dynamic noising decay factor

$\rightarrow$1

The resulting SQD-MapNet improves StreamMapNet from 60.4 to 63.9 mAP on nuScenes at $\rightarrow$2 m, and from 60.6 to 64.0 mAP at $\rightarrow$3 m (Wang et al., 2024).

In streaming video analysis, StreamDEQ addresses a different problem: reducing per-frame compute by reusing the previous frame’s fixed-point representation in deep equilibrium models. Instead of solving each frame from scratch, it uses

$\rightarrow$4

as the warm start for the current frame. Across semantic segmentation, video object detection, and pose estimation, it reports on-par accuracy with the baseline while being more than $\rightarrow$5 faster (Ertenli et al., 2022). These usages share the idea of temporal reuse or streaming adaptation, but not a common formalism.

6. Related stream-processing context and sources of confusion

The multiplicity of meanings is easier to interpret against broader stream-processing research. One reference point is exact incremental query processing, where SQL-like queries are transformed into homomorphic state-maintenance programs that return accurate snapshot answers at each time interval. In that setting, incremental evaluation maintains only minimal sufficient state,

$\rightarrow$6

and the result is exact rather than approximate for the supported query class (Fegaras, 2015). This provides a direct contrast with InQuest-style approximate estimation, where proxy models and sampling trade oracle cost against RMSE.

A second reference point is delayed view semantics and Dynamic Tables, which treat stream processing as asynchronous eager computation of derived SQL results. A Dynamic Table is defined to equal the result of its query at some point in the past, its data timestamp, and refresh is implemented through incremental view maintenance rather than explicit user-managed streaming logic. The system targets a latency spectrum from seconds to hours rather than the sub-second regime emphasized by many conventional stream processors (Sotolongo et al., 14 Apr 2025). This broadens the context in which terms like “StreamDQ” are used: some works focus on real-time inference bottlenecks, some on low-latency approximate analytics, some on declarative freshness-aware maintenance, and some on quality monitoring or temporal denoising.

The main encyclopedic point is therefore disambiguation. “StreamDQ” can denote a specific HBM-resident dequantization architecture, a stream-first data quality framework, or a shorthand for stream-oriented query and monitoring problems in adjacent literature. This suggests a family resemblance centered on streaming, bounded online state, and avoidance of full recomputation, but not a unified research lineage or a single stable definition across papers.