Zhixing Ren

Jiace Zhu, Wentao Chen, Qi Fan et al.

Recent studies have demonstrated the potential of Large Language Models (LLMs) in generating GPU Kernels. Current benchmarks focus on the translation of high-level languages into CUDA, overlooking the more general and challenging task of text-to-CUDA generation. Furthermore, given the hardware-specific and performance-critical features of GPU programming, accurately assessing the performance of LLM-generated GPU programs is nontrivial. In this work, we introduce CUDABench, a comprehensive benchmark designed to evaluate the text-to-CUDA capabilities of LLMs. First, we construct CUDABench-Set, which covers Breadth-Depth-Difficulty evaluation space in diverse application domains, including artificial intelligence, scientific computing, and data analytics, etc. Furthermore, we propose CUDABench-Score and Generative Verification Pipeline that assess (1) compilation correctness, (2) functional consistency through execution-based verification, and (3) a novel roofline-based metric, Performance-Score. Benchmarking state-of-the-art LLMs reveals insightful findings and challenges of text-to-CUDA, such as a notable mismatch between high compilation success rates and low functional correctness, a lack of domain-specific algorithmic knowledge, and suboptimal utilization of GPU hardware resources. Our benchmark is available at https://github.com/CUDA-Bench/CUDABench.

Kaikai An, Fangkai Yang, Junting Lu et al. · pku

Effective incident management is pivotal for the smooth operation of enterprises-level cloud services. In order to expedite incident mitigation, service teams compile troubleshooting knowledge into Troubleshooting Guides (TSGs) accessible to on-call engineers (OCEs). While automated pipelines are enabled to resolve the most frequent and easy incidents, there still exist complex incidents that require OCEs' intervention. However, TSGs are often unstructured and incomplete, which requires manual interpretation by OCEs, leading to on-call fatigue and decreased productivity, especially among new-hire OCEs. In this work, we propose Nissist which leverages TSGs and incident mitigation histories to provide proactive suggestions, reducing human intervention. Leveraging Large Language Models (LLM), Nissist extracts insights from unstructured TSGs and historical incident mitigation discussions, forming a comprehensive knowledge base. Its multi-agent system design enhances proficiency in precisely discerning user queries, retrieving relevant information, and delivering systematic plans consecutively. Through our user case and experiment, we demonstrate that Nissist significant reduce Time to Mitigate (TTM) in incident mitigation, alleviating operational burdens on OCEs and improving service reliability. Our demo is available at https://aka.ms/nissist_demo.

Hao Zhang, Zhan Li, Zhixing Ren

Data center (DC) contains both IT devices and facility equipment, and the operation of a DC requires a high-quality monitoring (anomaly detection) system. There are lots of sensors in computer rooms for the DC monitoring system, and they are inherently related. This work proposes a data-driven pipeline (ts2graph) to build a DC graph of things (sensor graph) from the time series measurements of sensors. The sensor graph is an undirected weighted property graph, where sensors are the nodes, sensor features are the node properties, and sensor connections are the edges. The sensor node property is defined by features that characterize the sensor events (behaviors), instead of the original time series. The sensor connection (edge weight) is defined by the probability of concurrent events between two sensors. A graph of things prototype is constructed from the sensor time series of a real data center, and it successfully reveals meaningful relationships between the sensors. To demonstrate the use of the DC sensor graph for anomaly detection, we compare the performance of graph neural network (GNN) and existing standard methods on synthetic anomaly data. GNN outperforms existing algorithms by a factor of 2 to 3 (in terms of precision and F1 score), because it takes into account the topology relationship between DC sensors. We expect that the DC sensor graph can serve as the infrastructure for the DC monitoring system since it represents the sensor relationships.