cuOPT vs CVXPY: a per-strategy bake-off for tax-aware portfolio optimization

Pick a tax-aware optimization workload — direct indexing on a US large-cap (500) universe, a 200/100 long/short book, a four-jurisdiction fleet rebalance — and ask the obvious operational question: how much wall-clock does the solver eat per account, per day? CVXPY with CLARABEL is the honest baseline; NVIDIA's cuOPT is the contender. We ran the same problems through both, with the same data and the same constraints, and watched what happened.

The headline finding: for the daily-cadence, account-scoped problem sizes that dominate the platform's compute budget, cuOPT is meaningfully faster — but the after-tax dollar that lands in the account is, within numerical noise, identical. That's the result you want from a solver swap. It also means the case for cuOPT here is operational, not financial.

Every account on the platform solves a constrained convex optimization once a trading day. For a sleeve tracking the US large-cap (100) universe with lot-level harvesting and a 5% tracking-error budget, the problem has on the order of 10² variables— one weight per name, plus auxiliary variables for the wash-sale lockout. Push to a US large-cap (500) universe and it's 10³. Open the long/short variants and the variable count roughly doubles because every long becomes a long-or-short cone. Add a per-name borrow rate and you've got a holding-cost matrix the solver folds in too.

At fleet scale the multiplier matters. Twenty accounts at one second of solve apiece is twenty seconds — fine. Twenty thousand accounts at one second apiece is five hours, and now your morning rebalance overlaps the open. The reason to care about solve-time isn't the math; it's how many seats the rebalancer can serve before the operating story falls apart.

The case for a faster solver isn't faster solves. It's a longer runway before the daily rebalance bumps into the open.

We took the production formulation of each catalog strategy, kept the constraint set identical, and translated the objective between the two solver front-ends:

The table below is the workhorse. Median solve-time over 252 daily rebalances, two solvers, the speed-up ratio, and the difference in after-tax terminal NAV against a $1M starting account. Negative speed-up means cuOPT was slower; we annotate why where it happens.

Three things stand out. First, the speed-up is monotone in problem size — the bigger the universe, the bigger the cuOPT margin. Second, the long/short strategies see less leverage from the GPU than the long-only ones because the conic structure CLARABEL handles natively isn't free for cuOPT either. Third, the after-tax difference is, across the board, indistinguishable from solver-tolerance noise.

The two strategies where cuOPT regressed — options overlay and VPF — share a property: the problem is small (~10 variables) and the constraints are mostly linear. The solver kernel is fast on either machine; the differentiator is host overhead. Each cuOPT invocation pays a fixed device-transfer cost in the low tens of milliseconds, which dominates kernel time when the kernel is already finishing in under 5 ms. CLARABEL, running on the same NUMA node as the calling Python process, just doesn't have that transfer.

The dev loop is the other place CVXPY wins. CVXPY's modelling layer is more permissive — log-det, geometric-mean, psd-square-root — and DCP errors are reported with line numbers and atom traces. cuOPT's QP/LP front-end is narrower; you express the problem in matrix form, and a malformed constraint manifests as an infeasibility return code rather than a stack trace. For prototyping a new strategy where the constraint shape isn't settled, CVXPY costs less developer time even when it costs more solver time.

At the per-account level a 14× speed-up is impressive but meaningless; the morning solve takes a quarter of a second either way. The number that matters is the fleet ceiling — how many accounts can a single rebalancer process between end-of-day and 6am Eastern. Under the synthetic benchmark, an US large-cap (500) tax-aware DI fleet sees:

The corresponding cost arithmetic, at AWS on-demand list prices as of May 2026: an m7i.4xlarge runs about $0.806/hour; a g6.2xlarge runs about $0.978/hour. The GPU instance is roughly 20% more expensive per wall-hour. Under the US large-cap (500) workload, that 20% premium delivers a 14.9× throughput multiplier — a per-solve cost ratio of about 12.5 to 1 in cuOPT's favour. Past a certain fleet size the question stops being "should we use cuOPT" and becomes "how many accounts is the GPU box still saturating."

The Δ after-tax NAV column in the per-strategy table is the load-bearing one for anyone evaluating a solver swap on investment-policy grounds: are we getting the same trades, the same harvests, the same realised P&L? Across 252 trading days and ten configurations, the maximum absolute difference in terminal NAV was 0.2 bp, and the median was zero. Trade-by-trade, the solvers agree on direction, magnitude, and lot identification on more than 99.7% of order tickets. The small set of disagreements is concentrated in days when two lots have nearly-identical cost basis and either choice is objective-optimal.

The conclusion isn't "cuOPT replaces CVXPY." It's that different solver back-ends fit different jobs, and the platform should be honest about routing each job to the back-end that fits it. The runtime now picks based on the request:

Both back-ends consume the same `OptimizeRequest`. The formulation lives in the strategy module and is solver-agnostic; the back-end picks up the resulting `Problem` shape and emits the same `OptimizeResponse`. Switching, in production, is a config flag.

Different solver back-ends fit different jobs. The platform's job is to route each job to the back-end that fits it — and to be boring about the routing.

Three things this benchmark deliberately leaves on the table, and which the production suite will pick up:

• Warm starts. Both solvers accept a warm-start primal/dual; we ran cold to measure the floor. Warm-started, CLARABEL gains roughly 2× on day-over-day rebalances; cuOPT gains less because PDHG has different convergence behaviour from a warm start. The comparison tightens but doesn't invert.
• Mixed-integer extensions.A few customizations (round-lot trading, tax-lot bucketing beyond HIFO) push the problem mixed-integer. CLARABEL doesn't handle MI; we'd switch to SCIP or HiGHS. cuOPT handles mixed-integer linear via its MIP solver — separate from the QP/LP path benchmarked here. We have a follow-up post planned for the MI numbers.
• Solver-failure handling.Both solvers return non-optimal status codes occasionally (numerical issues on poorly-scaled Σ, near-degenerate constraint sets). The router has identical fall-through logic for both — if a solve returns anything other than `OPTIMAL`, it falls through to a CLARABEL re-solve at tighter tolerance, and if that fails, the previous day's weights persist with an alert. Failure-rate parity matters as much as median speed.

Educational illustration · synthetic benchmark · numbers expected to refine when the production suite lands. Nothing here is investment, tax, or legal advice.