vllm 和 ollama 仅LLM（大语言模型）, tritonserver 其他模型ollama 上手快，快速验证，性能太差vllm 高吞吐，一个对话机器人能每秒应对几百人的提问。gpu 利用率也 高于其他引擎。

规划好三套独立的资源域：采集层、消息层、存储层，建议分别用不同的 node pool 或 namespace 隔离，避免遥测系统自身抢占训练任务的资源。按热路径优先、冷路径其次的顺序上：先把"采集 → 网关 → Kafka → Prometheus/Loki/Tempo → Grafana"打通，能看实时监控和告警了，再补冷路径数据湖。这个是冷路径的底座，也是 Loki / Tempo 的后端，统

推理需要 2.5 GB，剩余 1.5 GB↓[CUDA 层] cudaMalloc 失败，返回 OOM 错误码↓[ONNX Runtime 层] 尝试 shrink arena，还是不够，抛异常↓[Triton backend 层] 这次推理标记失败；Triton 进程一般不崩↓[BLS 层] rec_pipeline 收到带 error 的 response↓[Ensemble 层] ocr_e

主打自研网卡+自研交换机+TiTa协议的软硬一体全栈自研，适合追求超高通信效率、超大规模（10万卡）的极致训练集群。技术最激进，抛弃了传统网络拓扑，利用信元交换（DDC）实现了完美的负载均衡和纳秒级故障切换，解决了大模型训练最怕的“尾部延迟”和“作业中断”问题。走的是“底座网络 + 顶层平台”的双轮驱动。底层用磐久无损网络提供算力，上层通过百炼平台把这些算力包装成大模型能力卖给企业客户。

带着“算力怎么塞进机柜（空间）”、“电怎么供得上（电力）”、“热怎么排得出去（散热）”、“挂了怎么远程修（运维）”这四个问题去看资料，你的进度会比盲目背参数快十倍。去看他们的高密度散热设计（特别是冷板式液冷）资料。“硅谷速度”，英伟达最新的通用基板（如 HGX H200/B200）他们总是最先推出整机。重点看他们针对大模型训练场景下的 PCIe 拓扑和智能运维管理软件（OM）资料。看厂商的 PDF

带着“算力怎么塞进机柜（空间）”、“电怎么供得上（电力）”、“热怎么排得出去（散热）”、“挂了怎么远程修（运维）”这四个问题去看资料，你的进度会比盲目背参数快十倍。去看他们的高密度散热设计（特别是冷板式液冷）资料。“硅谷速度”，英伟达最新的通用基板（如 HGX H200/B200）他们总是最先推出整机。重点看他们针对大模型训练场景下的 PCIe 拓扑和智能运维管理软件（OM）资料。看厂商的 PDF

机房里有 64 台 H100 服务器，每台 8 张 GPU、8 张 400G 网卡。网络架构是Spine-Leaf（不是传统的接入/汇聚/核心）采用：每台服务器的 GPU0 网卡都连到 Rail0 的 LeafUnderlay跑 eBGP，Overlay跑 VXLAN EVPN 给租户隔离Spine 到 Leaf 之间有 8 条等价路径，靠ECMP做负载均衡Spine 的 400G 口通过拆成 4

机房里有 64 台 H100 服务器，每台 8 张 GPU、8 张 400G 网卡。网络架构是Spine-Leaf（不是传统的接入/汇聚/核心）采用：每台服务器的 GPU0 网卡都连到 Rail0 的 LeafUnderlay跑 eBGP，Overlay跑 VXLAN EVPN 给租户隔离Spine 到 Leaf 之间有 8 条等价路径，靠ECMP做负载均衡Spine 的 400G 口通过拆成 4

三层防抖：Prometheus for 过滤瞬时抖动 → Alertmanager group_wait 聚合 → repeat_interval 防刷屏。如果上层应用同事反馈性能不达标【nccl-test】，或者loss有尖刺，监控偶尔发现xid 79掉卡问题【-r 3查】过了实时监控（防抖）和日常巡检这两关，只能说明表面上硬件没有问题。巡检只是那一瞬，深度是压测，时间长，能看出一段时间内有没有

排查问题也可以写成一个 automated script.