Fall 2026 · Industry Projects
Course Projects
Each project addresses a real AI-infrastructure challenge contributed by an industry partner. The briefs define the problem, expected outcomes, and evaluation criteria while leaving implementation choices open to each student team.
Project expectations
Develop a verifiable systems solution
Each team is expected to turn its selected topic into a working systems solution: an Ascend A3 attention kernel, an automated inference-optimization workflow, a model–harness co-design pipeline, a single-GPU mega-kernel prototype, or a multi-GPU communication–computation fusion implementation. The technical approach is open, but it must be justified by the characteristics of the target workload and execution environment. Every project must include a reproducible baseline, a complete technical design, an executable implementation, a verifiable end-to-end demo with correctness checks, and quantitative evidence using the metrics defined in its project brief.
01
Efficient KDA Chunk Prefill on Ascend A3 with EasyASC
Contributing Organization Huawei
Efficient KDA Chunk Prefill on Ascend A3 with EasyASC
Contributing Organization Huawei
Background
Kimi Delta Attention (KDA) is a recurrent linear-attention mechanism that uses a gated state update. During prefill, processing one token at a time leaves substantial parallelism unused. A chunk-prefill implementation instead reorganizes the work within each group of tokens into matrix and vector operations while carrying the attention state from one chunk to the next. On Ascend A3, this design must also account for the device's Cube and Vector execution paths, on-chip storage limits, synchronization costs, and data exchange through global-memory workspaces. The full specification, reference implementation, test cases, and evaluation template are available in the project repository and exercise package.
Project Objective
The objective is to implement an efficient KDA chunk-prefill forward operator for Ascend A3 using the EasyASC Python domain-specific language. The project must also develop a reusable method for deciding how to divide, organize, and schedule the operator across multiple kernels. Predictions from this method should guide the implementation and then be tested against correctness results, execution traces, simulator estimates, and available hardware measurements.
Project Requirements
The implementation must include Q/K normalization, exploit parallelism among tokens within each chunk, preserve the state dependency between chunks, accept an optional initial state, and correctly handle a final partial chunk. The team must compare at least two materially different kernel-partition strategies. For each strategy, the analysis must explain the computation assigned to Cube and Vector pipelines, intermediate-data layouts, synchronization and buffering, logical global-memory traffic, expected L2-cache reuse, device-memory traffic, and numerical-precision choices. The implementation must obey the exercise package's host-operation restrictions and pass its required forward-correctness tests. A token-by-token recurrent decode loop is a reference for checking semantics, not the target implementation.
Required Submission
The submission must include the EasyASC kernel source, a complete forward entry point, environment and execution instructions, and correctness reports produced with the published exercise package. It must also include a kernel-partition evaluation model in the form of a report, tool, skill, or program that another developer can apply to a new input shape or operator. The final report must document both candidate strategies, predictions made before measurement, per-kernel and total execution time, workspace and cache assumptions, numerical results, execution traces that explain pipeline behavior, discrepancies between predictions and measurements, limitations, and reproducibility steps. Hardware-performance claims must identify the Ascend A3 system, CANN version, and measurement method.
Evaluation Criteria
Evaluation will consider forward correctness, effective use of chunk-level parallelism, the quality of the Cube/Vector decomposition and scheduling design, measured kernel performance, numerical robustness, the strength of the prediction-versus-measurement analysis, reproducibility, and whether the evaluation method is useful beyond this single implementation.
02
Full-stack Inference Optimization Harness for Coding-Agent Workloads
Contributing Organization ByteDance
Full-stack Inference Optimization Harness for Coding-Agent Workloads
Contributing Organization ByteDance
Background
The cost and throughput of an inference service are jointly determined by kernels, the serving engine, communication, KV-cache management, storage, and distributed scheduling. Manual layer-by-layer optimization covers only a small portion of this design space and can easily converge on a local optimum. Coding-agent workloads make this challenge especially important because they combine very long inputs with KV-cache hit rates above 90 percent.
Project Objective
The objective is to build an automated optimization harness for a provided serving-engine baseline, model, and target hardware. The harness should form a closed workflow that diagnoses bottlenecks, proposes and applies optimizations, executes controlled experiments, analyzes results, and detects regressions. The resulting system should improve serving cost-effectiveness without violating the specified service-quality constraints.
Project Requirements
The system must provide a reproducible replay of a representative coding-agent workload containing long inputs and a KV-cache hit rate above 90 percent. Disaggregated prefill and decode must be evaluated as the primary deployment setting and compared with a colocated prefill-and-decode baseline. Under a fixed model and hardware configuration, the team must measure QPS while satisfying the specified time-to-first-token (TTFT) and time-per-output-token (TPOT) service-level objectives. The evaluation must isolate the contribution of major optimizations and examine important interactions across system layers. The choice of optimization algorithms, agent workflow, software stack, and system architecture is left to the team.
Required Submission
The submission must include a technical proposal describing the architecture, optimization loop, design rationale, experiment plan, and risks; the complete implementation with configuration and environment information; and a verifiable demo that replays the target workload, applies at least one optimization, checks service correctness and SLO compliance, and reports before-and-after measurements. A final report must document the baseline, QPS, TTFT, TPOT, cost assumptions, ablation results, reproducibility procedure, limitations, and unsuccessful approaches.
Evaluation Criteria
Evaluation will consider functional correctness, the completeness and automation of the optimization loop, improvement over the baseline under the required SLOs, quality of cross-layer analysis, reproducibility, and the clarity of the technical justification.
03
Model–Harness Co-design RL Pipeline Based on DeepSeek Harness
Contributing Organization ByteDance
Model–Harness Co-design RL Pipeline Based on DeepSeek Harness
Contributing Organization ByteDance
Background
An agent's capability depends on both its model and its harness. The model provides the core policy, while the harness controls execution and embeds policy decisions such as context compaction, reasoning format, and tool-result retention. A model may become strongly coupled to the harness used during training, which means that a fixed, manually designed harness may not produce the best overall agent.
Project Objective
The objective is to build a reproducible model–harness co-design reinforcement-learning pipeline based on DeepSeek Harness. The pipeline should expose important harness policies as trainable or searchable decisions and enable the model and harness to evolve jointly for a provided task distribution.
Project Requirements
The experimental design must include context compaction, reasoning format, and tool-result retention within the harness-policy space. It must compare three controlled settings: a fixed harness, separate optimization of the model and harness, and joint model–harness optimization. All comparisons must use comparable training and inference budgets. The evaluation must report task success rate, token consumption, tool-call cost, and stability across task settings, together with ablation studies that identify the contribution of individual harness-policy choices. The specific reinforcement-learning method, search strategy, parameterization, and implementation framework are open design decisions.
Required Submission
The submission must include a technical proposal defining the trainable policy space, learning or search procedure, controls, budget, metrics, and risk-management plan; a working pipeline with code, configurations, task definitions, and reproducible launch instructions; and a verifiable demo that runs a small end-to-end training or optimization cycle and evaluates the resulting model–harness configuration on held-out tasks. A final report must present the controlled comparison, benchmark results, ablations, statistical or repeated-run evidence, cost analysis, limitations, and conclusions about model–harness compatibility.
Evaluation Criteria
Evaluation will consider pipeline correctness, experimental rigor, fairness of the controlled comparison, task-performance and efficiency gains, strength of the ablation evidence, reproducibility, and whether the conclusions follow from the reported results.
04
Subgraph-fusion-based Mega-kernel Generation
Contributing Organization Tencent
Subgraph-fusion-based Mega-kernel Generation
Contributing Organization Tencent
Background
Advertising-model training frequently contains fine-grained operators. Repeated kernel launches and device-memory transfers for intermediate results create substantial scheduling overhead and memory pressure. Fusing multiple operators into larger mega-kernels can reduce these costs, but automatically performing the fusion while preserving both forward- and backward-pass correctness remains challenging.
Project Objective
The objective is to create a prototype that transforms a provided PyTorch computation subgraph into one or more fused mega-kernels covering forward and backward computation. The prototype should reduce memory traffic or memory footprint and improve execution throughput while remaining numerically consistent with the unfused reference.
Project Requirements
The project will use a provided PyTorch subgraph, representative input shapes, and reference input/output cases. The solution must identify fusible operators, determine defensible fusion boundaries, generate or construct the fused forward and backward computation, and provide repeatable correctness checks against the reference implementation. The evaluation must use a single GPU and include subgraphs in which element-wise operations account for a significant portion of execution time. The team must measure latency or throughput, peak memory use, and relevant memory-traffic indicators across representative inputs. The code-generation approach, kernel language, compiler stack, scheduling strategy, and memory-management technique are not prescribed.
Required Submission
The submission must include a technical proposal explaining fusion eligibility, boundary selection, forward and backward generation, memory optimization, correctness tolerances, and evaluation methodology; a working prototype with source code, environment details, and reproducible commands; and a verifiable demo that accepts at least one provided subgraph, produces or invokes the fused implementation, checks forward outputs and backward gradients against the reference, and displays performance and memory results. A final report must compare the fused and unfused implementations, explain the sources of improvement, document cases that cannot be fused, and discuss limitations.
Evaluation Criteria
Evaluation will consider forward and backward correctness, the generality and soundness of the fusion process, reduction in launch or memory overhead, measured speedup and memory benefit, robustness across test cases, reproducibility, and the quality of the systems analysis.
05
Communication–Computation Fusion for Advertising-model Training
Contributing Organization Tencent
Communication–Computation Fusion for Advertising-model Training
Contributing Organization Tencent
Background
Distributed training of large sparse advertising models commonly uses expert or model parallelism, which introduces substantial All-to-All communication. When communication and computation execute serially, communication becomes a major performance bottleneck. A fine-grained overlap between communication and computation can hide part of this cost and improve cluster-level training efficiency.
Project Objective
The objective is to design a distributed parallelization scheme for a provided PyTorch layer dominated by GEMM computation and to implement at least one communication–computation fusion kernel that overlaps GEMM with All-to-All communication. The implementation should preserve numerical correctness and improve end-to-end throughput relative to a non-overlapped baseline.
Project Requirements
The team must justify its parallel decomposition, fine-grained pipeline, scheduling policy, and data-dependency management. The solution must be tested using the provided layer and reference cases on multiple GPUs, including a cross-node configuration, and must analyze the behavioral and performance differences between intra-node and inter-node communication. Measurements must quantify exposed communication time, the fraction of communication hidden by overlap, kernel or layer latency, and end-to-end throughput. The implementation may use any suitable communication library, kernel framework, runtime, or scheduling method.
Required Submission
The submission must include a technical proposal describing the parallel strategy, fusion boundary, pipeline and dependency design, correctness plan, hardware topology, baseline, and evaluation methodology; a working multi-GPU implementation with source code, configuration, environment information, and launch instructions; and a verifiable demo that runs both the non-overlapped baseline and fused implementation, checks numerical outputs and gradients where applicable, and reports communication and throughput measurements. A final report must present intra-node and inter-node results, explain the degree of achieved overlap, analyze bottlenecks and scaling behavior, and document limitations and failed approaches.
Evaluation Criteria
Evaluation will consider numerical correctness, soundness of the parallel and pipeline design, effectiveness of communication hiding, end-to-end throughput improvement, quality of the topology-aware analysis, scalability, reproducibility, and clarity of the engineering evidence.