精读笔记

Problem Setting

这篇论文实际解决的是“可用级别 differentiable MPC 的 GPU 化”，不是一个简化 LQR/iLQR benchmark 的加速问题。真正困难点在于 robotics MPC 的有用特性彼此冲突：隐式积分和控制率代价引入跨时间耦合，状态不等式和 slack 让 KKT 结构依赖 active set，可微分性又要求 backward pass 也能高效解线性系统。以前 CPU solver 如 acados 能处理较丰富问题，但难以嵌入大规模 batched learning；GPU solver 能并行，但常通过限制问题类来换速度。关键矛盾是：为了 GPU 并行性，solver 希望结构简单；为了真实机器人 MPC，问题结构必须足够复杂。

Motivation

已有路线不够的原因不是单纯“CPU 慢”或“GPU 快”，而是 solver abstraction 和 learning infrastructure 不匹配。学习系统需要 vmap/batch/gradient/rollout；传统 MPC solver 优化的是单个在线 solve 的低延迟；很多 GPU MPC 工作优化的是 forward pass 的某个窄类线性系统。作者的核心观察是 differentiable MPC 的 forward 和 backward 并不是同一个稀疏问题：forward ADMM primal update 可以 Schur-reduce 成 block-tridiagonal，backward active-set KKT 通常不能。因此关键缺口是一个同时服务 forward online control、batched learning 和 implicit differentiation 的 GPU-native solver design。

Core Idea

TurboMPC 的真正核心不是 SQP、ADMM、implicit differentiation 或 CUDA 中任何单个组件，而是把这些组件按 OCP 稀疏结构重新拼接：SQP 保留非线性和约束表达能力，ADMM splitting 把 QP 解法组织成 GPU 友好的 sparse primal solves + cheap projections，implicit differentiation 用 active-set KKT 避免 unrolling，cuDSS 则作为 forward/backward 都能接受的稀疏直接求解后端。

本质区别在于它没有为了 GPU 速度把 MPC 简化成 explicit dynamics + stage-separable cost + box control 的窄问题，而是承认真实 MPC 会破坏理想结构，然后选择一个更 general 但仍可利用时间稀疏性的线性代数原语。这引入的 inductive bias 是“保留 optimal-control 稀疏结构，同时把 batch/time/sparse factorization 映射到 GPU”，而不是把控制策略完全神经化或把规划替换成采样。

Method

1. SQP 外层解决非线性表达能力问题：每轮局部二次化 cost、线性化 dynamics/constraints，使隐式积分、NN cost、状态不等式都能进入同一 OCP 模板。它带来的变化是把复杂非线性问题转为一系列结构化 QP，而不是要求原问题属于 GPU solver 的窄类别。

2. ADMM 内层解决约束 QP 的 GPU 化问题：通过 OSQP-like splitting，把难点集中到 primal linear solve，把 inequalities 交给 projection。这样 forward pass 的核心变成重复求解具有时间稀疏结构的系统，适合 fused GPU loop。

3. Schur complement 是 forward scalability 的关键：ADMM KKT 中的 -rho^{-1}I 允许消去 multiplier，使 primal system 保持 block-tridiagonal。重要的是，隐式 dynamics 虽破坏 Riccati 所需的某些条件，但仍保留 C 的 block-bidiagonal 和 S 的 block-tridiagonal。

4. Slack projection 避免问题维度膨胀：ADMMSlack 风格的 smoothed projection 把 slack handling 移到 projection step，而不是扩展 primal linear system。它主要是 robustness/feasibility 工程，但对 batched RL/BO 很关键，因为 infeasible rollout 会直接破坏学习。

5. Active-set implicit differentiation 解决 backward memory 和速度问题：不 unroll SQP/ADMM，而是在收敛解处固定 active set，解 KKT sensitivity system。代价是梯度只在 active set 稳定且 forward 足够收敛时可靠。

6. JAX-CUDA co-design 解决系统瓶颈：JAX 提供 autodiff/batching API，CUDA fused loop 降低 kernel launch overhead，cuDSS 统一 forward/backward sparse solves。这里的贡献很大一部分是系统设计，而非新的优化理论。

Key Insight / Why It Works

最关键的 insight 是：GPU differentiable MPC 的瓶颈不是“有没有并行”，而是 forward/backward 两个线性系统的结构兼容性。很多 prior work 只优化 forward QP/OCP solve，因此可以依赖 PCG、parallel cyclic reduction 或 Riccati-like structure；但一旦要做 implicit differentiation，active-set KKT 的零块会让同样的 Schur reduction 不再成立。TurboMPC 的有效性来自从一开始就把 backward pass 纳入 solver primitive 选择。

最可能的核心贡献是 forward/backward co-design + fused CUDA implementation，而不是 SQP/ADMM/IFT 本身。SQP、OSQP-like ADMM、active-set sensitivity 都是已有思想；新意在于它们被组合成一个覆盖真实 MPC feature set 的 GPU-native primitive。这里的“新”更接近系统级 algorithm-engineering，而不是数学算法突破。

性能增益主要来自 scaling 和 memory/compute organization：batching 提高 GPU occupancy，fused ADMM 减少 kernel launch，cuDSS 复用 symbolic factorization，JAX frontend 降低学习管线接入成本。所谓 scalability 不是模型泛化意义上的 generalization，而是 computational scaling：更多 horizon、更大 batch、更高维系统时，GPU 稀疏线性代数开始摊薄 overhead。

松弛变量和 rescaling 更像必要的 robustness engineering，但不能低估其作用。没有 slack，batched RL/BO 中 infeasible states 会导致 solver failure；没有 scaling，车辆 OCP 这种量纲跨度大的问题会显著恶化收敛。它们不是论文最深的 insight，却是让系统在真实任务中不崩的关键。

需要警惕的是，实验中的速度优势并不全是算法复杂度优势。与 acados 的比较中，单实例 forward CPU solver 仍很强；TurboMPC 的优势在 batch、长 horizon、大问题和 backward 场景更明显。与 mpc.pytorch 的差距也部分来自后者问题类和实现年代差异。增益来源如果严格分解，算法、GPU backend、fused kernel、cuDSS、batch size 各占多少，文中未充分说明。

Relation To Prior Work

它最接近三条谱系的交叉：CPU 结构化 MPC/NLP solver，GPU MPC/QP solver，differentiable optimization layer。相对 acados/HPIPM/Riccati 系列，它牺牲部分单实例 CPU 极致低延迟，换取 GPU batch 和学习管线兼容性；相对 trajax/mpc.pytorch/DiffMPC，它支持更完整的 robotics MPC feature set；相对 MPCGPU/GATO/PCG 类 GPU solver，它不只服务 forward pass，而是把 backward KKT 也作为一等公民。

看似新的部分很多其实是已有思想重组：SQP 是标准路线，ADMM splitting 来自 OSQP，slack projection 来自 ADMMSlack，implicit differentiation 和 active-set VJP 也不是新理论。实质创新在于承认这些已有组件单独都不够，并围绕“forward/backward 稀疏结构不一致”做统一线性系统后端和 fused GPU 实现。

因此这篇论文更像 differentiable MPC infrastructure paper，而不是提出新控制算法。它推动的是 solver substrate：让约束 MPC 成为可 batch、可微、可部署的 GPU primitive。

Dataset / Evaluation

评估覆盖面相对扎实：有简化线性 RL scaling benchmark，有非线性 constrained tasks，有 humanoid IL，有 NN cost learning，也有真实 Lexus racing。真车部署是强证据，尤其因为 racing OCP 同时用到隐式 dynamics、控制率代价、slack、状态/控制约束，比较接近论文声称的 feature set。

不过 evaluation 对不同 claim 的支撑强度不同。对“GPU batching/scaling”支撑强；对“differentiable MPC 可用于学习”支撑中等，humanoid IL 和 point-mass NN cost 证明可行但规模和复杂度有限；对“泛化能力”支撑较弱，因为这不是一个学习泛化论文，更多是 solver 可用性展示。

BO tuning racing 参数的实验很有工程价值，但它验证的是 GPU-batched MPC rollout 让参数搜索更快，并不说明 differentiability 在 racing 中发挥了核心作用。真车速度提升也可能主要来自更好的 cost/parameter search，而不是 solver 本身带来更优控制结构。长 horizon 实验支持 solver scalability，但“8000+ nodes”在控制性能上的边际收益和实际必要性文中未充分说明。

Limitation

最根本的限制是它把一部分难度从算法结构转移到 sparse direct factorization 和数值工程上。cuDSS direct solve 提供 generality 和 robustness，但 factorization 的内存和常数开销会成为更大系统、更复杂 constraints、更高 active-set 密度下的上限。它不是免费扩展到任意 contact-rich whole-body MPC。

第二个限制是 backward pass 的 active-set implicit differentiation。它在固定 active set、forward 充分收敛、KKT 系统条件良好时成立；但机器人任务中 contact switches、constraint activation、slack transitions 很常见，梯度不连续会直接影响学习稳定性。论文承认这一点，但没有给出根本解决。

第三，当前 constraint class 仍主要是 pointwise slab inequalities。humanoid friction cone 被 box approximation 处理，这说明方法对真实 contact constraints 的支持仍有限。若引入 cone、complementarity、hybrid contact mode，当前结构可能需要重做。

第四，数值精度依赖 double precision，这与现代 GPU 的深度学习硬件趋势不完全匹配。若不能迁移到 mixed precision，吞吐上限会受限；若强行低精度，收敛和梯度精度会恶化。

第五，性能归因不完全清楚。fused CUDA、cuDSS、batch occupancy、JAX overhead removal、problem scaling、tolerance choice 都会影响速度。论文展示了很强系统结果，但如果要判断算法本身优于 PCG/Riccati/direct CPU solver，需要更细的 ablation。

Takeaway

• 1. Differentiable MPC 的关键不是把现有 MPC solver 加一个 backward，而是 forward/backward 从线性系统结构层面共同设计。
• 2. 对 robotics MPC，表达能力比追求某个窄结构的极致速度更重要；真正有用的 GPU solver 需要支持 implicit dynamics、constraints、slack 和 cross-time costs。
• 3. 这篇论文最值得迁移的 insight 是：选择线性代数 primitive 时不能只看 forward pass；如果下游要学习，backward KKT 的结构会反过来决定 forward solver 的设计。
• 4. 未来更有价值的方向不是再堆一个 GPU QP solver，而是 hybrid backend、mixed precision、contact/conic constraints、active-set-stable gradients，以及 solver 与 learning loop 的更细粒度 co-design。

一句话总结

TurboMPC 是一篇把约束 differentiable MPC 从“可演示的 GPU 加速算法”推进到“可用于 batched learning 和真实部署的 GPU-native solver infrastructure”的系统型工作，核心贡献在 forward/backward/implementation 的结构协同而非单点算法创新。