Search arXiv⌕ Search

arXiv · 2610.33932

FastSAR: High-Throughput, High-Fidelity Open-Source SAR Image Formation on CPUs, GPUs and TPUs

Abstract

Exact backprojection of a spaceborne SAR collection needs one interpolated read per pixel for every pulse; for the 12,207 by 8,808 pixel Umbra image of the Panama Canal this balloons to 1.6 trillion reads. FastSAR is an open-source library for SAR image formation on CPUs, NVIDIA GPUs and Google TPUs, with factorized backprojection, exact backprojection and polar format behind one Python interface and readers for the vendors' phase-history files. Its factorized kernels form the Panama image in 11.2 s on a 16-vCPU instance, 3.0 s on an NVIDIA L4, 0.6 s on an H100 and 2.9 s on a TPU v6e, with errors of -56 to -63 dB relative to a float64 exact backprojection in three regions over six cloud devices; the L4, a modest GPU, gives the lowest cost of the six at 0.59 US dollars per thousand images. At exact backprojection FastSAR is as fast as the MatX backprojection example, by far the fastest open-source implementation found (10.9 against 11.6 s at the same accuracy, with MatX's pixel coordinates in float64); its factorized algorithm is 3.8 times faster than MatX, and its polar format forms the image in 1.4 s on the L4 at -32 dB. On five Capella collections in three modes the worst-region error is below -59 dB.

Explore related subjects

Keep this discovery

Explore connections, maps & timelines

BibTeXRIS

Paul Singerman, Tom Braun. 2026-10-24. FastSAR: High-Throughput, High-Fidelity Open-Source SAR Image Formation on CPUs, GPUs and TPUs. https://arxiv.org/abs/2610.33932

Cite the original work for its findings. Save a collection to share your selection of sources.

KEEP EXPLORING

Related papers

DeepInfer-Mac: Running a 750B-Class MoE on a 24 GB Laptop

DeepInfer-Mac runs the 750B-class DeepSeek-V4.1-Flash model on a MacBook Air with 24 GB of unified memory. A mixed low-bit conversion occupies 338 GiB on the internal SSD. About 7.6 GiB of weights remain resident; routed experts and Engram rows are loaded when needed. This separation makes the model executable, but it leaves each generated token waiting for a succession of storage reads. We organize expert weights so that reads fill reusable GPU buffers directly, and couple cache allocation with the lifetime of those buffers. In end-to-end runs, the system generates English, Chinese and code at 0.21-0.72 tokens per second, with a largest sampled process footprint of 16.73 GiB across the tested requests. Matched decode comparisons show a 21.0% throughput gain from next-layer prefetching over resident-expert overlap alone, at the cost of additional reads. Longer prompts remain costly. We describe the design, provide the implementation and measurement scripts, and identify the limits of this operating point: a model far larger than memory can run locally, while storage and prefill still govern the user's wait.

cs.PF↗

DFIP: Decision-Focused Inference Path for System One Models

System One (decision) models return small structured answers, but can retain host dispatch, GPU launch overhead and full-vocabulary projection. We present DFIP (Decision-Focused Inference Path), an empirical systems study of established inference techniques in PPLX-Decider, Liquid d1-3B, Clef-Flash and GLiNER2.5-Decide. Selective CUDA graph replay, candidate-token projection and schema-compatible length-aware batching are applied at compatible model boundaries. We compare resident requests with stronger native baselines, audit exposed answers and measure changing arrivals. With optional native Qwen kernels installed, short Boolean resident speedups over strengthened native are 2.47x for Decider across five containers and 1.45x for Clef across four of five planned containers; Clef's fifth fails in native preflight. Liquid is effectively tied with released compilation; replay supplies most of its eager-baseline gain, while projection alone adds little full-request benefit. In a one-worker GLiNER follow-up, length-aware batching is 1.40x faster than compiled native FIFO batching on a diverse resident trace, but has worse arrival p95. Decider and Clef audits cover 3,024 decisions per model and preserve all 1,112 returned choices, while Clef changes scores, probabilities and serving confidence thresholds. Diverse external arrivals reverse fixed-shape replay gains and expose overload losses and a replay-path CUDA error. The results identify workload-specific acceleration and its limits, rather than a universal optimizer or production readiness.

cs.PF↗

Measuring the Energy Cost of Completing Tasks with Quantized Language-Model Agents

Quantization reduces the memory and energy needed to serve large language models (LLMs) and AI agents for coding and data analysis can now run on locally hosted LLMs. In practice, this benefit is commonly benchmarked per output token. Yet an agent calls its model repeatedly, runs tools, and revises its work, and quantization can change both how much the agent generates and whether it succeeds. Existing energy studies either compare quantized models on single requests or measure agents at one fixed precision, overlooking how a change in precision plays out across a complete agent task. To address this gap, this paper presents the first characterization of the task-level energy trade-offs of model quantization in locally hosted agents. We develop 29 agent tasks with automatic pass/fail checks in six families, ranging from single-answer SQL analytics to multi-step repository bug fixing, and measure CPU and GPU energy per output token and per completed task for 4-bit and 8-bit versions of two open-weight models on bare-metal NVIDIA A100 nodes with llama$.$cpp. Our findings reveal that 4-bit precision generally saves energy per token, though whether it saves energy per completed task is task dependent and changes with the model and the execution budget (i.e., limits on turns, tokens, and time). We trace this discrepancy to the extra tokens needed to complete a task in full, which translates into using up to 3.5 times as much energy per completed task. These findings offer actionable guidance for developers and operators choosing model precision for agents, showing how tokens per completed task, set against the per-token saving, reveal whether lower precision completes the work with less energy.

cs.PF↗