MoE 让 FFN 变稀疏、MoD 让整层 Transformer 直接跳过、KV 缓存量化压 attention 内存——这三条 LLM 推理的"省算力"路径，过去都是各自为战。arXiv:2607.06601 上 Balashov 与 Ponomarova 提出的 TriRoute，第一次把它们塞进同一个轻量控制器：每个 token 每经过一层，这个路由器要同时拍板三件事——skip / local / full 哪种 attention、走哪几个 FFN 专家、KV 缓存保留几位精度；null 专家的设计还能把 MoD 当作 MoE 的特例统一表达。训练端用 Gumbel-Softmax 加 straight-through 处理离散决策，配 load-balanced top-k 做专家路由，再加一个 Lagrangian 预算约束把"平均算力 / 内存"做成可调旋钮。 真正的难点在"联合训练"——论文把朴素方案碰到的 cross-axis routing-collapse 级联崩溃讲得很清楚：一条轴崩了会拖垮另外两条。作者用逐轴归一化 + 耦合感知均衡 loss 把这个坑解掉。160M 到 1.3B 的 decoder-only 模型在 compute-optimal token 量上，TriRoute 在相同 FLOPs 与内存下 Pareto 优于三种独立方案的拼装，且罕见实体、代码、算术上的尾部鲁棒性也更稳——这正是只看 perplexity 的优化容易丢掉的部分。事后分析还能读出路由器的"语义"：句首、罕见子词、命名实体一律吃 full attention + 高精度缓存，功能词被便宜打发。 剩下的问题很现实：这种联合路由的 GPU kernel 调度开销在小 batch 上能否摊薄？能否扩到 7B+ 的真实生产模型？和 vLLM、SGLang、TriRoute 这类专家调度框架的衔接也是开放题。如果答案是 yes，2026 下半年"小模型 + 智能路由"的玩法会比单纯堆参数更有戏。