Research Scientist - AI Compute & DPU - Global Frontier Tech Recruitment Program - 2027 Start (PhD)

We need to output HTML fragment with sections: Responsibilities, Team Introduction, What Makes This Different, Who We Are Looking For, Topic Content, Qualifications (Minimum and Preferred), Job Information (Pay Transparency includes compensation description and benefits). Also maybe "About Us", "Why Join ByteDance", "Diversity & Inclusion", "Reasonable Accommodation" but we should only include sections when posting has real specific content. The instructions: include a section ONLY when the posting has real, specific content for it — never emit a heading followed by filler/placeholder text. So we can include sections for which there is substantive content. We need to use

for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). Use

• for any list of duties/requirements/benefits, and

  for prose. Do NOT repeat the job title as a heading (the page already shows it) and do NOT put Job ID / requisition numbers as headings — fold minor metadata into a short

  or drop it. We need to preserve ALL substantive information; do NOT invent or summarize away detail. Remove cookie/navigation/legal/EEO/equal-opportunity/scam-warning boilerplate, duplicated lines, and application instructions. We need to output only HTML fragment, no /, no markdown code fences. Thus we need to parse the posting and extract relevant sections. Let's identify sections: - Responsibilities: The posting starts with "Responsibilities We are looking for talented individuals to join our team. As a graduate, you will get opportunities to pursue bold ideas, tackle complex challenges, and unlock limitless growth. Successful candidates must be able to commit to an onboarding date by the end of the year. Please state your availability and graduation date clearly in your resume." That's responsibilities content. We'll put

  Responsibilities

  then

  with that prose. But note: The responsibilities also include "Team Introduction" after that? Actually after responsibilities there is "Team Introduction". That seems like a separate section describing the team. So we can have a section "Team Introduction". Use

  Team Introduction

  then paragraphs. - What Makes This Different: heading present. So

  What Makes This Different

  then paragraphs. - Who We Are Looking For: heading present. So

  Who We Are Looking For

  then paragraphs. - Topic Content: heading present. So

  Topic Content

  then paragraphs (with sub-bullets? It lists topics with colon and description). We can keep as paragraphs or maybe list each bullet as
  • . The instruction: Use
    • for any list of duties/requirements/benefits. For topic content, it's a list of research areas. Could treat as list. We'll decide to use
      • for each bullet. - Qualifications: heading present. It includes Minimum Qualifications and Preferred Qualifications. Could split into two sub-sections? But we only have headings for Qualifications (maybe we can keep as one section with two paragraphs: Minimum Qualifications and Preferred Qualifications). Or we could make subheadings but only allowed headings are those listed? The instruction says use

        for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). It doesn't forbid other headings but suggests using those. Safer to keep Qualifications as

        Qualifications

        and inside we can have

        for Minimum Qualifications and another

        for Preferred Qualifications, maybe with tags? But we should not invent markup beyond allowed? Not restricted. We'll just use

        with bold text. - Job Information: includes compensation description and benefits. Could be split into Pay and Benefits sections. The instruction: Prefer a few substantive sections over many thin ones. But we have both Pay and Benefits as possible headings. Since the posting includes compensation description and benefits details, we could create two sections: Pay and Benefits. Or combine into one "Job Information" but we have headings Pay and Benefits allowed. Let's see: The posting includes "Compensation Description (Annually)" and then benefits description. So we can make

        Pay

        with the compensation paragraph, and

        Benefits

        with benefits paragraph. - Also there is "About Us", "Why Join ByteDance", "Diversity & Inclusion", "Reasonable Accommodation". Those are also substantive. Should we include them? The instruction: include a section ONLY when the posting has real, specific content for it — never emit a heading followed by filler/placeholder text. Those sections have real content. However the allowed headings list includes About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule. It does not list About Us, Why Join ByteDance, Diversity & Inclusion, Reasonable Accommodation. But we could still use

        for any heading? The instruction says use

        for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). It gives examples but not exclusive list. Probably we can use any heading but better to stick to those examples? The instruction: "use

        for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule)." This suggests those are typical headings but not limited. However to be safe, we could map those sections to allowed headings: About Us could be "About the role"? Not exactly. Why Join ByteDance could be "Skills"? Not. Diversity & Inclusion maybe "Requirements"? Not. Reasonable Accommodation maybe "Schedule"? Not. Given the instruction to prefer a few substantive sections over many thin ones, maybe we should combine those into fewer sections or drop them if they are considered boilerplate? But they are not boilerplate; they are specific content about company mission etc. However the instruction also says remove cookie/navigation/legal/EEO/equal-opportunity/scam-warning boilerplate, duplicated lines, and application instructions. Those sections are not boilerplate; they are company culture etc. Might be okay to keep. But the heading list didn't include them; but we can still use

        with those titles. The instruction didn't forbid other headings; just gave examples. So we can include them. Nevertheless, to follow "prefer a few substantive sections over many thin ones", maybe we should combine "About Us", "Why Join ByteDance", "Diversity & Inclusion", "Reasonable Accommodation" into a single section like "About ByteDance" or something. But we don't have a heading for that. Could use "About the role" as heading for that combined section? That seems odd. Better to keep them as separate sections but maybe they are considered thin? They have multiple paragraphs each. Given the instruction to preserve ALL substantive information, we should keep them. Thus final HTML will have sections: Responsibilities, Team Introduction, What Makes This Different, Who We Are Looking For, Topic Content, Qualifications, Pay, Benefits, About Us, Why Join ByteDance, Diversity & Inclusion, Reasonable Accommodation. We need to ensure we use

        • for any list. For Qualifications we have lists of items (minimum qualifications bullet points). We'll convert each bullet to
        • . Similarly for Preferred Qualifications. For Topic Content we have bullet list; we'll use
          • . For Responsibilities we have prose; we can keep as

            . For Team Introduction we have paragraphs; we can keep as

            . For What Makes This Different we have paragraphs; we can keep as

            . For Who We Are Looking For we have paragraphs; we can keep as

            . For Pay we have compensation description; we can keep as

            . For Benefits we have benefits description; we can keep as

            . For About Us we have paragraphs; keep as

            . For Why Join ByteDance we have paragraphs; keep as

            . For Diversity & Inclusion we have paragraphs; keep as

            . For Reasonable Accommodation we have paragraphs; keep as

            . We must not include duplicated lines. Need to watch for duplicate sentences. Let's extract each section's content precisely. I'll copy the posting and parse. Posting: Responsibilities We are looking for talented individuals to join our team. As a graduate, you will get opportunities to pursue bold ideas, tackle complex challenges, and unlock limitless growth. Successful candidates must be able to commit to an onboarding date by the end of the year. Please state your availability and graduation date clearly in your resume. Team Introduction The ByteDance DPU (Data Processing Unit) team builds foundational cloud and AI computing infrastructure for ByteDance and Volcano Engine. Our mission is to advance the architecture, development, and research of next-generation software-hardware co-design technologies across compute, networking, and storage for cloud and AI computing. Our technology stack spans Cloud virtualization, hypervisors, and operating systems High-performance networking, including DPDK and RDMA High-speed interconnects, virtual switching, and network offload Distributed storage and I/O acceleration Orchestration and scheduling for AI/ML workloads Our organization—AI Compute + DPU—unifies three foundational layers: AI Compute & Orchestration Planet-scale, cloud-native scheduling and serverless systems built on Kubernetes, operating across hundreds of clusters with hundreds of millions of containers and jobs daily. Inference Infrastructure We support Seed business workloads (including SeedDance and other ByteDance models), as well as a wide range of open-source models. Through the open-sourcing of AIBrix, we are re-architecting LLM inference around KV cache systems, multimodal serving, advanced scheduling, and disaggregated execution, pushing the frontier of performance, cost efficiency, and latency. DPU & Hardware-Accelerated Systems Next-generation software–hardware co-design across compute, networking, and storage—covering GPU virtualization, RDMA/DPDK-based networking, high-speed interconnects, and distributed storage acceleration. Together, we operate a globally distributed, hyperscale AI infrastructure powering products such as Doubao/Dola and CapCut, with a rapidly growing fleet of accelerators and increasingly deep integration with open-source ecosystems. What Makes This Different This is not an incremental infrastructure team. We are redefining how AI systems are built and operated: Re-architecting LLM inference for heterogeneous, disaggregated environments Designing next-generation scheduling and caching primitives for AI workloads Bridging research breakthroughs with production systems at scale Building infrastructure that can self-optimize via AI (AI for systems) Driving cost-efficiency at extreme scale (GPU, CPU, network, power) This is a system-defining opportunity to work on problems that do not yet have established solutions. Who We Are Looking For Through our Global Frontier Recruitment Program, we are selectively hiring a very small number of PhD candidates who demonstrate the potential to: define technical directions, lead complex systems end-to-end, and create lasting impact in AI infrastructure. We are not looking for strong candidates. We are looking for candidates whose absence would be felt. Topic Content With the large-scale adoption of LLMs and AI agents, traditional cloud-native infrastructure can no longer meet the ultra-high performance and elasticity requirements of AI workloads. This topic conducts systematic research across the entire AI infrastructure stack: Network and Observability: Research intelligent fault localization and root cause analysis for large-scale AI clusters, combined with intelligent tuning of time-series databases to improve cluster stability. Storage Systems: Develop serverless high-performance elastic file systems and storage acceleration architectures specifically for AI scenarios, explore hardware-software co-optimization for DPU, and overcome AI storage performance bottlenecks. Data Center Power Scheduling: Research GPU/CPU/MEM heterogeneous collaborative scheduling technologies, build a heterogeneous power orchestration system for AI agents, and address scheduling challenges including heterogenous workloads and state dependencies. Vector Retrieval: Optimize core vector retrieval technologies for LLM-powered applications, building a cloud-native distributed vector index engine to meet ultra-large-scale vector