博主经常到一个客户现场，发现客户是直连cn使用dws，每次一问lvs都是装了的，但是一问ip，所有人都不知道故没人用。如果安装部署的人还在就好，但博主遇到过到场发现安装部署的人已经辞职了，工号查出来是黑色的，这个时候就需要博主自己去找lvs的ip了。但这个其实很简单，这里做一个记录以root进行登陆，需要root的权限，不要切用户cat /etc/keepalived/keepalived.conf在文件靠近前面的位置virtual_ipaddress就是lvs的ip地址

本人深受低版本配置跨集群访问HDFS其害，低版本手动配置复杂，且出问题时候报错不明显（大部分统一为一个网络报错）但博主在一个的客户这边看到了高版本下的配置，可以直接在console界面一键配置（线下部署有，产品文档有写）。此处分享高版本HCS配置的方法（主要博主没有找到产品文档HCS配置的方法！）和博主遇到的错误。console界面-dws数据仓库-点开对应集群名-数据源-MRS数据源-创建MRS数据源此处会跳出一个相关信息填写创建MRS数据源连接可填写项填写说明备注数据源名称随便填可填dws_hdfs配置方式MRS用户和文件上传都可以（后面介绍MRS用户的配置方法）MRS用户需要提前在MRS创建好，选了文件上传需要在MRS管理界面创建好的用户的地方下载配置文件MRS数据源这里必须要填已经存在的同一个云平台的MRS集群名称同时这个集群得是你要访问的HDFS集群点击右边蓝色"查看MRS集群"可以查看已经存在的MRS集群MRS用户必须为在MRS创建的用户，可以点击？查看详细说明 用户密码上面MRS用户的密码 使用机机账号可选这里界面上有个介绍可以读一读数据库填DWS的数据库名称，填要写入或者要读取的DWS数据库 描述可选 填完点击确认，还会弹出一个是否修改安全组开通对应网络访问，点确认，耐心等待几分钟，当界面上变成绿色可用时，就可以直接写sql了。注意：该方法不需要配置路由，不需要开通任何网络侧。值得注意的是，这个同时会生成一个server在库里，名字与数据源名称为同一个。就是建好后可以从建立外表直接开始，以下是例子CREATE FOREIGN TABLE ft_region(    R_REGIONKEY INT4,    R_NAME TEXT,    R_COMMENT TEXT)SERVER    dws_hdfsOPTIONS(    FORMAT 'orc',    encoding 'utf8',    FOLDERNAME '/user/hive/warehouse/mppdb.db/region_orc11_64stripe/')DISTRIBUTE BY      roundrobin; select * from ft_region limit 1;博主配置过程中遇到一个报错，表现是配置不上，就是配完显示不可用，然而报错信息依旧没啥可用信息。然后博主改使用文件上传的方式配置了数据源（就是不选择mrs用户选择文件上传）就过了。拉研发一起定位了一下，定位为：DWS调用VPC接口返回安全组ID和VPCid不匹配。但vpc显示正常。研发没思路了，因为dws使用rms库时不喜欢删除各种曾经存在的数据，所以聪明的博主博主意识到了问题所在：本质上这个问题是rms库vpc对应了一条曾经存在或者有问题的安全组。拉上了vpc的人和dws研发继续查，确实是这个原因，博主所在局点确实曾经重新绑定过vpc。这里研发没料到这种情况，故如果其他局点存在dws使用的安全组更换过，且要用该方法访问HDFS，一定会出现这个问题。故只能等后续研发打补丁：安全组删除新增重新绑定算正常操作，mrs数据源应该增加或者删除这种情况下对安全组的判断规则这里只要把rms库的vpcid给修改为正确的就好select id,name,status,sgId from rds_instance where clusterId='集群ID';select id,fixIp,instanceId,portId,portType,sgId,subnetId from rds_port_relation where instanceId in (select id from rds_instance where  clusterId = '集群ID');这里解释一下为什么配置文件的方式可以用，这个原因是博主猜测，如有错误，恳请指正。可能是因为配置文件的方式写死了mrs所用vpc，故这里vpc找的是正确的vpc，就没有问题。

首先客户创建了表1,未插入数据，查询表1，该表存在。但查询pg_class表不存在，搜索为0条结果，以下三个语句是现场复现，这里是个非常简单的问题。你可以猜猜看为什么无数据。select * from pg_class c where c.relname='serviceAlarmEvent';select * from pl.serviceAlarmEvent;analyze pl.serviceAlarmEvent;原因非常简单，这里改查询语句为全小写就有结果了select * from pg_class c where c.relname='servicealarmevent';默认建表之后table以小写的形式存储，即大小写不敏感，大写的会转成小写，除非用双引号引起来·【建议】避免使用双引号括起来的字符串来定义数据库对象名称，DWS中使用双引号将数据库对象名称括起来时表示对大小写敏感。数据库对象名称大小写敏感会使定位问题难度增加。好简单的问题，但我不知道，故记录一下

DWS 线下8.2.1版本，开启系统表的vacuum以后为什么系统表的脏页还是一直在增加？怎么样让释放和占用的达到平衡？如果必须手动做vacuum full是否可以不停业务做？一直增加会有什么影响？

问题现象某局点出现集群降级且执行DDL必现阻塞，查看集群状态，发现6038和6040共2个备实例发生down。 问题排查步骤步骤1：查看DDL语句的pgxc_thread_wait_status等待视图，发现在等待异常备实例对应的主实例，怀疑备实例异常后，主从同步异常，导致DDL异常。 步骤2：在6037所在实例上执行gs_ctl query -D $datadir命令，发现信息不正常，然后查看从备实例的3020的pg_log日志，发现主从连接异常（理论上3020从备实例应该连接6037 44.36.9.37，但是日志中显示的连接是44.26.9.40，即是6038），导致DDL执行不下去。步骤3：查看主实例6037的pg_log日志，发现crc校验有异常，查看cma日志，发现共享内存申请失败。 解决方案6037主实例crc校准不通过的问题，可以停止通过停止实例后，mv或者rm清理对应从备6020实例的pg_xlog实例解决，清理完成后需重新拉起从备节点（若从备拉起异常，可删除从备数据目录里面的failover_xxx的文件）     2. data1和data8节点确认无硬件相关异常，可通过重启使集群恢复正常      

【问题现象】现象：用户执行授权语句时报错行大小超过8k语句: grant connect on database "XXX" to "XXX"报错内容: ERROR: dn_6201_6202: row is too big: size 8152, maximum size 8144'【问题原因】背景：OS一个页的大小为8k，DWS数据库存储行存表时，一个表文件中有若干个page，一个page中存若干个tuple，一个page大小为8k，对应OS的一个页原因：一个tuple的最大大小为 ”page大小减去page头大小“，即为报错内容中的8144【原因分析】1、报错中未明确说明是哪张表行大小超限，只能从产品逻辑去分析，语句是授权用户连接数据库，会更改pg_database系统表2、排查找到其中一条记录行大小接近8k：SELECT * FROM (SELECT oid, datname, pg_column_size(t.*) as row_size FROM pg_database t) t WHERE row_size > 2000 ORDER BY row_size DESC LIMIT 100;3、根据上面查出来的结果，看哪个字段过长。看到是datacl字段过长。找到问题所在，授权记录过多SELECT * FROM pg_database where datname = 'XXX'; SELECT pg_column_size(datacl) FROM pg_database WHERE datname = 'XXX';4、datacl是个数组字段，解析成每一行查看内容。找客户删除了其中几条无用授权进行临时规避，将新用户的授权加入SELECT datname, unnest(datacl) as acl_entry FROM pg_database WHERE datname = 'XXX';  4.1、客户找到几个不重要的客户，查这几个客户的权限情况用于解除授权：SELECT * FROM (SELECT datname, unnest(datacl)::text as acl_entry FROM pg_database WHERE datname = 'XXX') where acl_entry::text LIKE ANY (ARRAY['username1%', 'username2%', 'username3%']);【长期整改方案】1、同一类权限创建ROLE，授权给ROLE，用户继续ROLE权限。这样可大大减少datacl中的权限数量整改语句及测试用例如下：-- 创建测试数据库 CREATE DATABASE test_db; -- 创建角色（禁用密码，仅用于权限继承） CREATE ROLE app_connect_role PASSWORD DISABLE; -- 授予 CONNECT 权限 GRANT CONNECT ON DATABASE test_db TO app_connect_role; -- 创建测试用户 CREATE USER test_user1 WITH PASSWORD 'User1Pass123!'; CREATE USER test_user2 WITH PASSWORD 'User2Pass123!'; -- 用户继承角色权限 GRANT app_connect_role TO test_user1; GRANT app_connect_role TO test_user2; REVOKE CONNECT ON DATABASE test_db FROM test_user1; REVOKE CONNECT ON DATABASE test_db FROM test_user2; -- 检查数据库权限 select * from pg_database where datname='test_db'; -- 检查用户继承 SELECT r.rolname, ARRAY_AGG(m.rolname) as member_of FROM pg_roles r JOIN pg_auth_members am ON r.oid = am.member JOIN pg_roles m ON am.roleid = m.oid WHERE r.rolname LIKE 'test_user%' GROUP BY r.rolname; -- 连接数据库检查 gsql -d test_db -U test_user1 -W User1Pass123! -p 25308 -r2、可能有其它系统表也存在该问题，排查其它有权限字段的系统表：select relname,attname from pg_attribute a join pg_class c on c.oid=a.attrelid where attname like '%acl';3、排查所有有权限字段的系统表的行大小：SELECT * FROM (SELECT oid, datname, pg_column_size(t.*) as row_size FROM pg_database t) t WHERE row_size > 2000 ORDER BY row_size DESC LIMIT 100; SELECT * FROM (SELECT oid, nspname, pg_column_size(t.*) as row_size FROM pg_namespace t) t WHERE row_size > 2000 ORDER BY row_size DESC LIMIT 100; SELECT * FROM (SELECT oid, relname, pg_column_size(t.*) as row_size FROM pg_class t) t WHERE row_size > 2000 ORDER BY row_size DESC LIMIT 100; SELECT * FROM (SELECT attrelid, attname, pg_column_size(t.*) as row_size FROM pg_attribute t) t WHERE row_size > 2000 ORDER BY row_size DESC LIMIT 100; SELECT * FROM (SELECT oid, proname, pg_column_size(t.*) as row_size FROM pg_proc t) t WHERE row_size > 2000 ORDER BY row_size DESC LIMIT 100; SELECT * FROM (SELECT oid, lanname, pg_column_size(t.*) as row_size FROM pg_language t) t WHERE row_size > 2000 ORDER BY row_size DESC LIMIT 100; SELECT * FROM (SELECT oid, spcname, pg_column_size(t.*) as row_size FROM pg_tablespace t) t WHERE row_size > 2000 ORDER BY row_size DESC LIMIT 100; SELECT * FROM (SELECT oid, typname, pg_column_size(t.*) as row_size FROM pg_type t) t WHERE row_size > 2000 ORDER BY row_size DESC LIMIT 100; SELECT * FROM (SELECT oid, fdwname, pg_column_size(t.*) as row_size FROM pg_foreign_data_wrapper t) t WHERE row_size > 2000 ORDER BY row_size DESC LIMIT 100; SELECT * FROM (SELECT oid, srvname, pg_column_size(t.*) as row_size FROM pg_foreign_server t) t WHERE row_size > 2000 ORDER BY row_size DESC LIMIT 100; SELECT * FROM (SELECT tmplname, pg_column_size(t.*) as row_size FROM pg_pltemplate t) t WHERE row_size > 2000 ORDER BY row_size DESC LIMIT 100; SELECT * FROM (SELECT oid, defaclnamespace, pg_column_size(t.*) as row_size FROM pg_default_acl t) t WHERE row_size > 2000 ORDER BY row_size DESC LIMIT 100; SELECT * FROM (SELECT oid, group_name, pg_column_size(t.*) as row_size FROM pgxc_group t) t WHERE row_size > 2000 ORDER BY row_size DESC LIMIT 100; SELECT * FROM (SELECT oid, srcname, pg_column_size(t.*) as row_size FROM pg_extension_data_source t) t WHERE row_size > 2000 ORDER BY row_size DESC LIMIT 100; SELECT * FROM (SELECT oid, dirname, pg_column_size(t.*) as row_size FROM pg_directory t) t WHERE row_size > 2000 ORDER BY row_size DESC LIMIT 100; SELECT * FROM (SELECT oid, lomowner, pg_column_size(t.*) as row_size FROM pg_largeobject_metadata t) t WHERE row_size > 2000 ORDER BY row_size DESC LIMIT 100;

【问题现象】语句性能抖动，3s到10s【问题影响】影响客户查询业务【原因分析】1、语句性能波动，3s-10s，很容易复现（几分钟之内，多次跑语句）2、快慢计划是相同的，无跳变；慢计划慢在表扫描，Partitioned CStore Scan on dm_sv.dwd_sv_offline_sv_e2e_f3、无脏页，各DN CU数量相同，无倾斜4、慢的DN不固定，一个或多个。大部分DN也会在2s-6s之间波动5、查看autopolit监控，节点CPU、IO未到瓶颈（采样间隔为1分钟）6、深入分析计划，相同行的数据，CPU处理时长差异较大7、还是怀疑CPU有瓶颈，但监控采样频率为1分钟，语句的时长在3s到10s之前抖动，可能采样正好没采到；另外，用户所在资源池只在一半CPU，如果只是这个资源池的CPU高，也会存在监控发现不了CPU达到瓶颈在后台通过mpstat -P 10-36,62-88 1命令，只打印该资源池的CPU使用情况，每秒打一次，观察几分钟，发现偶尔会有CPU冲突情况8、公有云已有监控功能做不到CPU秒级的采样，通过xshell自带的日志功能采集CPU结果，通过claude AI工具写脚本解析mpstat命令的结果，根据时间线和CPU总使用率画出折线图如下：部署该监控后，与用户一起进行复现，多次语句慢的时间跟CPU冲高的时间完全对得上，确定是CPU冲高导致的性能抖动【措施和方案】通过以下命令，找出高CPU占用语句，用户侧整改select username,start_time,finish_time,duration,total_cpu_time,max_cpu_time,min_cpu_time,queryid,substr(query,1,100) from pgxc_wlm_session_info where start_time > '2026-03-25 08:30:00' order by total_cpu_time desc limit 1000;【排查方法】部署监控查看CPU使用情况

【问题现象】集群状态异常告警，cma日志显示gtm状态异常【问题影响】有告警，业务无报障【原因分析】1、查看主备gtm日志，有偶现几次gtm主备连接失败日志，连接超时导致(send timeout expired)。但前后无其它异常日志Could not connect to the GTM standby server with the connection info: localhost=192.168.123.240 localport=6001 host=192.168.86.153 port=6501 node_name=gtm_1001 remote_type=5 connect_timeout=30. errmsg: wait 192.168.86.153:6501:<NULL>s end timeout expired2、连接超时常见原因有业务过载导致的CPU、IO高、网络闪断等，往该方面排查：1）查看autopolit，该时间点集群负载无冲高；gtm主备节点，cpu、内存、磁盘、fd、网络各方面指标在对应时间无异常冲高2）查看sar日志，对应时间cpu、io负载均无冲高3）查看messages日志，报错时间无网络相关报错3、解析dbmonitor，全局等待事件中，有大量事务等待(Wait Status: acquire lock, WaitEvent: transactionid)，说明访问gtm频繁，但从上述第2点来看，业务负载并不高，只有gtm负载高4、从DN日志搜索gtm关键字，发现对应时间有连接gtm失败现象，进一步确定当时发生gtm连接过载情况WARNING:  Can not connect to all GTMs and then retry(1 times).5、综上来看，原因大概率在网络侧。结果历史案例，在message日志中检索tcp nf_conntrack相关日志，发现有nf table full现象。该现象发生于连接数过多时，后面的连接无法进入nf table，多次之后连接失败kernel: [137333.543118] nf_conntrack: nf_conntrack: table full, dropping packet【措施和方案】检查nf tcp timeout参数为120秒，修改为10s，修改后未再打印nf table full日志，问题解决sysctl -a | grep nf_conntrack_tcp_timeout_time_wait【排查方法】检索os的messages日志中是否有以下内容，有说明发生了连接过载，需要调整参数zgrep 'nf_conntrack: table full' /var/log/messages* | more

问题现象：DWS节点重启后，监控上报异常问题排查：排查上报日志，域名无法正常解析查看域名服务器配置信息有修改，ip在重启是配置错误原因：1.重启时，dhcp会从子网配置里面拿配置的DNS服务器地址，去刷新dns配置文件2.vpc子网配置dns服务器地址错误，导致os重启后dns地址配置同步错误，导致连接访问域名无法解析，指标无法上报解决方法：1.修改vpc子网对应的dns服务器为正确服务器地址2.再次重启服务器，让自动获取即可，如果暂时无法重启，则手动修改resolv.conf中配置信息

背景在centos7.2，RHEL7.2或Kylin-Server-20200711版本系统内核上遇到一个奇怪的问题，用户登入后创建的文件，在用户logout后会被自动删除。原因在RHEL7.2及之后，systemd-logind 服务引入了一个新特性——当一个user 完全退出os之后，remove掉所有的IPC objects。该特性由/etc/systemd/logind.conf参数文件中RemoveIPC选项来控制。详细请看man logind.conf(5)。当使用默认值（即 RemoveIPC=yes）的情况，当用户退出时，操作系统会remove掉该用户的shared memory segments and semaphores。影响范围在设置了RemoveIPC=yes 的RHEL7.2或Kylin-Server-20200711版本系统中会crash掉使用了Shared Memory Segment (SHM) or Semaphores (SEM)的应用程序目前遇到过的数据库应用在RHEL7.2上安装的Oracle Database应用程序异常crash在Kylin-Server-10-SP1-Release-Build04-20200711-x86_64部署的DM DSC应用也出现异常crash解决方案关闭RemoveIPC特性# 修改配置文件 sed -i 's/.*RemoveIPC.*/RemoveIPC=no/' /etc/systemd/logind.conf # 检查确认配置grep RemoveIPC /etc/systemd/logind.confRemoveIPC=no# 重启服务或重启操作系统systemctl daemon-reloadsystemctl restart systemd-logind.service# 结果验证确认loginctl show-session | grep RemoveIPCsystemctl show systemd-logind | grep RemoveIPC

在DWS的应用中，使用jdbc，利用其游标功能，分段获取数据，是常用的方法。在DWS后台，则会生成一个生成一个语句实际执行查询（后续简称主语句），后续多个语句fetch数据。如果把topsql全开，则会一大堆queryid不同，pid和query相同的语句。但当语句报错时，会出现如下报错，让人摸不着头脑，找不到原因。Failed to read response from connections while getting next data row from the combiner或者ERROR: dn_6049_6050: Failed to read response from Datanodes. Detail: 1049 Stream closed by remote 这是DWS内部报错，并非语句真正的报错。究其原因，则是主语句出现报错，但此刻主语句与客户端却没了直接联系，dn上主语句还在运行，但cn上主语句已经结束。此刻的报错则是后续的fetch语句，fetch语句想要从主语句获取数据，但是发现主语句已经报错退出了，所以可能报出连接错误的报错。想要找到真正的报错，需要追溯DWS日志，方法大概有两种。    一、通过主语句queryid追溯jdbc游标下发第一个语句就是主语句，找到其queryid，再通过queryid在dn上全量搜索，即可找到报错。如果topsql的设置能记录到该游标语句，则可先通过报错，找到报错语句，再通过报错语句的pid，找到主语句的queryid。select nodename, pid, queryid, username, start_time, finish_time, duration,status,abort_info,substr(query,1,100) from pgxc_wlm_session_info where start_time > '2025-08-18 00:00' and start_time < '2025-08-19 00:00' and query ilike '%xxxxx%' and status <> 'finished' order by start_time limit 100; select nodename, pid, queryid, username, start_time, finish_time, duration,status,abort_info,substr(query,1,100) from pgxc_wlm_session_info where start_time > '2025-08-18 00:00' and start_time < '2025-08-19 00:00' and query ilike '%xxxxx%' and pid = xxxx order by start_time limit 100;再通过queryid，在dn上全量搜索日志，即可找到对应的报错cm_ctl query -Cvi | grep 'Primary Normal' | awk '{print $3}' | uniq | xargs -I {} ssh {} "hostname && zgrep -i '223209657131345085' /DWS/manager/log/Ruby/pg_log/d*/postgresql-2025-08-19_*"如果topsql配置较低，没记录到游标语句，还可以在cn日志中碰碰运气，根据语句的不同，语句可能会触发DWS的日志打印。在cn日志中先找到报错语句，再往上搜索pid，可能能找到主语句的queryid，当然如果主语句没触发日志打印，也可能找不到。上述方法证据链比较完善，但有时候可能找不到主语句的queryid。    二、直接在dn日志中搜索报错语句直接在dn日志中全量搜索报错sql，再根据报错时间进行比对，时间和sql都对得上，那大概率就是要找的原始报错。cm_ctl query -Cvi | grep 'Primary Normal' | awk '{print $3}' | uniq | xargs -I {} ssh {} "hostname && zgrep -i 'xxx sql特征 xxx' /DWS/manager/log/Ruby/pg_log/d*/postgresql-2025-08-19_*"上述方法简单粗暴有效，但是证据链没那么完善。

春节将至，大家有哪些新年愿望

数据并行cid:link_0模型并行cid:link_1内存优化cid:link_2重计算cid:link_3优化器并行cid:link_4半自动并行cid:link_5自动并行cid:link_6混合并行cid:link_7持续学习的目标与特性cid:link_8混合专家模型cid:link_9Transformercid:link_10GlaMcid:link_11PanGu-Sigmacid:link_12Expert balancingcid:link_13分布式通信问题https://bbs.huaweicloud.com/forum/thread-0212720516321110833-1-1.html

分布式通信问题是分布式计算（含分布式深度学习、大数据处理）中最核心的瓶颈之一，指多计算节点（CPU、GPU、服务器集群）协同工作时，数据传输、信息同步过程中出现的延迟、拥堵、不一致等各类问题。其直接影响分布式系统的算力利用率、任务执行效率与稳定性，尤其在超大模型训练、海量数据并行处理场景中，通信效率往往决定了整个系统的最终性能。分布式通信问题的产生，根源在于节点间的物理隔离与资源差异。分布式系统中，各计算节点独立存储数据、执行任务，核心依赖通信链路传递中间结果、同步参数与指令，而通信链路的带宽有限、节点算力不均、数据量庞大等因素，都会引发各类通信问题，且节点数量越多、任务越复杂，通信问题的影响越显著，成为制约系统性能提升的关键。分布式通信的核心问题主要体现在三个方面。一是通信延迟，指数据从一个节点传输到另一个节点的时间损耗，包括链路传输延迟、节点处理延迟等，延迟过高会导致节点间协同脱节，尤其在模型并行、优化器并行中，参数同步延迟会大幅降低训练效率。二是通信带宽瓶颈，当传输数据量（如模型梯度、中间特征图）超过链路带宽上限时，会出现数据拥堵，导致任务卡顿甚至中断。三是通信一致性问题，多节点同步数据时，可能因网络波动、节点故障等，出现数据传输丢失、错乱，导致各节点数据不一致，影响计算结果的准确性。此外，不同并行策略（如数据并行、混合并行）的通信需求不同，也会衍生出针对性的通信问题，如MoE模型中专家间的路由通信开销过大。为缓解分布式通信问题，行业已形成多种优化方案，如采用高效通信协议、优化数据传输粒度、引入通信压缩技术、设计合理的并行通信策略等。这些方案通过减少通信数据量、提升通信效率、保障数据一致性，最大限度降低通信瓶颈的影响。随着分布式系统向大规模、高性能方向发展，分布式通信问题的优化的将持续推进，成为分布式计算技术迭代的核心方向之一。

Expert Balancing（专家平衡）是混合专家（MoE）架构的关键优化技术，核心是通过合理的路由调控与策略设计，使MoE模型中的所有专家网络被均匀激活、负载均衡，避免部分专家过载、部分专家闲置的现象，从而保障模型性能、提升计算效率，是稀疏大模型（如GLaM、PanGu-Sigma）稳定训练与高效推理的核心支撑。专家不平衡是MoE模型的固有痛点，其根源在于门控网络的自主路由特性。门控网络会根据输入数据特征，选择最适配的少数专家处理任务，若缺乏引导，会逐渐偏向激活部分“擅长”常见数据的专家，导致这些专家负载过重，而小众领域的专家因长期闲置无法得到有效训练，梯度趋近于零，最终使模型退化为少数专家的密集型模型，浪费稀疏架构的算力优势，甚至引发路由崩溃。Expert Balancing的核心目标是实现“专家负载均等化”，兼顾模型性能与计算效率，目前主要有两类主流实现方法。一类是基于辅助损失的方法，通过在模型训练中加入额外的平衡损失（如专家权重变异系数的平方），引导门控网络调整路由策略，平衡各专家的激活频率与权重总和，缓解不平衡问题，但可能引入与主任务冲突的梯度，影响模型性能。另一类是无辅助损失的方法，无需修改损失函数，通过优化路由机制实现平衡，例如添加偏置向量调整路由分数排序，或采用基于二进制整数规划的算法，动态调整专家分配顺序，可在训练初期就实现良好的平衡效果，且不影响主任务性能，还能节省训练时间。此外，在模型量化等场景中，还可通过专家平衡采样构建均衡校准集，确保所有专家得到充分校准。Expert Balancing的价值在千亿级以上稀疏大模型中尤为突出，是GLaM、PanGu-Sigma等模型实现高效训练与推理的关键。它不仅避免了算力浪费，还能提升模型的泛化能力，让小众领域的专家充分发挥作用，同时降低通信开销与硬件压力。随着稀疏模型的普及，Expert Balancing正不断优化，朝着更高效、更适配复杂场景的方向发展，成为MoE架构不可或缺的核心优化技术。