{"id":"6de668fb-9c5c-4fa7-ae83-43318b3a8b79","arxiv_id":"2412.19628","paper_version":3,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"RecConv recursively decomposes feature maps into multiple scales with shared small-kernel depthwise convolutions to grow the effective receptive field to k times 2^ell at roughly constant FLOPs, yielding the RecNeXt backbone family.","lead":"This paper presents RecConv, a way to build convolutions with very large effective receptive fields from small kernels by recursively downsampling and recombining feature maps at multiple scales. It reports mobile vision backbones that match or beat existing efficient models on ImageNet, COCO, and ADE20K while keeping parameter counts and FLOPs low.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Table 2's FLOPs accounting omits bilinear upsampling and multi-scale data movement, and the paper's own numbers (4538 to 384 im/s in Table 5) show the practical cost is not constant; the mathematical bound is correct, but the central efficiency claim is overstated.","rationale":"The reader's weakest assumption identifies the same general area of concern: the FLOPs-based efficiency claim does not align with measured throughput. I agree that this is the most load-bearing issue because the paper's motivation and title are explicitly about efficiency, and the complexity table (Table 2) omits the very operations whose runtime cost is visible in the paper's own speed measurements. However, I would not call the paper's central construction unsound. The 5/3 FLOPs bound is mathematically correct for depthwise convolution MACs, and even if bilinear interpolation MACs were included, the geometric decay of spatial sizes keeps the total operation count bounded independently of ell. The real gap is between MACs and wall-clock time: recursive multi-scale feature movement and small-kernel launches are inefficient on GPUs, which is why throughput collapses despite nearly unchanged MACs. On the target mobile NPU the latency increase is small (0.1 ms), so the practical significance of the concern depends on the deployment target. I therefore view this as a framing/accounting problem that requires a revision of the abstract and complexity tables, not a rejection of the method. I also noted a secondary issue: Algorithm 1's construction `self.conv = [Conv(...)] * (level+1)` in Python creates a list of references to the same module, and a plain Python list is not registered by PyTorch as a submodule, so the provided pseudo-code would not train as written. This is almost certainly a simplification or typo, but it means the released code, not the pseudo-code, is the authoritative artifact for verifying the ell+2 parameter growth. That reinforces the need for the same reproducibility check. Overall, the reader's conditional verdict is appropriate: the method appears sound and the experiments are informative, but the efficiency claims must be made precise and the throughput caveat handled in the presentation.","tokens_in":22715,"tokens_out":16334,"duration_ms":154635,"concrete_test":"Use the released code to reproduce the Table 5 baseline and recursive models on the same RTX3090 and iPhone 13, and profile the RecConv module (torch.profiler on GPU; Xcode/CoreML Instruments on NPU) to attribute latency and throughput to depthwise convolutions, bilinear upsampling, and memory movement. If the non-convolution operations account for the dominant share of the 4538 to 384 im/s throughput drop, the paper's 'constant FLOPs' efficiency claim should be revised to 'constant depthwise-convolution FLOPs' and the abstract and Figure 1 reframed; if instead the drop is caused by the depthwise convs themselves, the Table 2 accounting is the issue. The same breakdown on the NPU would show whether the mobile efficiency claim survives.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central theoretical claim — that RecConv keeps FLOPs bounded by 5/3 times the base depthwise convolution (Eq. 4) while the ERF grows as k*2^ell — is arithmetically correct under the accounting of Table 2, which counts only depthwise convolution MACs. The load-bearing problem is that the paper elevates this narrow FLOP count into the headline efficiency statement 'maintaining constant FLOPs regardless of ERF expansion.' The omitted operations, bilinear interpolation (Interp^up in Eq. 3 and Algorithm 1) and the multi-scale data movement (downsampled tensors, repeated kernel launches, memory traffic), are not free and are precisely the operations whose count and hardware inefficiency grow with the decomposition level ell. The paper's own Table 5 provides a direct contradiction: adding recursive decomposition with [4,3,2,1] levels and a 5x5 kernel increases MACs by only ~6% (0.82 to 0.87 G) but drops GPU throughput from 4538 to 384 im/s, an 11.8x slowdown; Table 1 shows RecNeXt-M3 at 314 im/s versus 3604 im/s for RepViT-M1.1. On the iPhone 13 NPU the latency penalty is small (1.6 vs 1.5 ms), so the method may still be viable for the stated mobile target, but the abstract's blanket 'constant FLOPs/efficient' framing is not supported by the reported wall-clock metrics. The theoretical complexity result should be stated as 'constant convolution FLOPs under a depthwise-MAC-only accounting,' and the practical efficiency claim should be conditioned on hardware and the cost of the upsampling chain. This does not attack the soundness of the recursive construction or the reported accuracy gains.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"This manuscript introduces RecConv, a recursive multi-scale decomposition of a depthwise convolution into small-kernel convolutions on progressively downsampled feature maps, using a shared stride-2 downsampling convolution, level-wise depthwise convolutions, and bilinear upsampling aggregation. The central claim is that for a base kernel of size k and ell levels of decomposition, RecConv achieves an effective receptive field of k*2^ell with parameter growth of only (ell+2) times the base kernel and convolution FLOPs bounded by 5/3 times the base depthwise convolution, in contrast to the 4^ell growth of standard and depthwise large-kernel convolutions. The authors instantiate this module in RecNeXt, a RepViT/RepNeXt-style mobile backbone, and report experiments on ImageNet-1K classification, MS-COCO detection and instance segmentation, ADE20K semantic segmentation, shape-bias analysis, and ablations, together with an implementation sketch and a code link.","tokens_in":23074,"tokens_out":11251,"duration_ms":101548,"significance":"The theoretical complexity relation is simple, transparent, and arithmetically correct under the stated depthwise-MAC-only accounting, and the architectural idea is a clean adaptation of WTConv to mobile settings. If the implementation matches the corrected description, the parameter-efficiency property is a useful design principle for large-receptive-field convnets. The paper also provides training details, two algorithm listings, a code link, and broad empirical validation across multiple tasks and model scales, which strengthens reproducibility. The main caveat is that the headline efficiency claim is based on a narrow FLOP definition and is not supported by the reported wall-clock throughput; this needs to be qualified before the central efficiency framing can be accepted.","major_comments":[{"comment":"The pseudocode line `self.conv = [Conv(**kwargs)] * (level+1)` is a Python aliasing error: it creates a list of references to one single Conv module. If taken literally, all decomposition levels share one set of convolution weights, so the parameter count would be 2 times the base kernel rather than the (ell+2) times claimed in Table 2; if this is only a typo, the code should create independent modules via a ModuleList comprehension. This discrepancy is load-bearing because the linear parameter-growth claim depends on having ell+1 independent level convolutions plus the shared downsampling convolution. Please correct the listing and verify that the released code matches the corrected version.","section":"Section 3.2, Algorithm 1 and Table 2"},{"comment":"The statement that RecConv maintains 'constant FLOPs' regardless of ERF expansion is only valid for the depthwise convolution MACs counted in Table 2; bilinear upsampling and the multi-scale data movement are excluded from that accounting. The paper's own measurements show a much larger practical cost: in Table 5, adding recursive decomposition with [4,3,2,1] levels and 5x5 kernels raises MACs from 0.82 G to 0.87 G but drops GPU throughput from 4538 to 384 im/s, and Table 1 reports RecNeXt-M3 at 314 im/s versus 3604 im/s for RepViT-M1.1. The Limitations section acknowledges this, but the abstract's unqualified efficiency claim and the 'constant FLOPs' phrase should be revised to, for example, 'bounded convolution FLOPs under a depthwise-MAC-only accounting,' with practical efficiency conditioned on hardware and resampling costs.","section":"Abstract, Section 3.2, Tables 1 and 5"},{"comment":"There is an internal inconsistency in the reported accuracy of RecNeXt-M5: the text says 'RecNeXt-M5 plateaus at 81.6% top-1 accuracy,' while Table 3 reports 82.9% for RecNeXt-M5 and Table 1 reports 83.3% with distillation. In addition, the claim that RecNeXt-M3 'exceeds other leading models' is contradicted by Table 3, where FastViT-SA12 and RepViT-M1.5 have higher top-1 accuracy. Please correct the numbers and qualify the comparison to models of the same scale.","section":"Section 4.1 versus Table 3"}],"minor_comments":[{"comment":"Equation (4) mixes a finite sum with an infinite-series bound in a way that is hard to read; please write the finite-sum expression first and then state the limit as ell grows.","section":"Equation (4)"},{"comment":"The 'Standard' row packs the channel factor into the 4^ell term; presenting parameters and FLOPs as k^2*C^2*4^ell and k^2*C^2*H*W*4^ell would remove ambiguity about the comparison to RecConv's depthwise operations.","section":"Table 2"},{"comment":"The diagram in Figure 4 appears to contain a stray external image URL from a Substack CDN in place of a vector graphic; this placeholder should be replaced.","section":"Figure 4"},{"comment":"Even after fixing the aliasing, the list assigned to `self.conv` should be wrapped in `nn.ModuleList` (or the modules should otherwise be registered) so that the parameters are discoverable by PyTorch.","section":"Algorithm 1"},{"comment":"The text alternates between 'constant FLOPs,' 'nearly constant FLOPs,' and 'maximum FLOPs increase of 5/3 times'; please align these terms so the abstract and Section 3.2 do not overstate what Equation (4) proves.","section":"Terminology throughout"},{"comment":"Please state explicitly in the Table 5 caption whether the reported MACs include bilinear/nearest upsampling and the downsampling convolution, or only the depthwise convolutions.","section":"Table 5 caption"}],"recommendation":"major_revision","confidential_remarks":"The theoretical derivation is sound under its stated accounting, and the empirical results are extensive, but the pseudocode/parameter-count contradiction and the unqualified 'constant FLOPs/efficient' framing are central enough that the revision should be checked carefully. It would be prudent to ask the authors to confirm, against the released code, whether the level convolutions are independent or shared; if they are actually shared, the parameter-scaling claim in Table 2 is wrong and the paper would need a deeper revision."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: this is a workmanlike mobile-backbone paper whose core recursive decomposition is explicitly inherited from WTConv; the genuinely new part is the engineering for mobile settings. The complexity math is correct under the accounting they state, but the abstract's 'constant FLOPs' headline does not survive contact with their own throughput measurements. Still, the empirical work is broad and mostly honest, and the method may be fine for its stated NPU target, so it deserves a serious referee.\n\nWhat's new and good: RecConv's specific design—shared stride-2 depthwise downsampling, same-channel scales, bilinear upsampling, and optional spatial-plus-channel recursion—is a reasonable adaptation of WTConv to small mobile backbones. The parameter and FLOPs derivation in Eq. 4 and Table 2 is arithmetically correct if you count depthwise convolution MACs only, and the paper is transparent that the FLOPs count excludes upsampling and data movement. The empirical package is unusually broad: ImageNet, COCO, ADE20K, ablations at two resolutions, shape-bias and OOD benchmarks, plus an interesting extension to linear attention. The authors also state the main limitation in their own Limitations section: the M series has the lowest throughput among comparable models because of bilinear interpolation. That counts in their favor.\n\nSoft spots: First, the 'constant FLOPs' claim is overstated. Their Table 5 shows adding recursion with a 5x5 kernel raises MACs from 0.82 to 0.87 G but drops GPU throughput from 4538 to 384 im/s, an 11.8x slowdown. The same table shows CPU latency roughly doubling. So the honest claim is 'constant depthwise-convolution FLOPs under a narrow accounting,' not 'constant FLOPs and efficient.' The paper would be stronger if it led with the NPU latency (1.6 vs 1.5 ms for RecNeXt-M3 vs RepViT-M1.1), where the cost is modest and the accuracy gains are real.\n\nSecond, the novelty over WTConv is incremental; the authors cite WTConv and list four differences, which is fair, but the marginal contribution is an engineering adaptation, not a new mechanism. Referees should hold it to that standard.\n\nThird, there is a concrete internal inconsistency in Section 4.1: the text says RecNeXt-M5 plateaus at 81.6% top-1 without distillation, but Table 3 reports 82.9% for that configuration. That needs fixing.\n\nOverall the central method is sound; the efficiency framing is the load-bearing weakness. For a reader working on mobile vision, this is a useful comparison point and a decent benchmark. I would send it to review, with the expectation that the authors revise the efficiency claims and correct the inconsistency.","headline":"Solid mobile adaptation of WTConv with a correct but narrowly-scoped complexity analysis; the 'constant FLOPs' framing is contradicted by the paper's own throughput numbers.","tokens_in":23604,"tokens_out":2986,"would_cite":true,"duration_ms":25352,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Recursive decomposition of a convolution yields an 80x80 effective receptive field with linear parameter growth and FLOPs bounded by a factor of 5/3.","keywords":["recursive convolution","effective receptive field","multi-frequency representation","lightweight vision backbone","depthwise convolution","bilinear upsampling","ImageNet classification","COCO object detection"],"falsifier":"A settling experiment would compare a RecConv block and a full large-kernel depthwise convolution of the same theoretical receptive field on the same hardware at matched FLOPs, measuring end-to-end latency and throughput; if the recursive version is consistently slower, the constant-FLOPs framing does not describe actual cost. A second check is to compute the gradient-based effective receptive field at each decomposition level and see whether the footprint actually reaches $k \\times 2^\\ell$.","tokens_in":22521,"feed_emoji":"🔁","tokens_out":8499,"duration_ms":76123,"temperature":0.7,"pith_summary":"RecConv, a recursively decomposed convolution, claims to build an effective receptive field of base kernel size $k$ times $2^\\ell$ using only small kernels, with parameter count growing linearly (a factor of $\\ell+2$) and FLOPs capped at $5/3$ times a single small-kernel convolution. The strategy splits the feature map into successively downsampled scales, applies a shared small-kernel depthwise convolution at each scale, and fuses them back with upsampling, so every block sees multi-frequency context. On backbone models built around this module, the paper reports accuracy gains on ImageNet classification, COCO detection, and ADE20K segmentation over lightweight baselines of similar FLOPs. The reason to care is that large receptive fields are the main route to global visual context; if this claim holds, mobile-sized networks can approach it without the parameter explosion of large kernels.","feed_headline":"Recursive kernels reach an 80x80 field at linear cost","feed_subtitle":"Small-kernel recursion buys large receptive fields for mobile vision, without big-kernel overhead.","key_machinery":"The carrying mechanism is a recursive decomposition with shared weights: one depthwise convolution of kernel $k$ with stride 2 maps each level to the next, and each level applies its own depthwise convolution of the same kernel, so the parameter count is the shared downsampler plus $\\ell+1$ convolutions rather than one growing kernel. The cost identity is a geometric series, written in the paper as\n$$1 + 2\\sum_{n=1}^{\\ell}\\frac{1}{4^n} < \\sum_{n=0}^{\\infty}2\\left(\\frac{1}{4}\\right)^{n} - 1 = \\frac{5}{3},$$\nbecause every halving of resolution cuts that level's FLOPs by four; this is what lets the effective receptive field grow as $k \\times 2^\\ell$ while the arithmetic stays bounded. Bilinear upsampling and element-wise addition are treated as parameter-free, and the design also permits simultaneous recursion along the channel dimension.","core_discovery":"At its core, the paper establishes a trade-off identity: for a base kernel $k$ and $\\ell$ decomposition levels, the effective receptive field is $k \\times 2^\\ell$ while the parameter factor over a single depthwise convolution is $\\ell+2$ and the FLOPs factor is at most $5/3$, against $4^\\ell$ for standard or depthwise convolution of the full kernel. This is achieved by recursively halving the spatial resolution with a shared strided depthwise convolution, running a small-kernel depthwise convolution at each level, and returning each level to full resolution by bilinear upsampling and addition. The authors call the result a multi-frequency representation and report that backbones using it, RecNeXt, surpass baseline lightweight backbones in accuracy without structural reparameterization or neural architecture search; for instance, the M3 model outperforms a leading lightweight backbone by 1.9 $AP^{box}$ on COCO at similar FLOPs.","pith_inferences":["Editorial extension: the paper's own tables show the \"constant FLOPs\" framing does not carry over to wall-clock speed: adding recursion or bilinear upsampling drops throughput from thousands to hundreds of images per second, a limitation the paper acknowledges in its limitations paragraph.","Editorial extension: the decomposition is effectively a coarse-to-fine recurrence over scales, so future work could unify RecConv with recurrent or state-space mixers and test whether the recursion itself, rather than the specific small kernels, carries the benefit.","Editorial extension: swapping bilinear upsampling for nearest interpolation or transposed convolution trades a small accuracy loss for large throughput gains, suggesting hardware-specific deployment rules rather than a single universal module.","Editorial extension: a direct gradient-based measurement of the effective receptive field across increasing decomposition levels would test whether the theoretical $k \\times 2^\\ell$ footprint is actually realized in trained models."],"forward_implications":["Lightweight backbones can reach effective receptive fields of $80 \\times 80$ with a $5 \\times 5$ base kernel and four decomposition levels, at parameter counts that grow by only $\\ell+2$ and FLOPs bounded by $5/3$.","Accuracy follows on standard benchmarks: RecNeXt reports higher ImageNet top-1 accuracy, higher COCO box and mask AP, and higher ADE20K mIoU than comparable lightweight baselines at similar FLOPs.","The recursion is a drop-in token mixer: it can replace the spatial operator in MetaNeXt-style blocks, and the paper shows variants with linear attention, nearest-neighbor upsampling, transposed convolutions, group convolutions, and channel concatenation.","Because the effective receptive field is determined by decomposition level, kernel size can stay small, preserving optimized small-kernel implementations.","No structural reparameterization or neural architecture search is required, which simplifies training and deployment."],"supporting_citations":[{"why":"Supplies the wavelet-decomposition multi-frequency idea that RecConv reworks into a shared-recursion form.","marker":"[15]"},{"why":"Provides the lightweight backbone architecture and training setup that RecNeXt builds on and is compared against.","marker":"[76]"},{"why":"Provides the multi-branch baseline whose design and evaluation protocol RecNeXt inherits.","marker":"[85]"},{"why":"Supplies the training recipe, CoreML latency protocol, and classification comparisons used in the main tables.","marker":"[43]"},{"why":"Defines the MetaNeXt token-mixer/channel-mixer block that RecConv plugs into.","marker":"[47]"},{"why":"Architecture base for the T/S/B variants where RecConv is combined with linear attention.","marker":"[78]"},{"why":"Supplies the partial-channel operation used in the shared-channel MetaNeXt blocks of the LSNet-derived variants.","marker":"[5]"}],"fun_headline_variants":["RecConv: exponential field, linear params, flat FLOPs","Recursive kernels: 80x80 field at 5/3 FLOPs","RecNeXt: 1.9 AP gain over RepViT at same FLOPs","Small-kernel recursion yields large receptive fields","Linear parameter growth, constant FLOPs, big field"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that FLOPs are the right measure of efficiency: the paper counts only convolution arithmetic and treats bilinear upsampling and multi-scale data movement as free, while its own latency and throughput tables show RecNeXt running several times slower than the baselines it is compared with.","fun_headline_variants_meta":{"raw":{"variants":["RecConv: exponential field, linear params, flat FLOPs","Recursive kernels: 80x80 field at 5/3 FLOPs","RecNeXt: 1.9 AP gain over RepViT at same FLOPs","Small-kernel recursion yields large receptive fields","Linear parameter growth, constant FLOPs, big field"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00026,"raw_usage":{"total_tokens":1605,"prompt_tokens":973,"completion_tokens":632,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":589,"completion_tokens_details":{"reasoning_tokens":538}},"tokens_in":589,"tokens_out":632,"duration_ms":6742,"temperature":1.0,"reasoning_tokens":538,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T00:08:30.447106+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A settling experiment would compare a RecConv block and a full large-kernel depthwise convolution of the same theoretical receptive field on the same hardware at matched FLOPs, measuring end-to-end latency and throughput; if the recursive version is consistently slower, the constant-FLOPs framing does not describe actual cost. A second check is to compute the gradient-based effective receptive field at each decomposition level and see whether the footprint actually reaches $k \\times 2^\\ell$.","supporting_citations":[{"cited_title":"Repnext: A fast multi-scale cnn using structural reparameterization, 2024","cited_arxiv_id":null,"evidence_quote":"Provides the multi-branch baseline whose design and evaluation protocol RecNeXt inherits."},{"cited_title":"Re- thinking vision transformers for mobilenet size and speed","cited_arxiv_id":null,"evidence_quote":"Supplies the training recipe, CoreML latency protocol, and classification comparisons used in the main tables."},{"cited_title":"Lsnet: See large, focus small, 2025","cited_arxiv_id":null,"evidence_quote":"Architecture base for the T/S/B variants where RecConv is combined with linear attention."}],"review_version":1}