DeepGEMM เปลี่ยนผ่านเชิงคุณภาพ: จากไลบรารี GEMM สู่แพลตฟอร์มพื้นฐานการคำนวณแบบครบวงจรสำหรับ LLM

นับตั้งแต่เปิดตัวครั้งแรกในต้นปี 2025 DeepGEMM เป็นไลบรารี Tensor Core kernel ประสิทธิภาพสูงที่ทีม DeepSeek สร้างขึ้นสำหรับ NVIDIA GPU (SM90/SM100)

อย่างไรก็ตาม PR #304 นี้ถือเป็นจุดเปลี่ยนครั้งสำคัญของ DeepGEMM โดยได้ยกระดับจาก “ไลบรารี GEMM ที่สะอาดและมีประสิทธิภาพ” ไปเป็น “แพลตฟอร์มพื้นฐานการคำนวณแบบครบวงจรสำหรับโมเดลภาษาขนาดใหญ่สมัยใหม่” โดยคำอธิบายตนเองใน README ได้เปลี่ยนจาก “a library designed for clean and efficient GEMMs” เป็น “a unified, high-performance tensor core kernel library that brings together the key computation primitives of modern large language models” อย่างเป็นทางการ

• [Public release 26/04] เปิดตัว Mega MoE, FP4 Indexer และฟีเจอร์/การแก้ไขอื่นๆ
• Mega MoE ยังอยู่ในขั้นตอนการพัฒนาและปรับแต่ง ยินดีต้อนรับข้อเสนอแนะเพื่อการปรับปรุง!
• ข้อจำกัดความรับผิดชอบ: การเผยแพร่ครั้งนี้เกี่ยวข้องเฉพาะความคืบหน้าของการพัฒนา DeepGEMM เท่านั้น ไม่เกี่ยวข้องกับการเผยแพร่โมเดลภายใน
• https://github.com/deepseek-ai/DeepGEMM/pull/304

การเผยแพร่ครั้งนี้ดำเนินการโดยผู้มีส่วนร่วม 9 คน เกี่ยวข้องกับไฟล์ 109 ไฟล์ และเพิ่มโค้ดมากกว่า 12,000 บรรทัด การเปลี่ยนแปลงหลักสามารถสรุปได้เป็นสามทิศทาง: Mega Moe Fusion Kernel, FP4 Indexer (MQA logits) และ การปรับโครงสร้างฮิวริสติก GEMM อย่างครอบคลุมและการเพิ่มประสิทธิภาพทางวิศวกรรม ต่อไปนี้จะเป็นการวิเคราะห์เชิงลึกทีละประเด็น

สารบัญ

• หนึ่ง, Mega MoE: “ซูเปอร์เคอร์เนล” ที่ซ้อนทับการสื่อสารและการคำนวณอย่างลึกซึ้ง
• 1.1 แก่นแท้ของปัญหา: คอขวดการสื่อสาร NVLink ในการอนุมาน MoE
• 1.2 แนวทางแก้ไข: การรวมห้าขั้นตอน + การซ้อนทับการสื่อสาร/การคำนวณ
• 1.3 การออกแบบเค้าโครง Buffer
• สอง, FP4 Indexer: การคำนวณ MQA Logits ความแม่นยำต่ำ
• 2.1 ความเป็นมาของปัญหา
• 2.2 การดำเนินการที่สำคัญ
• สาม, Dynamic Swap A/B: การเพิ่มประสิทธิภาพประสิทธิภาพที่สำคัญสำหรับ MoE GEMM
• 3.1 ปัญหา: Multicast ล้มเหลวในสถานการณ์ MoE บน SM100
• 3.2 แนวทางแก้ไข: สลับตัวถูกดำเนินการ A/B บน SM100
• สี่, การปรับโครงสร้างฮิวริสติกอย่างครอบคลุม
• 4.1 จาก Hard-coded สู่การกำหนดค่าแบบมีโครงสร้าง
• 4.2 SM90 นำการสร้างแบบจำลองแบนด์วิดท์ L1/L2
• ห้า, การปรับปรุงที่สำคัญอื่นๆ
• 5.1 PDL (Programmatic Dependent Launch)
• 5.2 การเร่งความเร็วการคอมไพล์ JIT และการแก้ไขระบบไฟล์แบบกระจาย
• 5.3 FP8 × FP4 GEMM
• 5.4 การอัปเกรดมาตรฐาน C++20
• สรุป

หนึ่ง, Mega MoE: “ซูเปอร์เคอร์เนล” ที่ซ้อนทับการสื่อสารและการคำนวณอย่างลึกซึ้ง

1.1 แก่นแท้ของปัญหา: คอขวดการสื่อสาร NVLink ในการอนุมาน MoE

ในโหมด Expert Parallelism (EP) การดำเนินการของเลเยอร์ MoE ประกอบด้วยห้าขั้นตอนแบบอนุกรม: dispatch → linear1 (FP8×FP4) → SwiGLU → linear2 (FP8×FP4) → combine

ในนั้น ขั้นตอน dispatch และ combine เกี่ยวข้องกับการสื่อสาร NVLink ข้ามโหนด วิธีการแบบดั้งเดิมคือการแยกการสื่อสารและการคำนวณเป็นเคอร์เนลอิสระที่ทำงานแบบอนุกรม ซึ่งนำไปสู่การใช้งานแบนด์วิดท์ NVLink ที่ต่ำ ในขณะที่ SM อยู่ในสถานะว่างระหว่างรอการสื่อสารเสร็จสิ้น

1.2 แนวทางแก้ไข: การรวมห้าขั้นตอน + การซ้อนทับการสื่อสาร/การคำนวณ

นวัตกรรมหลักของ Mega MoE คือการรวมห้าขั้นตอนข้างต้นเข้าเป็น mega-kernel เดียว ทำให้เกิดการซ้อนทับแบบไปป์ไลน์ระหว่างการสื่อสาร NVLink และการคำนวณ Tensor Core ภายในเคอร์เนล การออกแบบนี้อาศัยเทคโนโลยีหลักดังต่อไปนี้:

เทคโนโลยีหลัก 1: สถาปัตยกรรม Symmetric Memory

ใน csrc/apis/mega.hpp จะเห็นได้ว่า Mega MoE ใช้กลไกการจัดสรรหน่วยความจำแบบสมมาตรที่จัดทำโดย PyTorch >= 2.9 โดยทุก rank จะใช้ buffer ในพื้นที่ที่อยู่เดียวกัน โครงสร้าง SymBuffer (ดูที่ deep_gemm/include/deep_gemm/layout/sym_buffer.cuh) ทำการแปลพอยน์เตอร์ข้าม rank ผ่านการแมป offset:

// deep_gemm/include/deep_gemm/layout/sym_buffer.cuh  
template <uint32_t kNumRanks = kNumMaxRanks>  
struct SymBuffer {  
int64_t base;  
int64_t offsets[kNumMaxRanks];  
uint32_t rank_idx;  

template <typename ptr_t>  
CUTLASS_DEVICE ptr_t map(const ptr_t& ptr, const uint32_t& dst_rank_idx) const {  
int64_t mapped_ptr = offsets[dst_rank_idx] + reinterpret_cast<int64_t>(ptr);  
return *reinterpret_cast<ptr_t*>(&mapped_ptr);  
}  
};  

สิ่งนี้ทำให้เธรด GPU สามารถอ่านและเขียนหน่วยความจำโหนดระยะไกลได้โดยตรงผ่านการชดเชยที่อยู่ โดยไม่ต้องผ่านการประสานงานฝั่ง host

เทคโนโลยีหลัก 2: การแบ่งงานสามเฟสของเธรด

ในไฟล์ csrc/jit_kernels/heuristics/mega_moe.hpp สามารถสังเกตได้ว่า Mega MoE kernel แบ่งเธรดภายในออกเป็นสามบทบาทที่แตกต่างกัน:

• กลุ่มเธรด Dispatch (128 เธรด): รับผิดชอบการสื่อสาร NVLink โดยเฉพาะ ดำเนินการกระจายและรวบรวม token ข้าม rank
• กลุ่มเธรดที่ไม่ใช่ Epilogue (128 เธรด): ขับเคลื่อนลูปหลักของการโหลดข้อมูล TMA และการคำนวณ UMMA (Tensor Core)
• กลุ่มเธรด Epilogue (256 เธรด): ดำเนินการฟังก์ชันกระตุ้น SwiGLU, การหาปริมาณ FP8 และงานเขียนกลับเอาต์พุต TMA

const int num_dispatch_threads = 128;
const int num_non_epilogue_threads = 128;
const int num_epilogue_threads = 256;

เทคโนโลยีหลัก 3: กลไกการจัดตารางผู้เชี่ยวชาญระดับ Wave

เพื่อให้เกิดความสมดุลของโหลด Mega MoE ได้นำแนวคิด num_experts_per_wave มาใช้ แกนหลักของกลไกนี้คือแต่ละ “wave” จะประมวลผลผู้เชี่ยวชาญกลุ่มหนึ่ง และใช้การคำนวณแบบฮิวริสติก (พิจารณาปัจจัยความไม่สมดุล kImbalanceFactor = 2) เพื่อเลือกขนาด wave ที่เหมาะสม เพื่อให้แน่ใจว่า Streaming Multiprocessor (SM) ทั้งหมดมี block เพียงพอสำหรับการดำเนินการ:

// csrc/jit_kernels/heuristics/mega_moe.hpp#L83-L110
static int get_num_experts_per_wave_for_mega_moe(...) {
constexpr int kImbalanceFactor = 2;
// ...
int num_experts_per_wave = num_l1_blocks_per_expert > 0
? ceil_div(kImbalanceFactor * num_sms, num_l1_blocks_per_expert) : 1;
// Round up to nearest divisor of num_experts_per_rank
while (num_experts_per_wave < max_num_experts_per_wave
and num_experts_per_rank % num_experts_per_wave != 0)
        ++ num_experts_per_wave;
return num_experts_per_wave;
}

เทคโนโลยีหลัก 4: การใช้งาน NVLink Barrier

ในไฟล์ deep_gemm/include/deep_gemm/comm/barrier.cuh มีการใช้งานชุดดั้งเดิมการซิงโครไนซ์ข้าม rank NVLink อย่างสมบูรณ์ ชุดนี้ครอบคลุมการซิงโครไนซ์ภายใน grid, การแจ้งสัญญาณอะตอมมิกข้ามโหนดโดยใช้ ptx::red_add_rel_sys และมีกลไกตรวจจับหมดเวลา 30 วินาทีในตัว:

// deep_gemm/include/deep_gemm/comm/barrier.cuh
template <uint32_t kNumRanks, uint32_t kNumSMs, ...>
CUTLASS_DEVICE void nvlink_barrier(...) {
// Grid sync before NVLink signaling
grid_sync<kNumSMs, kGridSyncIndex>(workspace, sm_idx, thread_idx, sync_scope);

if (sm_idx == 0) {
// Send signals to remote ranks
if (thread_idx < kNumRanks)
ptx::red_add_rel_sys(sym_buffer.map(signal_ptr, thread_idx), ...);
// Wait arrival with 30s timeout
// ...
}
// Grid sync after NVLink completion
grid_sync<kNumSMs, kGridSyncIndex>(workspace, sm_idx, thread_idx, sync_scope);
}

1.3 การออกแบบเค้าโครง Buffer

ในไฟล์ csrc/apis/mega.hpp ฟังก์ชัน get_symm_buffer_size_for_mega_moe ได้ออกแบบลำดับการจัดเรียงของแต่ละพื้นที่ในหน่วยความจำแบบสมมาตรอย่างพิถีพิถัน: Workspace → Input(x, x_sf, topk_idx, topk_weights) → L1 pool(acts, sf, weights) → L2 pool(acts, sf) → Combine buffer(BF16) บัฟเฟอร์ทั้งหมดนี้เรียงต่อเนื่องกันในพื้นที่ที่อยู่ และบัฟเฟอร์ SF ถูกจัดตำแหน่งตามความละเอียด 128 องค์ประกอบของ UTCCP

สอง, FP4 Indexer: การคำนวณ MQA Logits ความแม่นยำต่ำ

2.1 ความเป็นมาของปัญหา

Lightning indexer ของ DeepSeek v3.2 ใช้ weighted ReLU MQA logits สำหรับการคำนวณคะแนน ก่อนหน้านี้ โซลูชันนี้รองรับเฉพาะความแม่นยำ FP8 เท่านั้น การเผยแพร่ครั้งนี้ได้เพิ่มการรองรับความแม่นยำ FP4 (เฉพาะสถาปัตยกรรม SM100/Blackwell) และขยายการรองรับ MTP (Multi-Token Prediction) ขนาดใหญ่ขึ้น

2.2 การดำเนินการที่สำคัญ

จากไฟล์ csrc/apis/attention.hpp จะเห็นได้ว่า API fp8_fp4_mqa_logits และ fp8_fp4_paged_mqa_logits ที่เพิ่งเปิดตัวได้รวมเส้นทางการประมวลผลทั้ง FP8 และ FP4 เข้าด้วยกัน ความแตกต่างหลักของเส้นทาง FP4 สะท้อนให้เห็นในประเด็นต่อไปนี้:

• Q และ KV ใช้ประเภทข้อมูล kPackedFP4 (ค่า FP4 สองค่าถูกบรรจุในหนึ่งไบต์)
• Scale factor ใช้ torch::kInt32 (การเข้ารหัส UE8M0)
• head_dim ถูกกำหนดเป็น 128 เพื่อให้แน่ใจว่ามีการจัดตำแหน่ง swizzle 64B
• TMA descriptor ใช้ fp4_unpacked_smem = false ซึ่งสอดคล้องกับ CU_TENSOR_MAP_DATA_TYPE_16U4_ALIGN8B

static torch::Tensor fp8_fp4_mqa_logits(
const std::tuple<torch::Tensor, std::optional<torch::Tensor>>& q,
const std::tuple<torch::Tensor, torch::Tensor>>& kv, ...) {
const auto [q_fp, q_sf] = q;
const bool is_fp4 = q_sf.has_value();
// FP4 path: head_dim *= 2 (packed), scalar type = kPackedFP4
// FP8 path: scalar type = kFloat8_e4m3fn
}

ในขณะเดียวกันก็ยังคงรักษา API `fp8_mqa_logits` แบบเก่าไว้เป็น wrapper เพื่อความเข้ากันได้ ซึ่งภายในจะเรียกใช้อินเทอร์เฟซใหม่และส่ง `std::nullopt` เป็นพารามิเตอร์ SF

## สาม, Dynamic Swap A/B: การเพิ่มประสิทธิภาพประสิทธิภาพที่สำคัญสำหรับ MoE GEMM

### 3.1 ปัญหา: Multicast ล้มเหลวในสถานการณ์ MoE บน SM100

ใน m-grouped contiguous GEMM ของ MoE เมทริกซ์ A (activation values) ถูกจัดเก็บอย่างต่อเนื่องตาม token ในขณะที่เมทริกซ์ B (weights) ถูกจัดเก็บเป็นกลุ่มตาม expert แม้ว่า TMA multicast บน SM100 จะสามารถกระจายข้อมูลภายใน cluster ได้ แต่เนื่องจากมิติ M ของ A (จำนวน token) มักจะมีขนาดเล็กและขาดความสม่ำเสมอ จึงทำให้ไม่สามารถดำเนินการ multicast กับ A ได้อย่างมีประสิทธิภาพ

### 3.2 แนวทางแก้ไข: สลับตัวถูกดำเนินการ A/B บน SM100

การปรับโครงสร้างครั้งนี้ได้เพิ่มฟิลด์ `Layout::swap_ab` ใน `GemmConfig` เมื่อ `swap_ab = 1` การคำนวณจริงจะเปลี่ยนเป็น `B^T @ A^T` ซึ่งทำให้มิติ N เดิม (hidden size ของเมทริกซ์น้ำหนัก ซึ่งมักจะมีขนาดใหญ่และสม่ำเสมอ) กลายเป็นมิติ M ของ UMMA ทำให้สามารถทำ cluster multicast ได้

// Always enable swap A/B for m-grouped GEMMs
if (desc.gemm_type == GemmType::MGroupedContiguous || …) {
const bool swap_ab = true;
const auto block_n = 128;
const auto block_m = heuristics_runtime->get_mk_alignment_for_contiguous_layout();
const auto cluster_n = ceil_div(desc.n, block_n) % 2 == 0
and desc.num_sms % 2 == 0 ? 2 : 1;
// …
}

ในระหว่างกระบวนการแจงนับตัวเลือกบน SM100 ทั้งสองทิศทาง `swap_ab` และไม่ใช่ `swap_ab` จะถูกนำมาพิจารณา (`for (int swap_ab = 0; swap_ab < 2; ++swap_ab)`) และตัวเปรียบเทียบแบบรวมจะเลือกการกำหนดค่าที่ดีที่สุดจากทั้งสอง การเพิ่มประสิทธิภาพนี้มีผลอย่างมากต่อประสิทธิภาพในสถานการณ์ MoE

## สี่, การปรับโครงสร้างฮิวริสติกอย่างครอบคลุม

### 4.1 จาก Hard-coded สู่การกำหนดค่าแบบมีโครงสร้าง

ระบบฮิวริสติกทั้งหมดผ่านการปรับโครงสร้างครั้งใหญ่ `GemmConfig` ในโค้ดเก่าเป็นโครงสร้างที่ซับซ้อน ในขณะที่โค้ดใหม่ได้แยกออกเป็นสี่ชั้นที่ชัดเจน:

// csrc/jit_kernels/heuristics/config.hpp#L134-L140
struct GemmConfig {
Layout layout; // block_m/n/k, swap_ab, cluster_m/n
StorageConfig storage_config; // load/store block sizes, swizzle modes
PipelineConfig pipeline_config; // num_stages, smem_size
LaunchConfig launch_config; // num_sms, num_threads
};

### 4.2 SM90 นำการสร้างแบบจำลองแบนด์วิดท์ L1/L2

การเลือกการกำหนดค่าสำหรับ SM90 ได้รับการอัปเกรดจาก "การลดจำนวนคลื่นให้น้อยที่สุด" เป็น **การประมาณรอบตามการสร้างแบบจำลองแบนด์วิดท์ L1/L2**:

// csrc/jit_kernels/heuristics/sm90.hpp#L159-L176
const int l2_bandwidth_per_cycle = std::min(64. * desc.num_sms, 8e6 / 1.3e3);
const int l1_bandwidth_per_cycle = 128 * desc.num_sms;
// …
int64_t num_l2_cycles = (num_bytes_l2_ab + num_bytes_l1_l2_cd) * num_blocks / l2_bandwidth_per_cycle;
int64_t num_l1_cycles = (num_bytes_l1_ab + num_bytes_l1_tc + …) * num_blocks / l1_bandwidth_per_cycle;
float wave_efficiency = static_cast(num_blocks) / (num_waves * desc.num_sms);
int64_t num_cycles = std::max(num_l1_cycles, num_l2_cycles) / wave_efficiency;

การปรับปรุงนี้ทำให้ SM90 สามารถเลือกขนาด block และกลยุทธ์ multicast ได้แม่นยำยิ่งขึ้นเมื่อจัดการกับสถานการณ์เมทริกซ์ขนาดเล็ก

## ห้า, การปรับปรุงที่สำคัญอื่นๆ

### 5.1 PDL (Programmatic Dependent Launch)

เพิ่ม API `set_pdl` / `get_pdl` เพื่อตั้งค่าแอตทริบิวต์ `cudaLaunchAttributeProgrammaticStreamSerialization` ระหว่างการเปิดตัว kernel ซึ่งอนุญาตให้ CUDA runtime เริ่มต้น kernel ถัดไปก่อนที่ kernel ก่อนหน้าจะสิ้นสุดลงอย่างสมบูรณ์ ซึ่งช่วยลดช่องว่างระหว่างการดำเนินการของ kernel ได้อย่างมีประสิทธิภาพ:

// csrc/jit/handle.hpp#L92-L98
if (enable_pdl) {
auto& attr = attrs[config.numAttrs ++];
attr.id = cudaLaunchAttributeProgrammaticStreamSerialization;
attr.val.programmaticStreamSerializationAllowed = 1;
}
“`

5.2 การเร่งความเร็วการคอมไพล์ JIT และการแก้ไขระบบไฟล์แบบกระจาย

• Incremental Hashing: เพิ่ม IncludeParser (อยู่ที่ csrc/jit/include_parser.hpp) ซึ่งจะคำนวณแฮชแบบเรียกซ้ำเฉพาะกับต้นไม้การพึ่งพา #include <deep_gemm/*> เท่านั้น แทนที่การแฮชเนื้อหาไฟล์ส่วนหัวทั้งหมดก่อนหน้านี้ ซึ่งช่วยลดค่าใช้จ่ายในการคำนวณคีย์แคชได้อย่างมาก
• Atomic Directory Rename: ผลิตภัณฑ์จากการคอมไพล์จะถูกเขียนไปยังไดเรกทอรีชั่วคราวก่อน จากนั้นจึงดำเนินการเปลี่ยนชื่อแบบอะตอมมิกผ่าน std::filesystem::rename ซึ่งช่วยแก้ปัญหาความเสียหายของแคช JIT ที่เกิดจากการแข่งขันของหลายกระบวนการบนระบบไฟล์แบบกระจาย (เช่น NFS/Lustre) ได้อย่างสมบูรณ์ นอกจากนี้ หลังจากเขียนเสร็จจะเรียก fsync เพื่อให้แน่ใจว่าข้อมูลถูกจัดเก็บอย่างถาวร
• Corruption Detection: เมื่อโหลดไฟล์ CUBIN จะตรวจสอบผ่าน cuLibraryGetKernelCount ว่าจำนวน kernel ต้องเป็น 1 หากไม่เป็นไปตามนั้นจะแจ้งให้ผู้ใช้ล้างไดเรกทอรีแคช

5.3 FP8 × FP4 GEMM

เพิ่ม sm100_fp8_fp4_gemm_1d1d.hpp รองรับการดำเนินการ GEMM แบบผสมความแม่นยำโดยที่ A เป็น FP8 และ B เป็น FP4 (หรือกลับกัน) ซึ่งเป็นหน่วยการคำนวณพื้นฐานของ Mega MoE

5.4 การอัปเกรดมาตรฐาน C++20

โปรเจกต์ได้รับการอัปเกรดจาก C++17 เป็น C++20 (เปิดใช้งานผ่าน CMAKE_CXX_STANDARD 20 ใน CMakeLists.txt) เพื่อรองรับคุณสมบัติภาษาโมเดิร์น เช่น std::variant, designated initializers เป็นต้น

สรุป

PR #304 ถือเป็นการเผยแพร่เวอร์ชันสาธารณะที่ใหญ่ที่สุดของ DeepGEMM จนถึงปัจจุบัน คุณค่าหลักของมันสะท้อนให้เห็นในประเด็นต่อไปนี้:

1. Mega MoE เป็นโอเพนซอร์สชิ้นแรกในอุตสาหกรรมที่รวมห้าขั้นตอน EP dispatch, linear1, SwiGLU, linear2 และ combine เข้าเป็นเคอร์เนลเดียว โดยใช้เทคโนโลยี Symmetric Memory, การแบ่งงานสามบทบาทของเธรด และ NVLink barrier เพื่อให้เกิดการซ้อนทับอย่างลึกซึ้งระหว่างการสื่อสารและการคำนวณ
2. Dynamic Swap A/B แก้ปัญหาคอขวดของ MoE GEMM multicast บน SM100 ได้อย่างมีประสิทธิภาพ แม้หลักการจะดูเรียบง่าย แต่ผลลัพธ์การเพิ่มประสิทธิภาพทางวิศวกรรมนั้นโดดเด่น
3. การปรับโครงสร้างระบบฮิวริสติกอย่างมีโครงสร้าง ได้วางรากฐานที่มั่นคงสำหรับการรองรับสถาปัตยกรรมฮาร์ดแวร์เพิ่มเติมและการปรับแต่งอัตโนมัติที่ละเอียดยิ่งขึ้นในอนาคต
4. การแก้ไขระบบไฟล์แบบกระจายสำหรับการคอมไพล์ JIT แก้ปัญหาที่พบในการปรับใช้จริงบนคลัสเตอร์การฝึกอบรมและการอนุมานขนาดใหญ่

ตามที่กล่าวไว้ในคำอธิบาย PR: “Mega MoE is still under development and optimizations, stay tuned” — นี่เป็นเพียงจุดเริ่มต้นเท่านั้น

ข้อมูลประสิทธิภาพจะถูกเปิดเผยตามลำดับในภายหลัง และ DeepEP V2 (ซึ่งมี ElasticBuffer) ก็กำลังจะเปิดตัวตามมาเช่นกัน เมื่อถึงเวลานั้น การทดสอบแบบหลายกระบวนการเต็มรูปแบบของ Mega MoE จึงจะสามารถดำเนินการได้สำเร็จ การเผยแพร่ครั้งนี้แสดงให้เห็นถึงความเชี่ยวชาญเชิงลึกของทีม DeepSeek ในการเพิ่มประสิทธิภาพระดับไมโครสถาปัตยกรรม GPU และยังเป็นทรัพยากรอันมีค่าสำหรับชุมชนโอเพนซอร์สในการเรียนรู้การออกแบบเคอร์เนลการอนุมาน LLM สมัยใหม่

คำแนะนำที่เกี่ยวข้อง

• ปลดล็อกประสิทธิภาพสูงสุดของ GPU GEMM! PyTorch ผสานรวมแบ็กเอนด์ CuteDSL ครอบคลุม BF16/FP8/FP4
• วิธีเขียน MoE Align Block Size ที่เร็วกว่า SGLang ด้วย Triton
• การตัดสินใจระดับไมโครวินาที ประสิทธิภาพเกือบดีที่สุด! AMD เสนอ tritonBLAS: บอกลาการค้นหาพารามิเตอร์ที่ใช้เวลานาน ใช้ “คณิตศาสตร์” คำนวณการคูณเมทริกซ์ที่เร็วที่สุด