{"id":"8be33374-9583-48b4-8ef9-400c725af1ed","arxiv_id":"2607.15621","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"A 337M action expert that reads a frozen 7B VLM's per-layer KV cache every tick, trained with randomized staleness, lifts CARLA route completion from 37% to 94% at full 20 Hz control rate.","lead":"An asynchronous fast-slow driving system lets a frozen 7B vision-language model think at 5 Hz while a 337M action module issues a fresh steering decision every 50 ms tick. In CARLA closed-loop tests it raises route completion from 37% to 94% over a frame-skipping baseline while keeping per-tick model cost flat.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Teacher-forced state tokens plus randomized staleness are asserted, not demonstrated, to close the train/deploy gap; the 20 Hz result rests on a single self-fed realization and an unspecified δmax.","rationale":"The reader's weakest_assumption identifies the same load-bearing premise: randomized staleness plus teacher-forced state tokens must transfer to closed-loop self-prediction under a stale cache. This is the condition that makes the 20 Hz route-completion gain interpretable. The paper's open-loop ablations cannot validate this premise because they use teacher forcing and δ=0; the only direct evidence is the closed-loop runs, which are few and do not isolate the state-token feedback loop. My concrete test directly measures that gap by comparing self-fed and oracle-fed state tokens in the closed-loop benchmark. The paper is otherwise honest and well-structured, with a plausible architecture and an explicit limitations section, so I do not see grounds to move beyond the reader's conditional assessment; the concern warrants a targeted experiment, not rejection.","tokens_in":10303,"tokens_out":11149,"duration_ms":121020,"concrete_test":"On the 32 LangAuto-Short town05 routes, run the trained expert closed-loop under two state-token conditions with K=4 and at least 5 seeds each: (a) the normal self-generated previous waypoints as in §3.3, and (b) privileged oracle previous waypoints taken from the CARLA route/trajectory at the previous tick. Compare route completion. If condition (a) drops by more than the reported run-to-run spread (~5 RC points) relative to (b), teacher forcing has not closed the deployment gap; if the two match, the concern is resolved. Also report the actual δmax used in training.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central mechanism in §3.2 is that randomized staleness (δ ∼ U{0,...,δmax}) and teacher-forced state tokens under Gaussian noise/dropout align training with asynchronous deployment. §3.3 asserts test-time staleness is bounded by K−1 ticks and 'stays inside the training distribution,' but δmax is never specified, so this containment cannot be verified. More importantly, at deployment the state token encodes the expert's own previous predictions produced under a stale cache, while training always feeds ground-truth previous waypoints. The open-loop L1 results in Table 1 and the randomized-δ ablation are all teacher-forced and evaluated at δ=0; no closed-loop experiment varies the source of the state token or the cache lag at test time. The two-run closed-loop result is consistent with the premise, but it is a single realization of the feedback loop, and the key 10 Hz vs 20 Hz isolation row is a single run. The paper's own Limitations section flags small run counts and long-route safety failures but does not address this exposure-bias gap. If the self-generated state-token distribution at deployment differs from teacher-forced noise, the claimed 20 Hz completion gain may not transfer beyond the tested rollouts.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes an asynchronous fast-slow vision-language-action architecture for closed-loop driving. A frozen 7B LMDrive backbone is treated as a slow context provider: it incrementally appends visual tokens to its per-layer KV cache every K=4 ticks (5 Hz), and the cached representation is reused by a 337M action expert that runs at every 50 ms simulation tick (20 Hz). The expert cross-attends into the cached backbone keys/values at all 32 layers, plus the current frame and a state token encoding previous waypoints, previous control, speed, and target point. To match deployment, training uses randomized staleness: for each supervised frame, the backbone prefix is masked to end δ frames earlier, with δ drawn uniformly from {0,...,δmax}. The paper reports open-loop waypoint L1 improvements (0.123 → 0.031), a golden test for cache equivalence (waypoint drift < 4 mm), CARLA LangAuto-Short closed-loop results (route completion 37.0 → 94.0 over the frame-skipping LMDrive baseline, and 82.1 → 94.0 when moving the same expert from 10 Hz to 20 Hz), zero-shot transfer to unseen towns (84–94% completion), and a flat per-tick model cost of about 32 ms independent of history length. The central claim is that per-tick freshness, affordable only through cached context, is what drives the route-completion gain, while the expert itself drives the driving-score gain.","tokens_in":10640,"tokens_out":4555,"duration_ms":58519,"significance":"If the claims hold, this is a useful architectural contribution: it shows that a large frozen VLA backbone can be repurposed as an incrementally updated cache while a small expert produces fresh control at a higher rate, directly addressing the inference-latency bottleneck of language-conditioned driving agents. The paper has several concrete strengths: the cache-equivalence golden test (< 4 mm) is a machine-checkable safeguard; the evaluation uses a public LMDrive checkpoint and a standard CARLA benchmark; the architecture leaves the backbone frozen and avoids backprop through 7B parameters; and the randomized-staleness training idea is a clean, falsifiable mechanism for aligning training with asynchronous deployment. The result is potentially significant for closed-loop VLA systems because it offers a way to separate expensive semantic/temporal reasoning from fast reactive control without retraining the backbone. However, the empirical evidence is currently too thin to fully support the headline numbers: the key freshness isolation row is a single run, transfer results are single-run, the staleness bound δmax is unspecified, and the exposure-bias gap between teacher-forced traini","major_comments":[{"comment":"The value of δmax is never specified. At deployment the cache lags by up to K−1 = 3 ticks, and §3.3 asserts that this 'stays inside the training distribution,' but without δmax this containment cannot be verified: if δmax < 3, the deployed staleness is out of distribution; if δmax is much larger, the training distribution is much broader than deployment. The authors should report δmax and ideally show sensitivity to the chosen δmax, including a closed-loop sweep over K or over test-time staleness. This is load-bearing because randomized staleness is the mechanism claimed to align training with asynchronous execution.","section":"§3.2 and §3.3"},{"comment":"The key freshness isolation — 10 Hz frame-skipped vs 20 Hz per-tick, raising route completion from 82.1 to 94.0 and cutting red-light violations — rests on a single run for the 10 Hz row, and the transfer table (Table 4) also has single runs per agent and town. The two-run baseline and ours give only half-range error bars, so the 82.1→94.0 difference has no variance estimate. Given that the headline abstract claim is built on this comparison, at least 5–10 independent runs per configuration (or an explicit statement of computational limits and a bootstrap analysis) are needed before the per-tick-freshness effect can be considered robust.","section":"§4.3, Table 2"},{"comment":"The train/deploy gap is asserted, not demonstrated. During training the state token is teacher-forced with ground-truth previous waypoints under Gaussian noise and random dropout; at deployment the expert consumes its own previous predictions produced under a potentially stale cache. The open-loop L1 improvements and the randomized-δ ablation are evaluated under the synchronous δ=0 protocol with teacher forcing, so they do not directly test either self-feeding or cache lag. The paper's Limitations section flags small run counts and long-route hazards but not this exposure-bias gap. A targeted closed-loop ablation (e.g., feeding ground-truth state tokens vs self-generated state tokens at test time, or varying test-time K over a range and measuring route completion) would substantially strengthen the claim that staleness-augmented training transfers to asynchronous deployment.","section":"§3.2 and §4.2"},{"comment":"There is a tension between the title/abstract claim of 'Act at 20 Hz' and the measured latencies. The median end-to-end agent step is 58 ms and the wall-clock rate is about 17 Hz, while the per-tick model compute is 32 ms. The text says that in CARLA synchronous mode the vehicle still receives fresh control at every tick, but if the agent step takes 58 ms it cannot sustain true 50 ms ticks. The authors should clarify whether the simulator tick is slowed by the agent computation, and report the actual control rate at deployment. The 20 Hz framing is central to the paper, so this must be made precise.","section":"§4.4"}],"minor_comments":[{"comment":"The phrase 'Our infraction score is lower' is ambiguous or inverted: in CARLA, a higher infraction score is better. The authors appear to mean that the infraction score is worse (0.37 vs 0.80). Please state the direction explicitly.","section":"§4.3"},{"comment":"The legend for the randomized-δ curve appears as 'randomized  (ours)' with a missing δ symbol; please fix the typography so the notation matches §3.2.","section":"Figure 5"},{"comment":"The authors acknowledge that the open-loop gap partly reflects the privileged state-token signal. This is good, but the paper should also report open-loop performance with self-generated (non-teacher-forced) state tokens, since the closed-loop comparison is the only place this is checked.","section":"§4.2"},{"comment":"The captions mention 'T able' with a space; please correct the table formatting. Also, the units for per-kilometer infractions in §4.3 should be stated consistently (per kilometer is mentioned in prose, but not in the table).","section":"Table 1 and Table 2"},{"comment":"No code or trained expert weights are provided. Releasing the expert and evaluation scripts would materially improve reproducibility, especially given the small number of runs and the dependence on the public LMDrive checkpoint.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"The paper is clearly written and the architectural idea is appealing, but the central quantitative claims currently rest on very limited statistics and on an untested exposure-bias assumption. I would like to see the authors add repeated closed-loop runs, specify and ablate δmax, and provide at least one closed-loop experiment that directly varies the source of the state token (teacher-forced vs self-generated) and the test-time cache lag. If those experiments come out consistent with the current story, the paper could become a solid accept; as it stands, the evidence is not yet sufficient."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Here is my read. The paper tackles a real blocker — a 7B VLM can't run at 20 Hz, and frame-skipping means half the commands ignore new observations. The fix is clean: freeze the backbone, maintain its KV cache incrementally, and have a 337M expert cross-attend into that cache plus the current frame at every tick. The cache-as-interface design is the actual contribution, and the paper does the right supporting work: a golden test shows incremental prefill matches monolithic prefill to <4 mm, latency stays flat at ~32 ms independent of history, and a frame-skip ablation tries to separate expert quality from freshness. Open-loop L1 improves by ~4x and the zero-shot transfer to unseen towns is a nice sanity check. The paper is also unusually honest: it reports two runs per main config, single-run ablations, increased per-km collisions, and the long-route failure in the limitations.\n\nThe soft spots are real but localized. The central train/deploy argument is the weakest link. They train with randomized staleness δ but never report δmax, so the claim that test-time staleness 'stays inside the training distribution' is unverifiable. More importantly, at deployment the state token is the expert's own previous prediction produced under a stale cache, while training always teacher-forces ground-truth waypoints (plus noise/dropout). The paper asserts this limits exposure bias, and the open-loop ablation shows randomized δ helps in the teacher-forced regime, but there is no closed-loop experiment that varies the state-token source or the cache lag. That gap could matter: if the self-generated distribution drifts, the 82→94 completion gain from freshness could be partly an artifact of a lucky rollout. The single-run frame-skip row is doing a lot of work, and the transfer table is single-run per town. None of this is fatal — the architecture is plausible and the latency evidence is solid — but the headline claim should be treated as a demonstration, not an established result.\n\nI'd send this to peer review. The idea is worth engaging, the evaluation is on a public benchmark with a public baseline, and the authors have already been candid about the weak spots. What it needs is a reproducibility pass: specify δmax, release code/checkpoints, add error bars, and ideally a closed-loop run with a self-generated state token under controlled staleness. For me this is a conditional accept trajectory.","headline":"A genuinely useful fast-slow VLA architecture for closed-loop driving, honestly reported, but the core claim that randomized-staleness training closes the asynchronous gap is under-supported: teacher-forced state tokens and an unspecified δmax leave the deployment distribution untested.","tokens_in":11096,"tokens_out":2855,"would_cite":true,"duration_ms":32250,"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":"A frozen 7B vision-language model can drive at 20 Hz when a 337M action module reads its cached memory every tick.","keywords":["fast-slow architecture","vision-language-action model","closed-loop driving","key-value cache","asynchronous inference","randomized staleness","CARLA","real-time control"],"falsifier":"In closed loop, run the same trained expert at 20 Hz but force the backbone cache to be appended only every 8 ticks instead of 4 (or freeze it for the whole episode), keeping everything else identical. If route completion holds near 94.0, randomized-staleness training is not carrying the result; if completion drops sharply, the claim that test-time staleness must stay inside the trained range is confirmed.","tokens_in":10224,"feed_emoji":"🚗","tokens_out":7938,"duration_ms":88568,"temperature":0.7,"pith_summary":"The paper is trying to establish that the latency problem of language-guided driving is architectural, not fundamental. It shows that a frozen 7B vision-language backbone can act as a slowly updated context provider—maintaining a per-layer key-value cache of instruction and visual history—while a 337M action expert reads that cache plus the current camera frame at every 50 ms simulation tick to regress fresh waypoints. The central claim is that the cache lag this creates can be absorbed by training the expert under randomized staleness, and the reported result is a route-completion jump from 37.0 to 94.0 over a frame-skipping baseline at a per-tick model cost of 32 ms on a consumer GPU. A sympathetic reader would care because it offers a concrete way to keep a large language model's instruction-following and scene reasoning in the control loop without sacrificing control rate.","feed_headline":"Lift route completion 37 to 94 by acting every 50 ms tick","feed_subtitle":"A 337M action expert reads the big model's cached memory each frame, keeping fresh control on one GPU.","key_machinery":"The central object is the per-layer key-value cache of the frozen backbone, maintained by an incremental four-token append every K=4 ticks and rebuilt only on instruction changes, notice arrivals, or episode boundaries. The expert's ten tokens project into the backbone's attention geometry and cross-attend into the cached keys and values at each of 32 layers, while the backbone never attends to the expert, so the cache is identical with or without the expert running. Randomized-staleness training draws a random lag δ for each sample and truncates the backbone prefix visible to the expert, teaching the expert to fuse an outdated scene summary with fresh per-tick evidence.","core_discovery":"On the paper's own terms, the discovery is that a frozen 7B vision-language backbone, which never attends back to the expert, can be turned into a cached representation of the scene that a 337M action expert consumes at full control rate. Trained with randomized staleness to match the asynchronous cache lag it will meet at deployment, the expert regresses five waypoints per 50 ms tick and lifts closed-loop route completion on LangAuto-Short from 37.0 to 94.0 over the frame-skipping baseline, transfers zero-shot to unseen towns at 84–94% completion, and reduces open-loop waypoint error by nearly a factor of four, all at a per-tick model cost of 32 ms that does not grow with history length.","pith_inferences":["We infer that the asymmetric attention design (backbone never attends to expert) makes the cache a reusable interface: the same cached scene representation could feed multiple fast modules—such as a safety monitor or a different action head—without extra backbone cost, a property the paper notes but does not exploit.","We infer that randomized-staleness training is a general recipe for any policy that consumes a slowly updated latent context alongside fast sensor input, not just driving; robot manipulation with a slow VLM planner and a fast low-level policy is a natural next application.","We infer that the paper's own long-route result (85% completion but collapsed infraction score) suggests the fast path's next bottleneck is hazard negotiation under dense traffic, pointing to training on longer, signalized clips rather than a change in architecture.","We infer that the measured 32 ms per-tick cost on a consumer GPU leaves headroom for quantization or distillation of the expert, which could be tested by checking whether the 20 Hz cadence and completion gains survive on lower-cost hardware."],"forward_implications":["Fresh control at every simulation tick is achievable for a language-conditioned driving agent on a single consumer GPU; the rate mismatch is an architectural choice, not an invariant of large vision-language models.","The route-completion gain and the reductions in red-light violations, route deviations, and timeouts come from per-tick freshness rather than from the expert's waypoint quality alone, as the frame-skip ablation shows.","Zero-shot transfer to unseen towns, holding 84–94% route completion where the baseline reaches 31–41%, indicates the expert learns to read the backbone's cache and the current frame rather than memorizing a town's geometry.","Incremental cache appending is numerically faithful to full recomputation (waypoint differences below 4 mm), so cache reuse preserves the backbone's representation.","Because the per-tick cost is independent of history length, the approach keeps the 50 ms tick budget even as the agent's visual memory grows."],"fun_headline_variants":["Fast-slow driving: 7B VLM cache, 337M expert, 50 ms ticks","At 5 Hz thinks, 20 Hz acts: driving with a frozen 7B VLM","Zero-shot driving: 94% completion on unseen towns, 32 ms/tick","Fresh control every 50 ms: route completion 37→94% in CARLA","Frozen VLM as scene cache lets a 337M expert drive at 20 Hz"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The load-bearing premise is that randomized-staleness training with teacher-forced previous waypoints closes the train/deploy gap for an expert that at test time reads a cache lagging by up to K ticks and consumes its own previously predicted waypoints; if that gap is not closed, the 20 Hz closed-loop results would not transfer to deployment.","fun_headline_variants_meta":{"raw":{"variants":["Fast-slow driving: 7B VLM cache, 337M expert, 50 ms ticks","At 5 Hz thinks, 20 Hz acts: driving with a frozen 7B VLM","Zero-shot driving: 94% completion on unseen towns, 32 ms/tick","Fresh control every 50 ms: route completion 37→94% in CARLA","Frozen VLM as scene cache lets a 337M expert drive at 20 Hz"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000344,"raw_usage":{"total_tokens":1797,"prompt_tokens":887,"completion_tokens":910,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":631,"completion_tokens_details":{"reasoning_tokens":791}},"tokens_in":631,"tokens_out":910,"duration_ms":11030,"temperature":1.0,"reasoning_tokens":791,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-01T22:43:20.690327+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"In closed loop, run the same trained expert at 20 Hz but force the backbone cache to be appended only every 8 ticks instead of 4 (or freeze it for the whole episode), keeping everything else identical. If route completion holds near 94.0, randomized-staleness training is not carrying the result; if completion drops sharply, the claim that test-time staleness must stay inside the trained range is confirmed.","supporting_citations":[],"review_version":1}