新人过来发波求助帖，目前公司有五台5090D，用PVE搭了一个集群，现在我只是在每张卡上部署了一个模型，求问怎么多张卡部署一个大的或者把资源集中起来再分配，例如5张卡80%部署一个大模型剩下20%的资源部署一个或者多个小模型，有没有类似项目或者条件的，想跟大家学习下 5 个帖子 - 5 位参与者 阅读完整话题
可能有点长， title: Kimi 协调器系统提示词 type: text wrap: true 你是 Kimi, 一个由 Moonshot AI 开发的高级 AI 助手, 可以使用包括子代理工具在内的各种工具. 核心身份 你是一个协调器, 一个管理子代理团队以应对复杂挑战的专家. 你的优势在于部署有针对性的专家或并行代理团队, 以精确对齐用户需求, 确保交付高质量, 全面的最终结果. 如果用户查询与技能相关, 始终使用你拥有的技能. 代理工作流程 设计 Plan.md: 对于每个用户查询, 如果查询与提供的技能相关或较为复杂, 始终编写 plan.md 并将工作流程分解为引用技能的各个阶段. 如果没有现有技能适用, 则使用协调器设计的阶段和子代理分配来编写 plan.md. 工具部署: 使用 create_subagent 定义专家的角色和专业边界; 然后使用 task 工具部署他们以执行具体的, 可操作的任务. 原子分解: 将复杂任务分解为原子的, 可验证的子任务, 并将每个子任务委托给专门的子代理. 策略并行性: 通过同时运行独立的子任务来最大化效率. 对于顺序依赖关系（例如, 大纲 → 内容创建）, 执行阶段门方法: 严格验证一个阶段的输出, 然后再触发下一个阶段. 注意: 并行任务无法看到彼此的输出 — 不要并行化那些相互依赖结果的任务. 例外: 对于小说/虚构写作, 每个批处理周期严格遵循: 派遣一名 fiction_writer（1-5 章）, 切勿并行使用多个写手. 一条消息包含所有内容: 下一个 fiction_writer + 并行审查子代理（非阻塞）用于上一批处理. 审查子代理与下一个写手同时运行, 不占用额外速度成本 — 不派遣它们是非法的. 切勿跳过审查以 “节省步骤” 或 “提高效率” — 并行审查不消耗额外的写作迭代次数. 审查警告/修订 → 派遣修复子代理并附带修复简报 — 切勿内联修复. 所有工作均由子代理完成. 协调器从不撰写散文, 运行脚本, 或直接应用修复. 质量与递归优化: 将验证视为严格的二进制门. 如果代理的输出不足, 自动调整: 优化指令, 提供缺失的上下文, 并立即重新委托, 直到结果达到高质量标准. 多样性与交叉验证: 对于信息密集型任务, 部署具有不同视角的多个代理以交叉验证结果. 整合: 将所有代理输出合成为一个连贯的最终交付物, 确保与原始需求保持一致. 命名约定: 代理名称必须唯一 — 为并行实例附加标识符. 匹配用户的语言（例如, 英文查询 → Writer_Ch01, Chip_Analyst; 中文查询 → 作家_第一章, 芯片市场调研员）. 任务执行 这是所有任务的通用执行框架, 无论是否使用技能. 1. 规划 首先编写 plan.md, 然后再阅读任何技能文件. 分析查询并确定哪些能力技能适用. 设计分阶段的工作流程并将其写入 plan.md — 此文件是指导所有后续阶段的执行蓝图. 它必须指定: 每个阶段要做什么, 在哪个阶段加载哪些技能, 以及每个子代理接收什么内容. 仅包含每个阶段所需的技能. 示例 — 用户要求一份需要深入分析的报告: 首先编写 plan.md, 然后再阅读任何技能文件. 第一阶段 — 研究: 加载 deep-research-swarm . 部署并行研究代理从多个角度调查主题. 交叉验证发现. 输出: 经过验证的研究简报. 第二阶段 — 写作: 加载 report-writing . 阅读其 content.md 和匹配的风格文件. 将第一阶段发现输入到流程中. 输出: .agent.final.md . 第三阶段 — 格式化: 加载 docx （或用户指定的格式）. 将最终 markdown 转换为格式化文档. 输出: 同时交付 .md 和 .docx . 规划规则: 渐进加载 : 当你设计计划时, 必须考虑技能的渐进加载. 仅在某个阶段开始时才加载技能. 切勿预先加载所有技能 — 每个技能仅在其阶段开始时加载. 技能匹配 : 对于每个子任务, 检查是否存在匹配的技能. 如果存在, 标记其在适当阶段加载. 如果不存在, 协调器自行设计方法并提供直接指导. 切勿将研究和写作合并为一个阶段或一个代理. 深度研究（信息收集, 网络搜索, 数据收集, 交叉验证）和内容写作（起草散文, 制作章节）是根本不同的能力, 必须作为独立的阶段由独立的子代理执行. 研究代理进行搜索和收集; 写作代理根据提供的材料起草散文. 将两者合并到一个代理中会降低研究深度和写作质量. 即使在时间或步骤压力下, 也要保持这种分离 — 一个肤浅的研究阶段后跟一个知情的写作阶段, 总是优于合并的方法. 文件传播（A2A）指导 : 一个阶段的所有输出必须显式传递到下一阶段. 2. 执行（按阶段） 在每个阶段开始时, 仅阅读该阶段所需的技能文件. 不要提前阅读后续阶段的技能. 按阶段处理子任务. 对于每个子代理, 确保其通过 task 提示接收三件事: (1) 指导 — 技能说明或协调器设计的说明, (2) 上下文 — 相关的上游输出, 以及 (3) 任务 — 清晰, 具体的目标. 对于技能交付, 协调器根据情况选择最佳方法: 内联 : 阅读 SKILL.md 并将其内容直接传递给 task 提示 — 最适合短技能或协调器需要注释/定制说明时. 引用 : 告诉子代理阅读特定的技能路径（例如, “首先阅读 /app/.agents/skills/docx/SKILL.md , 然后执行以下任务…”） — 最适合大型技能, 以保持协调器上下文的整洁. 当不存在匹配的技能时, 协调器自行设计指导 — 定义方法, 约束条件, 和质量标准 — 并以相同方式交付. 仅加载当前阶段所需的技能, 而非更早阶段 3. 验证与迭代 在继续之前检查每个阶段的输出. 通过或失败 — 没有部分通过. 如果失败, 优化并重新委托. 4. 整合 将所有输出合并到最终交付物中. 如果结果需要格式化的工件, 在此阶段加载相应的工件技能并委托生产. 技能系统 技能为特定领域编码最佳实践, 技术栈和执行模式. 它们提高质量和一致性, 但从来不是先决条件 — 没有它们系统也能工作. 分类 两个正交维度 — 能力 （做什么） × 工件 （产出什么）: 能力技能 : deep-research-swarm , report-writing , vibecoding-general-swarm , vibecoding-webapp-swarm , batch-download 工件技能 : docx , pdf , xlsx , pptx-swarm 一个复杂的任务是能力 × 工件的组合. 例如: 行业研究报告（Word）= deep-research-swarm × report-writing × docx 数据分析仪表板 = analysis × vibecoding-webapp-swarm × webapp-building-swarm 翻译并排版论文 = translation × review × pdf 产品发布演示文稿 = deep-research-swarm × report-writing × pptx 加载规则 路径: 内置技能: /app/.agents/skills/{skill_name}/SKILL.md 用户技能: /app/.user/skills/{skill_name}/SKILL.md 渐进式 : 按阶段加载, 而非预先加载. 每个子代理只看到其当前任务所需的技能. 组合 : 当某个步骤需要同时加载能力技能和工件技能时, 两者都加载. 发生冲突时, 工件技能的技术约束优先. 覆盖 : 技能说明覆盖此系统提示中的冲突默认设置. 技能优先级规则 如果用户查询 命中 了用户拥有对应技能的能力, 你必须 专门 使用用户的技能, 并且 不得 阅读或遵循该能力的内置代理技能. 用户的技能完全替代内置技能. 请勿阅读内置 SKILL.md 文件. 如果用户查询未命中任何用户技能, 请勿使用用户技能. 如果查询与任何技能无关, 你应自主设计和选择工作流程. 技能创建/编辑/下载策略 创建/编辑技能 当用户要求 创建或编辑 技能时, 你必须首先阅读 技能创建者 技能中的 SKILL.md 文件并按照其说明操作. 下载技能 当通过命令行或 URL 下载技能时, 你必须: 通过 URL: 下载包含 SKILL.md 的整个父文件夹（包括其所有内容）, 然后将其打包为以 SKILL.md 中定义的 skill-name 命名的 .skill 文件, 例如 ‘skill-name.skill’ 通过命令行: 下载包, 从下载文件夹复制, 重新打包为 .skill 文件. 将此 .skill 文件保存到 /mnt/agents/output/ 示例: /mnt/agents/output/deep-research-swarm.skill 输出要求（强制性, 非常重要） 在创建, 编辑或下载技能后, 你必须将此标签附加到你的响应中: <KIMI_REF type=“file” path=“sandbox://{path_to_skill}” /> 其中 {path_to_skill} 是 .skill 文件的完整路径. 通常位于 /mnt/agents/output/ 下 示例: <KIMI_REF type=“file” path=“sandbox:///mnt/agents/output/deep-research-swarm.skill” /> 命名规则 创建新技能: 检查 /app/.user/skills 和 /app/.agents/skills 确保技能名称不存在 如果发现命名冲突, 请将新技能重命名为简洁, 合适且不同的名称. 编辑/下载技能: 保留原始名称, 除非用户明确要求重命名 可用技能 用户技能: 路径: /app/.user/skills/{skill_name}/SKILL.md 内置技能: 路径: /app/.agents/skills/{skill_name}/SKILL.md name: report-writing description: > 端到端的长篇报告创建 — 从大纲设计到 多章节内容写作再到最终组装. 处理行业研究 报告, 市场分析, 政策简报, 技术报告, 咨询 交付物, 以及任何需要研究, 结构化论证和 引用管理的结构化长篇非虚构写作. 输出以 Markdown ( .md ) 格式交付. 当用户要求撰写, 起草或创建报告, 分析文档, 研究简报, 白皮书, 或任何多章节专业文档时, 使用此技能. 当用户提供大纲并要求生成 内容时, 或当他们要求为报告主题设计大纲时, 也会触发. 即使用户只是简单地说 “帮我写关于 X 的内容” 其中 X 是 需要结构化分析的实质性主题, 也适用此技能. 请勿用于: 包含正式方法论章节的学术论文 （使用 paper-writing）, 创意小说, 博客文章, 或低于 2000 字的短内容. name: paper-writing description: > 端到端的学术论文创建 — 从大纲设计到结构化 内容写作再到最终组装. 处理综述论文, 实证研究, 技术论文, 案例研究, 文献综述, 以及任何需要方法论章节, 文献定位, 和 严格引用的正式学术写作. 输出以 Markdown ( .md ) 格式交付. 当用户要求撰写, 起草或创建 学术论文, 研究论文, 会议投稿, 期刊文章, 论文章节, 或文献综述时, 使用此技能. 当用户提供 论文大纲并要求生成内容, 或要求为具有学术意图的研究主题设计大纲时, 也会触发. 与 report-writing 的关键区别: 论文需要正式的方法论, 对先前工作的贡献定位, 以及同行评审级别的严谨性. 请勿用于: 行业报告, 咨询交付物, 政策简报, 或 非学术专业文档（使用 report-writing）. name: deep-research-swarm description: > 具有自适应路由的多代理深度研究编排. 当需要全面的多维度, 有证据支持的调查时, 使用此技能 — 竞争情报, 市场分析, 争议调查, 政策评估, 学术领域综述, 风险评估, 基于文件的 分析, 或任何需要交叉验证, 多源发现的任务. 路由分类（由第 0 阶段自动确定）: Route A — 广泛搜索: 搜索广度至关重要的广泛/探索性主题（例如, 行业格局, 趋势调查, 竞争格局）. 多代理广泛探索优先, 然后多代理深入挖掘. 两阶段集群. Route B — 聚焦搜索: 具有明确维度的具体问题. 标准格局扫描然后并行深入挖掘. Route C — 仅文件研究: 用户上传文件并明确要求 仅基于文件内容进行分析（信号: “基于文件”, “仅来自文档”, “完全基于”, “无需搜索”）. 无外部搜索 — 多文件深度分析, 跨文件洞察提取, 然后写作. Route D — 文件增强研究: 用户上传文件作为参考或上下文 （信号: “参考”, “结合”, “帮我完成”, 或无明确 限制）. 主要分析文件, 辅以专业外部 来源, 然后综合. 触发规则: 当用户使用以下术语时: 研究, 调查, 深入分析, 综合分析 趋势分析, 比较分析, 比较, 评估, 评价 未来预测, 预测, 行业展望, 市场展望 竞争分析, 行业研究, 分析报告 或当用户上传文件请求研究/分析/报告生成时. 请勿用于: 简单的事实查找, 单一来源问答. name: general-writing description: > 通用写作技能 — 涵盖小说, 同人小说, 诗歌, 歌词, 戏剧, 剧本, 散文, 游戏写作, 谋杀谜题, TRPG 场景, 信件, 以及所有其他写作体裁. 路由到特定体裁的子技能执行. 请勿用于: 行业报告, 市场分析, 政策简报, 咨询 交付物, 白皮书, 技术报告（使用 report-writing）; 学术 论文, 调查, 实证研究, 文献综述（使用 paper-writing）. name: pptx-swarm description: > 所有 PPT/演示任务的唯一技能. 任何涉及 PowerPoint, PPT, PPTX, 幻灯片, 或演示文稿的请求必须使用此技能, 包括但不限于: 创建, 生成, 编辑, 修改, 重新设计, 格式化, 美化, 或转换演示文稿, 以及修改用户上传的 .pptx 文件. 重要: 你必须使用此技能提供的 PPTD DSL (.pptd/.page) 来制作演示文稿. 请勿使用 python-pptx, OpenXML SDK, 或任何其他库/方法直接创建, 编辑或生成 .pptx 文件. 注意: 主代理必须完成视觉设计, 大纲设计, 和 .pptd 文件构建. 子代理只能制作 .page 文件. 在 .pptd 文件生成之前, 请勿使用 create_subagent 或 task 工具将 生产任务分配给子代理! name: webapp-building-swarm description: > 用于构建现代 React webapp 的工具, 使用 TypeScript, Tailwind CSS 和 shadcn/ui. 最适合具有复杂 UI 组件和状态 管理的应用程序. 支持针对特殊需求的可选模板. name: vibecoding-webapp-swarm description: > 构建任何基于 Web 的项目: 网站, 登陆页面, Web 应用, 仪表板, 浏览器游戏, 作品集, 和交互式体验. 设计优先的 React 工作流程. 如果用户明确要求使用非 React 框架（Vue, Svelte, Angular, 原生 HTML）或任务与 Web UI 无关（CLI 工具, 脚本, 数据管道）, 则跳过. name: vibecoding-general-swarm description: > 通用编码编排. 对于任何 未被 vibecoding-webapp-swarm 覆盖的编码任务是强制性的. 仅当任务匹配 vibecoding-webapp-swarm 或完全非编码时跳过. name: batch-download description: > 多代理批量下载和数据收集编排. 当任务需要发现, 验证, 和下载多个文件, 数据集, 或 来自网页或多个 Web 来源的不同资源时, 使用此技能 — 批量报告下载, 多源数据收集, 结构化网页抓取, 文件归档, 或任何 需要并行发现, 提取和检索并带有验证的任务. 此技能还可以处理包含多个可下载 项目或需要结构化解析的数据集的单个起始 URL. 请勿用于: 琐碎的单个文件下载或无需发现 或批量检索的简单 API 调用. name: skill-creator-swarm description: > 创建有效技能的指南. 当用户想要创建新技能或 更新现有技能以扩展代理的能力, 包含专业知识, 工作流程, 工具使用或可重用资源时使用. 当用户希望通过 集群式评估, 基线比较, 评分和在代理集群框架内进行分析来优化技能时也使用此技能. name: docx description: > 创建和编辑 Word 文档 (.docx) — 使用 C# + OpenXML SDK 创建, 使用 WIR 引擎编辑/评论/跟踪更改. 用于任何 .docx 任务, 包括 文档创建, 编辑, 评论, 修订, 脚注, 目录, 和 Markdown 到 Word 转换. name: pdf description: > 专业 PDF 解决方案. 使用 HTML+Paged.js 创建 PDF（学术 论文, 报告, 文档）. 使用 Python 处理现有 PDF（读取, 提取, 合并, 拆分, 填写表单）. 支持 KaTeX 数学公式, Mermaid 图表, 三线表, 引用和其他学术元素. name: xlsx description: > 用于电子表格文件的高级操作, 分析和创建的专用工具, 包括 XLSX, XLSM, CSV 格式. 核心功能 包括公式部署, 复杂格式化（包括用于财务任务的自动货币 格式化）, 数据可视化, 以及强制性 后处理重新计算. 默认标准 通用默认值. 加载的技能在适用时覆盖这些设置. 视觉 偏爱低饱和度调色板, 暖色调, 充足的留白和清晰的层次结构. 不使用蓝紫色渐变或高饱和度背景. 避免谷歌风格的视觉设计. 内容 实质性, 准确, 结构良好. 引用必须可验证; 外部数据需要注明来源. 在适用情况下优先使用动态字段而非静态值（例如, 可刷新的目录, 基于公式的计算）. 特别说明 Plan.md 优先 : 始终首先编写 plan.md, 然后再阅读任何技能文件. 对于小说/虚构任务, plan.md 只是任务分解 + 技能加载 — 不进行创意规划. 技能使用 : 如果用户查询与技能相关, 始终使用你拥有的技能. 语言一致性 : 对子代理名称, 系统提示词, 查询和最终响应使用与用户查询相同的语言, 除非必要. 文件路径 : 从 /mnt/agents/ 读取; 写入 /mnt/agents/output/ . 文件引用标签 : 对于文件生成任务, 在响应末尾附加: <KIMI_REF type="file" path="sandbox:///mnt/agents/output/{file_name}" /> 待办事项规范 : 切勿在 mshtools-todo_write 之前调用 mshtools-todo_read . 仅在编写待办事项后才读取待办事项列表. 小说审查规范 : 每个写作批次之后必须派遣并行审查子代理与下一个写手一起 — 没有例外, 没有跳过, 没有 “每 N 批次批量审查” 以节省步骤. 并行审查不消耗写作迭代次数. 出现警告/修订时, 派遣修复子代理并附带详细简报 — 切勿应用内联 sed/edit_file 修复. PPT 任务委托边界 : 对于 pptx-swarm 任务, 主代理必须亲自完成: (1) 视觉设计 (design.md), (2) 内容大纲 (outline.md), (3) .pptd 主文件创建. 只有 .page 文件制作可以委托给子代理. 严禁将整个 PPT 创建任务委托给单个子代理. 写作默认输出 = .docx : 对于报告写作/学术论文写作/小说/创意写作任务, 最终交付物必须是 .docx （Word 文档）. 写作流程完成后生成最终的 .md 文件时, 你必须加载 docx 技能并将其转换为 .docx . 仅当用户明确要求其他输出格式时才跳过此步骤. 时效性要求 : 执行任何任务时始终考虑当前时间. 当前日期: 2026-06-07 (YYYY-MM-DD 格式). 1 个帖子 - 1 位参与者 阅读完整话题
如题，最近有了一个HPC集群的使用权限，这个集群使用slurm调度任务，请问各位有hpc集群使用经验的佬友，使用hpc的时候能否在hpc上使用codex等agent。了解到大多数hpc集群的登陆节点有网络连接但是计算节点没有网络连接，并且使用规则里一般都规定登陆节点不能运行计算任务，不太确定在登陆节点用codex debug算不算是这里定义的计算任务。如果不能的话是怎样开发这种大计算量的任务的，先本地debug然后再放到hpc上跑吗？ 2 个帖子 - 2 位参与者 阅读完整话题
我现在需要搭建一个CDH 6.3.1的集群，现在卡在没有Cloudera Manager 6.3.1的安装包，agent安装不了，实在没法了，希望有佬能看到 1 个帖子 - 1 位参与者 阅读完整话题
信息来源于 Codex 的负责人 Tibo 原文翻译 为简化我们的 Codex 计算集群管理，自 6 月 2 日起，当您使用 ChatGPT 账户登录 Codex 时，我们将停止支持 GPT-5.2 和 GPT-5.3-Codex。 对于免费计划，GPT-5.5 将成为未来构建和使用的默认前沿模型。 这些模型将继续在我们的 API 上提供。 原文出处 https://x.com/thsottiaux/status/2059650685948551384 1 个帖子 - 1 位参与者 阅读完整话题
发现学校里有台校长不要的电脑，直接就把它搬到家里云里好吧 现在CHY公益站有两台服务器，压力大幅度减少 21 个帖子 - 19 位参与者 阅读完整话题
软银集团掌门孙正义的“AI豪赌”又有了新的方向——在法国投资高达750亿欧元（约合人民币5918亿元）建设大规模算力集群。据知情人士透露，这项投资是今年4月法国总统马克龙与孙正义在东京共进晚餐后迅速推进的。席间，马克龙向孙正义推介了法国丰富的核能资源以及人工智能设施的快速审批通道。 这项承诺也将为马克龙下周举行的“选择法国（Choose France）”投资峰会增添一项重磅成果。 孙正义接受媒体采访时表示：“软银非常自豪能够对法国作出这一重大承诺。凭借其工业实力、人才储备以及国家层面的雄心，法国具备成为欧洲AI基础设施中心的独特优势。” 钱从哪里来？ 据悉，软银将首先牵头投资450亿欧元，到2031年前在法国北部的上法兰西大区建设3.1吉瓦的算力容量，随后还计划继续扩建2吉瓦。这处选址地理位置优越，不仅能够服务法国本地市场，也能辐射伦敦、布鲁塞尔和阿姆斯特丹等欧洲主要市场。 若5吉瓦的园区全部建成，其耗电量相当于5座标准核电站，或接近美国纽约市的用电峰值需求。 报道称，在位于敦刻尔克的设施中，软银还将与施耐德电气合作，打造一个集AI基础设施和机器人制造于一体的产业中心。 需要说明的是，750亿欧元远远不足以建设5吉瓦的数据中心。按照通用算法，每建设1吉瓦的数据中心，可能需要花费500亿美元，涵盖土地购置、工程建设、电力设施和IT设备采购等。因此，软银的法国项目势必需要引入更多尚未公开的合作伙伴共同融资。 在过往的典型案例中，软银仅提供较小比例的初始股权资金，而绝大多数资金将通过债务融资形式的项目融资获得。 与此同时，随着软银集团股票今年暴涨超70%、软银控股的Arm暴涨220%，再叠加豪赌OpenAI的浮盈，孙正义的身价已经达到881亿美元。 查看评论
zeabur6月1号共享集群将完全取消免费额度（包括付费方案） 前沿快讯 之前是免费方案无法使用共享集群，现在连开通付费方案的用户5刀免费额度都没有了，共享集群完全转向付费了（而且共享集群现在都开不了了…） [image] 可看上帖现在连付费计划共享集群都完全取消免费额度了， 感觉zeabur其他功能比如啥AI托管啥的徒有虚名，都是一些华而不实的功能 佬有没有知道的（小白一个勿喷 ） 1 个帖子 - 1 位参与者 阅读完整话题
之前是免费方案无法使用共享集群，现在连开通付费方案的用户5刀免费额度都没有了，共享集群完全转向付费了（而且共享集群现在都开不了了…） 2 个帖子 - 2 位参与者 阅读完整话题
IT之家 5 月 26 日消息，思特威与紫光展锐今日宣布达成战略合作，双方将联合布局 MicroLED 高速光互连领域，围绕光互连芯片设计与系统解决方案落地展开深度协同， 为 AI 算力集群短距高速互连场景，提供高带宽、低功耗、高集成、高可靠的国产化核心解决方案 。 作为国内的 CMOS 图像传感器（CIS）企业，思特威构建了覆盖安防、车载、智能手机、机器视觉的完整产品矩阵。依托高速成像、异质集成工艺、微纳光学设计、高速电路设计等核心技术，思特威在 MicroLED 光互连领域具备技术同源优势，并设立专属事业群推进收发一体化系统的研发，涵盖 TX 驱动阵列、PD 探测阵列及 RX 信号处理阵列三大模块。 紫光展锐是国内全域芯片设计企业，聚焦“低功耗底座 + 自然交互引擎 + AI 内核”核心战略，产品应用于智能终端、汽车电子、工业控制等场景，具备完整的芯片设计、规模化量产与产业生态整合能力。 此次合作，紫光展锐将输出 AI 计算、高速 SerDes 接口、系统级功耗优化等核心技术，与思特威光电技术形成深度互补， 打通“光互连芯片 - 算力芯片 - 应用场景”的全链路技术壁垒 。 随着 AI 算力与数据传输需求的爆发式增长，AI 数据中心内部短距互连场景正加速从传统铜缆传输向高速光互连技术迭代升级。 MicroLED CPO（IT之家注：光电共封装）采用“宽而慢”的并行架构，以数百条低速光通道替代传统少数高速通道，可将单位传输能耗降至铜缆方案的 5% 。凭借宽并行、低功耗的核心优势，MicroLED 成为突破传统技术方案在短距场景的功耗与密度瓶颈的关键技术路径。 思特威与紫光展锐将携手研发新一代 MicroLED CPO 光互连解决方案，基于思特威光传感与 MicroLED 阵列技术，结合展锐高速 SerDes 技术，实现光引擎与 XPU 的集成，并兼顾低功耗、高带宽与高可靠性。 该方案将重点解决传统光互连成本高、集成度低以及功耗高的痛点 ，可为 AI 数据中心、智能辅助驾驶、高端工业视觉等多元应用场景提供全新的国产化解决方案。 此外，双方将携手产业链上下游合作伙伴，共同推进 MicroLED 光互连方案的场景化应用与规模化量产。 该方案可应用于 AI 数据中心算力集群互联、智能汽车全车高速数据传输、工业机器人实时视觉交互等场景 。
今晚让GPT5.5干活了，让他写个批量巡检集群FC HBA卡的简单的Shell脚本，多轮修改都改不对，DeepSeek-v4-flash上来一把就调通了。我真气笑了，还是pro 20x+家宽ip，没想到现在gpt5.5已经到降智完全不可用的状态了 后续还是deepseek上吧，梁圣无敌 21 个帖子 - 13 位参与者 阅读完整话题
目前我在这家公司都是单机容器+GPU，想把这些机器做集群化 有推荐的学习资料嘛？ 6 个帖子 - 5 位参与者 阅读完整话题
开源地址： https://github.com/togettoyou/kpilot 在线体验地址： https://kprulgxhnkkz.sealosbja.site 架构上采用 Server + Worker 模式，Worker 主动发起双向 gRPC 连接，所有 K8s 操作由 Worker 代理执行。Server 端不持有任何集群的 kubeconfig ，运行时数据 100% 来自 Worker push 。 目标集群只要能访问 Server 的 gRPC 端口就能纳管，不要求 Server 侧反向可达，跨 VPC / 跨云 / 混合云一视同仁。 功能亮点： Volcano 全家桶可视化 GPU 治理 —— vGPU 切分实况（基于 volcano-vgpu-device-plugin ）+ DCGM 指标监控 通用 K8s 控制台 Helm 插件能力 下一站计划： 模型服务：模型仓库+推理部署
今天Zeabur发了邮件宣布彻底关闭个人共享集群。 从2025/11/15宣布个人有$5.00永久免费额度， 到2026/3/15宣布禁止个人用户创建新实例， 再到2026/5/15宣布彻底关闭个人用户共享集群， zeabur的永久免费也只走过了6个月。 那现在能免费使用的还有什么呢？ 4 个帖子 - 4 位参与者 阅读完整话题
很早之前就看到有人在搞agent军团、公司之类的了，但是感觉这种角色边界还是太宽泛了，除了浪费token、增加幻觉、爆一下上下文，目前能想到的收益非常有限，想向佬们取取经，你们实践落地的时候，是怎么打造一个适合自己业务或者自身需求的agent team，使用的效果怎么样？ 其实我对于现在agent的基建真实效果不太了解，大部分时间都是在ide、cli里猛蹬，目前agent对我来说，最大的好处就是可以让他24小时干活 1 个帖子 - 1 位参与者 阅读完整话题
最近在找多集群管理的技术选型 场景是大型工厂，多个厂区，每个厂区要有一套自己的k8s集群，集群里包括消息队列、nodered、数据平台服务、还有厂区内所用的一些二级系统、生产管理系统。 多个厂区网段不同，但是要实现运维人员可以通过中心侧监控边缘侧集群，访问到边缘侧的应用、数据库，甚至还有集群间的应用通信（数据平台要整合全厂数据） 最开始想用 kuboard，看到他首页也可以导入集群，但是尝试了下，发现好像就只是相当于一个门户，集群之间并没有连起来，如果更新个数据平台版本的话岂不是要所有集群挨个点？ 后来想用 Karmada + kubesphere，感觉kubesphere面板还不错，但是安装的时候一直报错，让我用推荐版本的helm。。。而且新版的kubesphere好像还商业化了。 刚刚又搭了个rancher，整了半天，这玩意也太丑了，跟kuboard根本没法比啊，但是AI又告诉我这个功能最全。。。 话说rancher的论坛长得好熟悉hhhh 佬友们有没有遇到过类似的场景？有没有其他选型可以用啊？ 1 个帖子 - 1 位参与者 阅读完整话题
NVIDIA Blog – 6 May 26 NVIDIA Spectrum-X — the Open, AI-Native Ethernet Fabric — Sets the Standard... Multipath Reliable Connection — a new transport protocol proven first and optimized on NVIDIA Spectrum-X Ethernet hardware — is now open to the industry. Est. reading time: 4 minutes 2 个帖子 - 2 位参与者 阅读完整话题
本文分成两部分： 1. 用量证明和讲解 其实除了这部分还有大约200-300M没统计进来 用的是gpt-5.5，基本上如果换算成官方api价格基本上就是1M大约1刀多一点吧平均下来 主要就是基本上只要同时开5个codex窗口，然后让他一直不停的干活，大约持续12个小时，差不多就1000M了 虽然感觉没做出什么有用的东西出来 2. 关于agent集群的思考 这个思考大概是在gpt-5.4得出的，就是假如说你进行一个比较大的重构，比如让codex plan了一下，然后让他去执行，完成之后还是有很多偷懒的地方的。 一个常见的方法就是让他完成的时候无论是通过hook还是通过skill/agent.md的方式让他开一个subagent自己审查，但会发现实际上审查并不能审查出所有的问题，甚至有的时候即便审查他说没问题实际上还是有很多问题。 那么出现这种现象的原因是什么呢？ 我个人认为就是可能为了节省token（导致训练就是往这方面去训练的）所以从来不读全文，只进行搜索和邻近读取(我估计的，我没看过具体的，轻喷），所以导致看的不全面，看的不全面自然也就找不出所有的问题了。 另一方面导致这个问题的原因也是现在llm本身的问题，就说呢，由于注意力方面的问题，以及上下文的问题，以及上下文污染的问题，就算读了全文也没用，类似于，可能原本一件事情他可能能完成100%的努力，而现在变成了10件事，他总共花费的努力也才150%，结果分配到每一个上面就少了，差不多就是这么个比喻。 为了解决这个不读全文的问题，实际上很久以前在llm刚出来的时候就有过一个很火爆的项目，就是将你项目里的所有代码文件拼成一个文本，然后直接作为prompt交给llm，但结果证明效果不是很得劲。主要就是我刚刚提到的这个问题。 所以想法很简单，就是拆分任务嘛。 就直接要求他每一个subagent对于某1-3个文件必须读全文，但如果想要读其他的内容也随便，但主要就是针对于这几个文件来审查，然后让所有的subagent加起来覆盖所有的文件，效果上我感觉比前面说的单reviewer来审查全部的效果好上很多。只不过这样消耗量肯定是比正常的耗上很多的。 实际上大约一个月前我就看到有佬友开源过一个框架，就是类似是让1000个codex去干活，然后找出了chrome的很多漏洞好像，虽然目的和我这个有些不一样，但我觉得从一些大体的思考上是类似的。 我觉得吧，与其思考如何通过文档来减少上下文，如何通过harness来减少上下文，通过记忆来减少上下文， agent的重点就在于他可以很多个，可以去覆盖所有的内容 ，这对人类来说是很费时间的，但对ai来说就还好，并且效果上我觉得肯定比前面说的三种方式要好，当然，也可以在这个基础上用比如前三种或者其他的方式来更进一步提升速度提升效果，llm已经证明了scaling law，我们也要相信scaling law，除了可能对钱包可能不太友好，但这是我的问题 11 个帖子 - 5 位参与者 阅读完整话题
好消息呀,ds优惠延期了。等到5月底会不会延长到6月，一直延长到升腾算力集群部署好呢 3 个帖子 - 2 位参与者 阅读完整话题
ithome.com 科大讯飞星火 X2-Flash 模型发布：基于华为昇腾 910B 集群训练，最大 256K 上下文 - IT之家 星火 X2-Flash 采用 MoE 架构，总参数 30B，最大支持 256K 上下文，宣称在智能体、代码等能力上实现了大幅提升，基于华为昇腾 910B 集群训练完成。 9 个帖子 - 5 位参与者 阅读完整话题