1. 百度百舸上 DeepSeek V3 的 AE 分离到底在解决什么如果你正在百度百舸Baidu AI Cloud 的容器/训练推理平台上部署 DeepSeek V3 系列模型并且用 SGLang 做推理引擎那你大概率会遇到一个绕不开的架构选择Attention 和 Expert 要不要拆开跑。这就是所谓的 AE 分离框架——把注意力计算Attention和专家网络MoE Expert放到不同的并行组、甚至不同的节点上去执行。DeepSeek V3 是典型的 MoE 架构总参数量很大但每个 token 实际激活的专家只是一小部分。传统做法是把整个模型按 TP张量并行切分后塞进一个实例问题是 Attention 部分和 Expert 部分的计算特征、显存占用、通信模式完全不同。Attention 对 KV Cache 敏感、随序列长度增长Expert 则对专家路由的负载均衡敏感。硬绑在一起就会出现一边算力打满、另一边在等通信的情况。AE 分离的核心思路就是让这两类计算各走各的并行策略Attention 侧用 TP 或 CP上下文并行来摊薄长序列的显存和计算压力Expert 侧用 EP专家并行把不同专家分散到不同卡上再配合 DP数据并行提升吞吐。百度百舸在万卡级生产环境里把这套东西做成了可配置的框架你通过 config.toml 和 settings.json 两个文件就能把分离策略声明出来SGLang 启动时读取并生效。这篇文章面向的是已经拿到百舸集群资源、准备跑 DeepSeek V3 推理的工程师。我会把从环境准备、配置文件骨架、启动命令到验证 AE 分离是否真正生效的完整链路走一遍重点放在可复制的配置和排障上。适合谁手上有百舸账号、熟悉 SGLang 基本启动流程、但还没把 AE 分离调通的同学。2. 前置准备TaoToken 与百舸环境的衔接在讲百舸的 AE 分离配置之前先说一个实际开发中经常被忽略的环节模型权重和推理服务的调用凭证管理。很多团队在百舸上跑推理是一套环境但本地做调试、对比不同模型输出、或者给上层应用发请求时又需要另一套 API 入口。这时候用 TaoToken 做统一的模型调用层会比较省事。TaoToken 是一个模型 API 聚合服务你可以把它理解成一个统一的入口把不同模型的调用收敛到一套 key 和一套接口格式上。它的官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 。注意 API 地址不带 UTM 参数直接写就行。为什么在百舸 AE 分离的场景里要提这个因为你在验证 AE 分离是否生效时往往需要对比「分离前」和「分离后」的输出一致性。如果本地没有一套稳定的调用入口你就得反复在百舸集群里起服务、发请求、看日志效率很低。用 TaoToken 的模型对话能力https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 可以快速拿到基线输出再和百舸上 SGLang 服务的结果做比对。如果你是要长期在百舸上跑编码类或 Agent 类任务建议直接看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 它针对代码生成和长上下文场景做了额度优化。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite API Keys 管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。控制台入口是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 。注意TaoToken 在这里的角色是「调用侧的统一入口」不是替代百舸的推理引擎。百舸负责跑模型TaoToken 负责让你方便地发请求和做对比验证。两者是配合关系。环境准备清单百舸集群至少 2 台 8 卡节点AE 分离建议 P 节点和 D 节点分开或者至少 Attention 组和 Expert 组用不同的卡SGLang 版本建议 0.4.x 以上AE 分离相关参数在较新版本才稳定模型权重DeepSeek V3 系列已上传到百舸的共享存储或对象存储Python 环境3.10sglang、torch、transformers 依赖装好网络节点间 RDMA 或高速内网AE 分离会引入跨节点通信3. 可复制配置config.toml 骨架与 settings.json 关键字段这一节是全文的核心。百度百舸的 AE 分离框架通过两个配置文件来声明并行策略和运行时参数。config.toml 负责集群级和并行组的定义settings.json 负责 SGLang 引擎侧的细粒度参数。先看 config.toml 的骨架。这个文件通常放在百舸任务的配置目录下启动脚本会读取它。# config.toml - 百度百舸 AE 分离框架配置骨架 [cluster] name deepseek-v3-ae nodes 4 gpus_per_node 8 network rdma [parallel] # Attention 侧并行策略 attention_tp 4 attention_cp 2 # Expert 侧并行策略 expert_ep 8 expert_dp 2 # 全局数据并行 global_dp 2 [ae_separation] enabled true # P 节点Prefill/Attention 为主和 D 节点Decode/Expert 为主的卡分配 prefill_nodes [node-0, node-1] decode_nodes [node-2, node-3] # Attention 和 Expert 的通信后端 comm_backend nccl # KV Cache 传输方式 kv_transfer active_passive [model] path /mnt/models/DeepSeek-V3 dtype bfloat16 max_seq_len 32768 [server] host 0.0.0.0 port 30000几个关键点解释一下。attention_tp4 表示 Attention 部分用 4 路张量并行attention_cp2 表示上下文并行度为 2这两个乘起来是 8正好覆盖一个节点的 8 张卡。expert_ep8 表示专家并行度 8expert_dp2 表示专家侧再叠一层数据并行。global_dp2 是整体数据并行副本数。ae_separation.enabledtrue 是总开关。prefill_nodes 和 decode_nodes 分别指定哪些节点承担 Prefill偏 Attention和 Decode偏 Expert角色。kv_transfer 用 active_passive 是百舸的双模式 KV Cache 传输机制主动和被动结合跨节点传 KV 时效率更高。再看 settings.json。这个文件是 SGLang 引擎启动时读取的字段更贴近运行时。{ model_path: /mnt/models/DeepSeek-V3, tokenizer_path: /mnt/models/DeepSeek-V3, tp_size: 4, ep_size: 8, dp_size: 2, cp_size: 2, enable_ae_separation: true, attention_backend: flashinfer, expert_backend: cutlass, kv_cache_dtype: auto, max_running_requests: 256, max_total_tokens: 65536, chunked_prefill_size: 8192, schedule_policy: lpm, schedule_conservativeness: 0.3, mem_fraction_static: 0.85, disable_radix_cache: false, enable_mtp: true, mtp_num_steps: 2, log_level: info }这里有几个字段直接决定 AE 分离能不能跑起来。enable_ae_separation 必须和 config.toml 里的开关一致。tp_size、ep_size、dp_size、cp_size 要和 config.toml 的 parallel 段对应上不一致会导致启动时报并行组初始化失败。enable_mtp 和 mtp_num_steps 是多步预测配合 AE 分离能进一步提升 Decode 吞吐建议开。mem_fraction_static 控制静态显存分配比例AE 分离后 Attention 和 Expert 的显存压力不同0.85 是个比较稳的起点显存紧可以降到 0.8。提示config.toml 和 settings.json 里的并行度参数必须交叉一致。我见过最常见的启动失败就是 tp_size 和 attention_tp 对不上报错信息是「parallel group size mismatch」排查时先看这两个文件。4. 启动与验证AE 分离是否真正生效配置写好后启动命令通过百舸的任务提交接口下发。假设你用 sglang 的 launch_server命令大致如下python -m sglang.launch_server \ --config /path/to/settings.json \ --ae-config /path/to/config.toml \ --host 0.0.0.0 \ --port 30000 \ --log-level info启动后不要急着发请求。先看日志里有没有 AE 分离的初始化信息。正常生效时日志里会出现类似这样的行[AE-SEP] Initializing AE separation framework... [AE-SEP] Attention group: tp4, cp2, nodesnode-0,node-1 [AE-SEP] Expert group: ep8, dp2, nodesnode-2,node-3 [AE-SEP] KV transfer backend: nccl, mode: active_passive [AE-SEP] AE separation enabled successfully.如果只看到「AE separation enabled」但没有后面的分组信息说明配置读到了但并行组没建起来大概率是节点分配或并行度不匹配。日志确认后发一个实际请求验证。用 curl 打一个 chat completionscurl -X POST http://localhost:30000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: DeepSeek-V3, messages: [{role: user, content: 用一句话解释 MoE 架构}], max_tokens: 64, temperature: 0 }请求返回正常只是第一步。要确认 AE 分离真正在干活需要看运行时的指标。SGLang 暴露了 metrics 端点默认在 /metrics。抓一下关键指标curl http://localhost:30000/metrics | grep -E ae_sep|attention|expert重点看这几个指标sglang:ae_sep_attention_forward_timeAttention 前向耗时sglang:ae_sep_expert_forward_timeExpert 前向耗时sglang:ae_sep_kv_transfer_bytesKV 跨节点传输量sglang:ae_sep_active_transfer_count和passive_transfer_count主动/被动传输次数如果 kv_transfer_bytes 一直是 0说明 KV Cache 没有跨节点流动AE 分离可能退化成了单节点内的伪分离。这时候要检查 prefill_nodes 和 decode_nodes 是不是真的分到了不同节点。另一个验证手段是对比吞吐。在相同并发下分别跑开启和关闭 AE 分离的配置看 tokens/s 的差异。长上下文场景32K 以上AE 分离的收益最明显短序列可能看不出差别甚至略慢因为多了跨节点通信开销。注意验证时用固定随机种子和 temperature0保证输出可复现。AE 分离不应该改变模型输出如果发现同一 prompt 在分离前后输出差异很大说明 KV Cache 传输或专家路由出了问题。5. 本篇常见错误排查AE 分离配置涉及的环节多出错的地方也比较集中。下面是我在实际部署中遇到过的几类典型问题。启动报「parallel group size mismatch」。这是最高频的错误。原因基本是 config.toml 和 settings.json 的并行度不一致。检查清单attention_tp × attention_cp 是否等于 Attention 组的卡数expert_ep × expert_dp 是否等于 Expert 组的卡数global_dp 是否和 dp_size 一致。三个都对齐后再启动。日志显示 AE 分离已启用但吞吐没变化。先看 metrics 里的 kv_transfer_bytes。如果是 0说明 KV 没跨节点传分离没实际发生。常见原因是 prefill_nodes 和 decode_nodes 配成了同一批节点或者节点名写错导致框架 fallback 到单组模式。另外检查 comm_backend 是不是 nccl用 gloo 在 GPU 间通信会非常慢。请求超时或 Decode 阶段卡住。AE 分离后 Decode 节点依赖 Prefill 节点传来的 KV Cache。如果 KV 传输的 active_passive 模式配置不当或者网络带宽不够Decode 会一直等。排查方向看 passive_transfer_count 是否远大于 active_transfer_count如果是说明被动传输占主导延迟会高。可以调整 kv_transfer 策略或者检查 RDMA 网络是否正常。显存 OOM。AE 分离后 Attention 和 Expert 各自占一部分显存如果 mem_fraction_static 设太高或者 max_total_tokens 太大容易 OOM。先把 mem_fraction_static 降到 0.8max_total_tokens 降到 32768 试。另外 chunked_prefill_size 设太大也会导致 Prefill 阶段显存峰值过高8192 是个比较安全的起点。MTP 开启后输出异常。enable_mtp 配合 AE 分离时多步预测的 draft 逻辑对 KV Cache 的依赖更强。如果发现输出重复或截断先把 mtp_num_steps 降到 1确认基础链路没问题再逐步加。SGLang 社区对 MTP 的适配在持续更新建议用较新版本。节点间通信报 NCCL 错误。AE 分离跨节点通信依赖 NCCL。检查各节点的 NCCL 版本是否一致RDMA 驱动是否装好防火墙是否放行了 NCCL 用的端口段。百舸环境一般有预置的网络配置如果自己改过安全组容易漏掉。6. 接入与调用把百舸的 AE 分离服务用起来百舸上的 SGLang 服务跑起来后上层应用怎么调如果你的应用是直接打百舸的内网地址那用 OpenAI 兼容的接口就行SGLang 默认暴露 /v1/chat/completions。但如果你的应用需要同时调多个模型或者本地开发环境访问不到百舸内网就需要一个统一的调用层。TaoToken 在这里的作用就是收敛调用入口。你可以在百舸服务前面挂一层转发或者直接用 TaoToken 的 API 做模型路由。API Keys 在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 管理接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。对于长期在百舸上跑编码任务或 Agent 的团队Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 的额度模型更适合高频调用。如果你只是想快速验证模型输出用模型对话页面https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 最省事。调用示例用 Python 的 openai 客户端指向 TaoTokenfrom openai import OpenAI client OpenAI( base_urlhttps://taotoken.net/api, api_keyyour-taotoken-key ) resp client.chat.completions.create( modelDeepSeek-V3, messages[{role: user, content: 解释一下 AE 分离框架}], max_tokens128 ) print(resp.choices[0].message.content)如果你在百舸上跑的是 Claude Code 类的编码 AgentTaoToken 也提供了对应的接入方式具体看文档里的 ClaudeCodeAnthropic 部分https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite 。最后说一个实际经验AE 分离的收益在长上下文和高并发下才明显短请求低并发时跨节点通信开销可能吃掉收益。所以验证时一定要用贴近真实业务的负载别只用单条短 prompt 测。另外 config.toml 里的节点分配不是越多越好Attention 组和 Expert 组的卡数比例要根据你的请求特征调Prefill 重的场景多给 Attention 组卡Decode 重的场景多给 Expert 组卡。这个比例需要压测几轮才能找到最优点。