{"id":"e0f6aad9-0f4d-4f7c-be70-a33aa8935985","arxiv_id":"2511.19711","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"An MPC-ML compiler that modularizes and auto-tunes operator approximations, delivering 1.2–1.8x speedups over an optimized baseline under user-set accuracy bounds.","lead":"CrypTorch is a compiler that lets machine-learning models run on encrypted data via multi-party computation, automatically choosing cheaper approximations for operations like Softmax without much accuracy loss. It reports 1.2–1.8x speedups over an optimized MPC baseline and 3.2–8.6x over the popular CrypTen framework.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Auto-tuner relies on non-MPC GPU runtime to rank approximations, but MPC-specific fixed-point effects (truncation, scaling, underflow) are absent from that search; no evidence yet that rankings transfer.","rationale":"I agree with the reader's weakest_assumption: the non-MPC validation of approximation candidates is the most load-bearing unverified assumption. The paper explicitly claims the non-MPC runtime captures all approximation-induced errors, yet the backend formalism (Section 4.4.2) and background (Section 2.2.1) show MPC-specific truncation, scaling, and underflow effects that the non-MPC runtime cannot capture. The absence of final accuracy numbers in Section 6 makes the 'without sacrificing accuracy' claim untestable from the manuscript. Other issues (abstract/body speedup-range discrepancies, modified CrypTen baseline) are real but secondary; they affect reporting consistency and comparison fairness, not the core validity of the auto-tuning mechanism. The proposed concrete test — running final tuned configurations on the real MPC backend and comparing accuracy — would settle whether the concern lands. The verdict remains CONDITIONAL, matching the reader's verdict, because the paper's central claim is plausible but requires this additional evidence.","tokens_in":33089,"tokens_out":1675,"duration_ms":19216,"concrete_test":"Take the tuned graphs produced by CrypTorch-eco, -moderate, and -aggressive for at least ViT-B/16 and BERT-SST2 (the configurations visualized in Figure 15), execute them on the actual MPC backend (CrypTen++) with the same held-out search/validation data, and report final task accuracy (ImageNet top-1, GLUE accuracy) versus the CrypTen++ baseline. If all tuned configurations stay within the stated degradation thresholds (0.5%/2%/5%) on the MPC runtime, the concern is resolved. If any exceed the threshold, the non-MPC search criterion is not predictive of MPC accuracy behavior, and the speedup claims must be re-scoped or the tuner must incorporate MPC-specific error modeling.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The central speedup claim ('without sacrificing accuracy') depends on the auto-tuner selecting approximations that respect the user's accuracy budget on the real MPC runtime. In Section 4.3.2 (Figure 8), candidates are evaluated by lowering to a non-MPC PyTorch GPU runtime, and the paper states this 'still captur[es] all the approximation-induced errors.' That statement is the load-bearing assumption: the MPC backend in Section 4.4.2 inserts operations the non-MPC runtime does not model, including probabilistic truncation underflow (Section 2.2.1), scaling-factor conversion errors (Sec-PubFloat Add/Mul), and truncation after every secret multiplication (Sec-Sec Mul). These errors are not constant across candidates: a lower-degree polynomial or fewer exponential iterations changes the distribution of intermediate values, which can change the magnitude and sign of fixed-point error, and can change which approximation is actually best. The paper provides no experiment comparing candidate rankings or final accuracy on the non-MPC search runtime versus the real MPC runtime (CrypTen++), and Section 6 reports no final task accuracy for the tuned configurations. The claim that CrypTorch-eco 'mostly maintains accuracy' is therefore not established by the reported evidence. This is an internal-correctness risk, not a disagreement with consensus: the paper's own design explicitly depends on the non-MPC evaluation being representative.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents CrypTorch, a multi-stage compiler for MPC-based ML built on PyTorch 2's compiler infrastructure. The authors first engineer CrypTen++, an optimized variant of CrypTen (14.4–96.2× kernel speedups), and use it to characterize MPC inference overheads, finding that operator approximations (Softmax, GELU, SiLU, etc.) dominate in Transformer and EfficientNet models (72.8–97%). CrypTorch separates operator approximation from the MPC runtime, exposes a tunable-pass programming interface, and auto-tunes per-operator approximation choices using a greedy/hill-climbing search that evaluates candidates on a non-MPC PyTorch GPU runtime. The paper claims 1.17–1.38× speedup without sacrificing accuracy and 1.22–1.8× speedup when some accuracy degradation is allowed, on top of CrypTen++; compared to CrypTen, it claims 3.22–8.6× end-to-end speedup. It also formalizes backend translation rules for scaling/truncation/encryption and demonstrates extensibility via a HummingBird auto-tuner pass.","tokens_in":33470,"tokens_out":4052,"duration_ms":43297,"significance":"If validated, CrypTorch would be a practically valuable contribution: it converts a manual, global, and often opaque approximation-selection process into an automatic per-operator compiler stage, and it ships a usable optimized baseline (CrypTen++) as well as a formal specification of MPC-specific lowering rules. The modular design on PyTorch 2's IR is sensible, and the characterization study is a useful update to older overhead analyses. However, the central accuracy-preservation claim currently rests on an unvalidated proxy: candidate approximations are ranked on a non-MPC GPU runtime, while the actual MPC backend introduces fixed-point truncation, scaling-conversion, and underflow errors that are not modeled during the search. No final task accuracy numbers are reported for any tuned configuration, so the 'without accuracy loss' claim is not established by the evidence in the paper.","major_comments":[{"comment":"The load-bearing assumption is stated in §4.3.2: testing on a non-MPC PyTorch GPU runtime 'still captur[es] all the approximation-induced errors.' This is not supported. The search graph is lowered before the MPC backend inserts MPC-specific operations: truncation after every secret multiplication (Sec-Sec Mul, §4.4.2), scaling-factor conversion errors (Sec-PubFloat Add/Mul, §4.4.2), and probabilistic underflow from local truncation (§2.2.1). These errors are not candidate-independent: changing t or the polynomial degree changes the distribution of intermediate values, which can change the sign and magnitude of fixed-point error, and hence which approximation is actually best on the MPC runtime. The paper provides no experiment comparing candidate rankings or final accuracy between the non-MPC search runtime and the real CrypTen++ runtime. Without such validation, the 'without accuracy l","section":"§4.3.2, Figure 8"},{"comment":"No final task accuracy numbers are reported for CrypTorch-eco, -moderate, or -aggressive. The text and figure only state user-supplied thresholds (<0.5%, <2%, <5%) and report speedups. The claim that CrypTorch-eco 'mostly maintains accuracy' therefore lacks direct evidence. The manuscript should report achieved accuracy (with variance or confidence intervals) for each model and task, for CrypTen++ and for each CrypTorch configuration, and clearly state how many runs were averaged.","section":"§6.2, Figure 14"},{"comment":"The output-quality metric used by the auto-tuner is not precisely defined. §4.3.2 says quality is compared with the 'maximally accurate approximation' against a user-given threshold, and §6.1 says both model accuracy and loss were explored with loss working better. The exact loss function, the search dataset size per model, whether the threshold is checked on a held-out split, and the rollback rule are not specified. This matters because the search result—and therefore the speedup numbers—depends on this metric. Please provide the concrete definition and the values used for each experiment.","section":"§4.3.2 / §6.1"},{"comment":"The speedup claims are reported differently in the abstract, introduction, and evaluation body. The abstract says auto-tuning alone gives 1.21–1.5× and 1.33–1.74×; the introduction says 1.20–1.7× and 1.31–1.8×; §6.2.1 reports LAN 1.20–1.38× / 1.21–1.55× / 1.31–1.7× and WAN 1.19–1.42× / 1.24–1.62× / 1.35–1.80×. The end-to-end CrypTen comparison also varies (abstract 3.74–8.32×, introduction and §6.2.2 3.22–8.6×). The central claim should be stated with one consistent set of numbers and clearly tied to the experimental section.","section":"§1 / §6.2.1"}],"minor_comments":[{"comment":"The HummingBird technique [78] is used both inside CrypTen++ as a static guess and as an additional auto-tuned pass in CrypTorch. The paper does isolate its incremental benefit (6–10%, Figure 17), which is good. Given that [78] is a co-authored work of one of the authors, please add an explicit disclosure in the final version.","section":"§3.1 / §4.5"},{"comment":"The axis labels in Figure 4 are difficult to read and appear garbled (e.g., the x-axis around '-520/-515/-510' and the labels '5 0 5'). Please redraw with clearer tick labels and larger fonts.","section":"§3.2.2, Figure 4"},{"comment":"Typo: 'addational speedup' should be 'additional speedup'.","section":"§4.5"},{"comment":"The usability comparison reports lines of code added (3 vs. 46), but no information is given about the complexity or maintainability of the pass interface beyond line counts. Please also provide the actual pass code for LayerNorm in an appendix or artifact.","section":"§6.5"},{"comment":"The security argument says MPC kernels are secure by themselves and 'their security does not degrade upon composition.' This is stated without reference to standard composition theorems or to the semi-honest threat model. A brief justification or citation would strengthen the claim.","section":"§5"}],"recommendation":"major_revision","confidential_remarks":"The central idea is promising and the engineering contribution (CrypTen++, modular compiler passes, formal backend rules) is real. My main concern is the unvalidated proxy in the auto-tuning loop: the paper's headline claim depends on non-MPC GPU rankings transferring to the MPC runtime, and no accuracy table is provided. This is fixable with additional experiments, but it is load-bearing. Also, the abstract/introduction/evaluation speedup numbers should be reconciled. The self-citation to [78] is disclosed in context and its isolated benefit is small, so I do not see an ethical problem, but a formal co-authorship disclosure would be appropriate."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Hi — short take on arXiv:2511.19711.\n\nThe paper is a solid systems contribution. What is actually new: it stops treating operator approximation in MPC-based ML as a fixed, global runtime decision and makes it a compiler stage with per-operator, auto-tuned choices on PyTorch 2's export IR. The characterization study on CrypTen++ is useful: after fixing kernel-level bottlenecks, approximation (ex, GELU, SiLU/Softmax internals) accounts for 72.8–97% of overhead, and different layers tolerate very different approximation levels. The backend translation rules (Section 4.4) are clearly specified and implement the right scaling/truncation bookkeeping. They also engineered CrypTen++ (14.4–96.2x kernel speedups) and promise to open-source it, which is a real gift to the community even independent of CrypTorch.\n\nThe soft spot is exactly where the reader and stress-test point. The auto-tuner ranks candidates on a non-MPC PyTorch GPU runtime (Section 4.3.2, Figure 8), and the paper claims that still captures all approximation-induced errors. That claim is doing heavy lifting. The MPC backend inserts truncation, scaling-factor conversion, and probabilistic underflow (Section 2.2.1) that the non-MPC runtime does not model, and these effects can change the relative ranking of candidates. If the ranking does not transfer, the chosen approximations can violate the user's accuracy budget on the actual MPC runtime — so the headline \"without sacrificing accuracy\" is not established by the reported evidence. This is not a manufactured concern; the paper's own design makes the non-MPC evaluation load-bearing.\n\nSmaller issues: no final task accuracy numbers are reported anywhere — only the user-set thresholds (0.5%, 2%, 5%), which makes \"mostly maintains accuracy\" unverifiable. The abstract and body speedup ranges differ (1.21–1.5x vs 1.20–1.7x for the no-loss case), which looks like inconsistent bookkeeping rather than cheating, but it should be reconciled. The CrypTen comparison is against a modified CrypTen with replaced approximations and no ViT — fair to state, but the 3.22–8.6x end-to-end numbers should be read as \"vs. a reasonable improved CrypTen,\" not the standard baseline. The HummingBird pass is co-authored with the paper's own, but its isolated benefit is measured at 6–10%, so no red flag there.\n\nBottom line: the core idea is new and the engineering is real. What the paper needs before the \"without accuracy loss\" claim can be accepted is (a) final accuracy and error bars on the real MPC runtime, (b) a check that candidate rankings from the non-MPC search match rankings on CrypTen++, and (c) code or at least a reproducible artifact. That is exactly the right scope for a serious referee, not a desk reject.\n\nI'd bring it to reading group and would likely cite it once the artifact is out.","headline":"Worth taking seriously: a genuinely useful compiler framework for MPC inference, with one load-bearing validation gap around the non-MPC auto-tuning runtime.","tokens_in":33896,"tokens_out":2168,"would_cite":true,"duration_ms":21004,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"CrypTorch compiles MPC-based ML into modular stages and auto-tunes per-layer operator approximations, claiming 1.17–1.38× speedup without accuracy loss over an optimized baseline.","keywords":["multi-party computation","MPC-based machine learning","operator approximation","auto-tuning compiler","private inference","fixed-point arithmetic","PyTorch export IR","accuracy-performance tradeoff"],"falsifier":"Run a model from the paper, such as BERT-SST2, under CrypTorch's chosen moderate configuration on a real two-party MPC setup and compare the resulting accuracy against the non-MPC estimate from the auto-tuner's search. If any operator's MPC-specific fixed-point error changes the final accuracy by more than the user's budget, or if two configurations ranked on GPU reverse their ranking on MPC, the 'without accuracy loss' claim is falsified.","tokens_in":32978,"feed_emoji":"🔐","tokens_out":4455,"duration_ms":45233,"temperature":0.7,"pith_summary":"The paper argues that in modern MPC-based machine learning, the dominant remaining bottleneck is no longer matrix multiplication or comparison kernels but the approximations used for operators MPC cannot run natively, such as Softmax, GELU, LayerNorm, and SiLU. Existing frameworks fix these approximations globally, and the paper shows they are often both too inaccurate—ruining output on some inputs—and unnecessarily slow. CrypTorch splits compilation into modular stages, exposes approximations as tunable compiler passes, and automatically chooses an approximation per operator under a user-supplied accuracy budget. On top of a heavily optimized baseline, the auto-tuner alone gives 1.17–1.38× speedup without accuracy loss and 1.22–1.8× when some degradation is allowed; the full framework is 3.22–8.6× faster than CrypTen. The broader point is that approximation selection should be a compiler optimization, not a manual runtime design decision.","feed_headline":"Auto-tuned approximations speed private ML up to 1.8×","feed_subtitle":"MPC frameworks waste time on overly accurate or inaccurate operator approximations; a compiler can pick per-layer winners.","key_machinery":"The load-bearing mechanism is the tunable approximation pass combined with per-operator search. CrypTorch represents approximations as compiler passes with explicit knobs, provides a programming interface so new approximations are added as short pass bodies, and uses a greedy or hill-climbing tuner that lowers candidate graphs to a non-MPC PyTorch GPU runtime, compares output quality against the most accurate baseline, and rolls back unacceptable changes. Because graphs at that point are MPC-agnostic export IR, search cost stays low. The backend's formal type and scale rules—secret versus public, integer ring size, scaling-factor propagation, truncation—then make the chosen approximations ex","core_discovery":"Operator approximation—not communication or MatMul—is the main performance and accuracy bottleneck in a well-optimized MPC-based ML framework, and it can be removed automatically. CrypTorch makes approximation a compiler stage: a frontend annotates tensor ownership on PyTorch export IR; an approximation stage rewrites unsupported operators into supported ones, each exposing tunable knobs (iteration count, clamping, polynomial degree); an auto-tuner searches these knobs per operator, tests candidates on a fast non-MPC GPU runtime, and rolls back changes that violate an accuracy threshold. A backend then lowers the chosen graph to MPC with formal encryption, scaling, truncation, and comparison","pith_inferences":["A natural extension is to treat the accuracy budget as one axis of a latency–accuracy Pareto search rather than a hard threshold, letting the tuner expose a frontier of configurations instead of a single point.","Because the tuner independently rediscovers known MPC-friendly design choices, such as ReLU-like Softmax and low-degree polynomial activations, it could serve as an automated oracle for architecture search: run the tuner on a candidate architecture to see which non-linearities are actually cheap.","The non-MPC search step is the main risk point: if fixed-point truncation, scaling-factor mismatch, or local-truncation underflow changes candidate rankings, the chosen configuration could violate a tight budget on the real MPC runtime. A cheap validation would be to run only the tuner's final configuration and its top alternates on real MPC during search.","The search currently uses loss on held-out data; using per-layer sensitivity metrics or calibrated uncertainty could reduce the hundreds of candidates tested and shorten the multi-hour search times reported."],"forward_implications":["If correct, the standard practice of hard-coding one approximation per operator globally in an MPC runtime can be replaced by automatic per-layer selection, removing a source of both wasted communication and accuracy failures.","Users can specify an accuracy budget (e.g., <0.5%, <2%, <5% degradation) and the tuner trades speed against that budget at operator granularity, including automatically discovering that some LayerNorm and Softmax instances tolerate very aggressive approximations.","New approximations can be added as short IR passes rather than by modifying runtime internals, lowering the barrier to adopting future advances in MPC kernels and protocols.","The speedup grows with longer BERT sequences and larger batch sizes because approximation tuning cuts communication bytes more than rounds; the benefit holds when models are encrypted, though slightly reduced.","Because the IR and backend formalism are separable from the specific MPC runtime, the same auto-tuning idea can be reapplied to other MPC backends once they are ported into the compiler."],"fun_headline_variants":["Auto-tuned approximations slash private ML latency","Private ML gets 1.7× faster by auto-tuning approximations","Faster private ML: auto-tune your operator approximations","Auto-tuning approximations boosts private ML speed by 1.7×","Why private AI is slow: approximation, not communication"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The tuner judges candidate approximations by running them on a non-MPC PyTorch GPU and assumes this reflects their relative accuracy on the real MPC integer-ring runtime, where fixed-point truncation, scaling-factor mismatches, and local-truncation underflow also inject errors.","fun_headline_variants_meta":{"raw":{"variants":["Auto-tuned approximations slash private ML latency","Private ML gets 1.7× faster by auto-tuning approximations","Faster private ML: auto-tune your operator approximations","Auto-tuning approximations boosts private ML speed by 1.7×","Why private AI is slow: approximation, not communication"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000494,"raw_usage":{"total_tokens":2293,"prompt_tokens":806,"completion_tokens":1487,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":550,"completion_tokens_details":{"reasoning_tokens":1406}},"tokens_in":550,"tokens_out":1487,"duration_ms":10848,"temperature":1.0,"reasoning_tokens":1406,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-03T20:25:23.721069+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a model from the paper, such as BERT-SST2, under CrypTorch's chosen moderate configuration on a real two-party MPC setup and compare the resulting accuracy against the non-MPC estimate from the auto-tuner's search. If any operator's MPC-specific fixed-point error changes the final accuracy by more than the user's budget, or if two configurations ranked on GPU reverse their ranking on MPC, the 'without accuracy loss' claim is falsified.","supporting_citations":[],"review_version":1}