不卷算力，卷效率｜HAMi Meetup 上海站回顾：从异构算力管理到 AI 生产实践
大模型进入生产，企业真正面对的已经不只是"有没有 GPU"，而是如何把分散、异构、稀缺的算力，转化为可调度、可隔离、可观测、可持续交付的基础设施。
远程 GPU、分布式推理、国产 GPU 适配、Kubernetes 异构算力底座与智算平台工程，正在从一个个局部技术问题，汇成同一道产业命题：算力效率如何真正落实到生产侧？
9 月 6 日，由密瓜智能（Dynamia）与 HAMi 社区联合主办、上海五角场创新创业学院协办的"不卷算力，卷效率｜HAMi Meetup 上海站 · Incubating 特别活动"圆满落幕。这是双方联合发起的第四场 Meetup，也是 HAMi 进入 CNCF Incubating 后的首场线下技术分享活动。
一场开场演讲、五场主题分享和一场社区圆桌，从开源框架、GPU 厂商、终端用户、云厂商与社区治理等不同视角，集中讨论了 AI Infra 从"资源可用"走向"生产可用"必须跨越的关键问题。
CNCF 开场：HAMi 迈入 Incubating
2026 年 7 月，HAMi 正式晋级 CNCF Incubating。截至 9 月，今年全球仅有 6 个项目进入这一阶段。Incubating 意味着项目已在真实采用、技术成熟度与社区治理等方面通过 CNCF 的系统评估，也标志着 HAMi 迈入更成熟的社区发展阶段。
在这一重要节点上，CNCF 中国区总监、Linux 基金会亚太区副总裁 Keith Chan 再次为 HAMi Meetup 带来 Opening Speech。从多次参与 HAMi 社区活动，到在项目晋级后的首场线下活动中开场，Keith 的持续参与，也体现了 CNCF 对 HAMi 发展及其云原生 AI 基础设施方向的关注与支持。
开场演讲中，Keith 以《CNCF × PyTorch：构筑面向产业落地的云原生 AI 研发基座》为题，从企业 AI 落地普遍面临的成本失控、效率瓶颈与规模受限三大挑战出发，梳理了 PyTorch 模型与运行时、CNCF 编排服务及资源管理组件共同支撑 AI 从研发、训练到部署的分层架构。
在这套架构中，HAMi 承担异构 AI 算力虚拟化与资源管理能力，为 GPU、NPU 等加速器的共享、隔离和智能调度提供支撑，也为随后关于 GPU 资源调度、推理效率和产业实践的讨论建立了更完整的行业背景。
01｜从本地 GPU 到远程算力池
主题演讲环节中，密瓜智能联合创始人兼 CTO、HAMi 作者及 Maintainer 李孟轩，以《从本地设备到远程算力池：远程 GPU 方案与 HAMi 2.10 新能力》为题，介绍了 HAMi 最新的技术演进。
当 GPU 分散在不同节点、机房或集群中，传统"设备必须与任务共处一地"的使用方式会限制资源调度范围。远程 GPU 的核心价值，是把设备从本地节点的物理边界中进一步释放出来，使算力能够以资源池的方式被访问和调度。
围绕生产环境中的异构资源治理，HAMi v2.10 还带来了多项能力更新：KAI Scheduler 适配、vNPU 切分与监控升级、mutex 调度策略及策略组合、更灵活的动态 MIG，以及 HAMi-DRA 在设备分配、资源复用与 Ascend 支持等方向的推进。
分享同时强调了一个容易被忽略的问题：**算力效率并不止于"分配成功"。**平台还需要知道每张卡被哪些任务占用、分配了多少算力和显存，以及应用实际使用了多少资源。只有调度、分配和真实使用情况能够被统一观测，GPU 才真正成为可治理的生产资源。
02｜分布式推理走向控制平面
红帽大中华区 CTO 张家驹带来了《llm-d：打造跨负载、跨模态、跨硬件、跨平台的分布式推理平面》。
随着模型规模、请求类型和硬件环境不断复杂化，单一推理引擎很难独立解决生产环境中的全部问题。llm-d 将重点放在推理控制平面：通过智能路由、KV Cache 管理、Prefill/Decode 分离、流量控制、自动扩缩容与批处理等能力，让不同推理端点能够围绕实时负载和服务目标协同工作。
从 v0.8 的演进方向看，llm-d 进一步明确了自身定位：不做推理引擎的分叉，而是围绕路由、端点选择、缓存管理和弹性能力构建独立控制层；同时通过 EndpointDiscovery 等机制，将调度能力延伸至 Kubernetes 之外的 Slurm、裸金属和强化学习训练场景。
这意味着，面向多租户、Agentic AI、多模态与大规模批处理负载，推理平台的关键能力正在从"把模型跑起来"，转向如何在复杂流量下持续守住延迟、吞吐与服务稳定性。
03｜国产 GPU 推理：以 SLO 验收
天数智芯 Infra 研发总监叶成林围绕《天数智芯 GPU 上的高性能推理部署实践》，分享了国产 GPU 进入主流推理生态后的完整工程路径。
在上层，OpenAI API、vLLM 与 Hugging Face 等兼容接口帮助团队降低迁移成本；在底层，IxFormer、IXInfer、ixDNN、ixBLAS、IXCCL 与 IXLink 等自研软件栈负责兑现算子、运行时和多卡通信性能。GPUClusterPolicy、Device Plugin、DRA、拓扑调度与 HAMi 小模型 GPU 共享，则共同进入统一的资源控制面。
分享中有一个判断尤其值得关注：**设备完成分配并不等于服务已经就绪，首个满足 SLO 的 Token 才算真正完成交付。**从设备分配、GPU 与 NIC 拓扑绑定，到权重加载、预热、路由租约和 First Token，每一步都需要进入可观测、可验收的链路。
对于 Prefill/Decode 分离，判断标准同样不是"架构上能否拆分"，而是 Prefill 计算节省和 Decode 排队收益，能否覆盖 KV 搬运、额外路由、远端排队与故障恢复成本。TTFT、TPOT、Scale-to-First-Token、KV Transfer 和有效 Token，才是评估集群性能的最终口径。
04｜Volcano + HAMi-core：调度与隔离
科大讯飞资深架构师、Volcano 与 HAMi 社区成员董江，分享了《基于 Volcano + HAMi-core 打造 K8s 异构 AI 加速算力底座》的实践。
在大规模训练与推理集群中，资源碎片、作业类型多样、分布式训练、历史任务迁移、多租户配额与复杂工作流往往同时出现。单独解决某一个调度问题，很难形成稳定的 AI 算力底座。
这套实践以 Volcano 统一承载多引擎编排、队列管理、DAG 工作流、Gang 调度、装箱调度、真实负载感知与资源公平性，再通过 HAMi-core 提供 GPU 显存与算力隔离、细粒度切分及多架构兼容能力。
其中，装箱调度让资源利用率提升 40%。更重要的是，它揭示了生产环境中的一组双重目标：既要减少资源碎片、提高共享效率，也要控制任务异常、显存不足和共享 GPU 故障传播带来的稳定性风险。调度负责把资源放到合适的位置，隔离负责让共享之后的业务仍然可靠。
05｜让 GPU 成为开箱即用的开发环境
UCloud 高级研发工程师彭鹏在《智算平台的工程挑战与实践》中，将讨论从资源管理进一步推进到环境交付。
对于内部算法团队、自建推理集群和拥有自有 GPU 的企业客户，共同需求不是再看到一组硬件清单，而是把已经拥有的 GPU 转化为可管理、可交付、可直接使用的算力服务。底层越异构，开发者越期待简单，复杂度必须在平台内部被消化。
围绕一次开发环境交付，分享拆解了五个连续的工程断点：资源如何统一表达、多集群如何接入、开发工具如何灵活装配、镜像如何快速就绪，以及 GPU 如何高效使用。对应的实践包括 Instance Spec 资源抽象、轻量多集群接入、运行时工具注入、镜像按需加载与场景化 GPU 隔离。
在 GPU 隔离方案上，不同部署形态需要不同路径：私有化智算平台可采用 HAMi vGPU 提升共享效率；公有云 C 端场景需要内核级 vGPU 补齐隔离边界；公有云 B 端则要在 QEMU 透传、共享 NVSwitch Fabric 与 PCIe-only 之间作出工程取舍。
当开发环境能够被快速交付，新的瓶颈会继续向模型权重加载、Prefill/Decode 协同、KV Cache、空闲 CPU 复用和异构算力选型迁移。智算平台的终点不是"纳管集群"，而是让开发者更快获得稳定环境，让模型运行在更合适的算力上。
圆桌｜从 Incubating 再出发
技术分享之后，活动进入社区圆桌环节。讨论从几位嘉宾使用和贡献 HAMi 的真实经历出发，进一步延伸至 AI Coding 浪潮下的开源协作方式，以及 HAMi 下一阶段的技术演进。
现场讨论主要聚焦三个方向：
- **从使用者到贡献者。**大家分享了在企业环境中选择 HAMi 的实际场景，并讨论新人如何从真实 Issue、文档、测试或第一个 PR 开始参与社区。
- **AI Coding 如何进入开源协作。**AI 生成代码并不是问题本身，关键在于贡献者是否真正理解代码、主动说明 AI 的参与方式，并对提交结果负责。代码评审也需要从检查具体实现，进一步延伸至需求是否真实、设计是否合理以及实现边界是否清晰。
- **HAMi 下一步如何面向 AI。**嘉宾围绕 MCP 与自动化诊断工具、项目知识库建设，以及大小模型并存、国产异构算力持续增长等趋势展开讨论。对于 HAMi 而言，资源切分、共享、隔离与调度依然存在广泛而持续的应用空间。
进入 Incubating，意味着 HAMi 在技术成熟度和社区发展上迈入新的阶段。下一步，社区既需要降低新人参与和用户排障的门槛，也需要持续回应真实生产环境中的算力管理需求，让更多企业、开发者与生态伙伴能够共同参与项目建设。
五场分享，一个共同答案
从 HAMi 的远程 GPU 与 DRA 演进，到 llm-d 的分布式推理控制平面；从国产 GPU 上的端到端 SLO，到 Volcano + HAMi-core 的调度与隔离，再到智算平台的环境交付，五场分享覆盖了不同技术层次，却最终指向同一件事：
算力效率不是某一个组件的单点能力，而是一套贯穿资源接入、调度、隔离、路由、观测、交付与社区协作的系统工程。
对于正在建设 AI 平台的企业而言，有三点尤其值得带走：
- **资源可分配，不等于算力可运营。**真实利用率、拓扑、租户边界与任务生命周期都必须进入统一治理。
- **模型能启动，不等于推理可交付。**首 Token、尾延迟、吞吐、缓存和故障恢复需要共同接受 SLO 验证。
- **技术能落地，不等于生态可持续。**只有把企业问题沉淀为开放、可复用的社区能力，项目才能服务更多硬件、平台和真实场景。
