DeepSeek + Huawei = END of Nvidia?!

0:00 Move this matrix multiplication from an Nvidia GPU to Huawei's Ascend. Buying the chip doesn't supply the software that arranges these numbers and gets them into the calculation. If both chips

0:11 can multiply these numbers, why is switching difficult? Because the data needs a different arrangement and a different route into working storage. Deepseek's Deep Gem Ascend release

0:20 announced September 30th, 2026 supplies that machinery for supported operations with familiar entry points. Some operations are still missing. What changes underneath the same function

0:31 call? Watch these blue and orange tiles move from the storage shelf into smaller work trays. A blue row meets an orange column. Multiply the matching entries, then add those products. You've got one

0:43 position in the output. Repeat across the grids to build the result. Our illustration keeps that mathematical request visible while the machinery around it changes. Zoom out and you can

0:54 see the implementation moving whole tiles of those matrices through storage before calculating. We've got two jobs to follow. Doing the arithmetic and getting the right chunks into position

1:03 so the arithmetic can happen. Picture a large storage shelf with smaller work trays near the calculator. Huawei's documentation describes a trade-off between capacity and access efficiency.

1:15 You can hold more out on the shelf, but where you put the data matters when computation needs it. We call the specialized code handling this operation a kernel. This ascend kernel moves

1:25 matrix tiles from global memory into L1 then into L0 for matrix multiply ad. Those are the storage names behind our shelf and trays. Along the way, the tiles change arrangement, too. When

1:37 loading them into L1, the code uses what it calls a fractal layout. Leave the indexing details aside for now. Preparing these numbers includes choosing where each one sits. The

1:46 arithmetic hasn't changed. The seating plan has. Moving an operation between chips takes real engineering even when its purpose looks identical from the application. You're asking for the same

1:56 result, but the implementation has to organize the work for this chip. Low precision operations also use scale factors, values that set the numerical scale of the stored numbers. Picture

2:06 them as tags attached to the tiles. Ascend expects those tags in a particular packed format and layout. So moving the operation means preparing that supporting data too. Here, the

2:16 conversion helper packs pairs of scale factor values into 16bit integer containers arranged in what the code calls MN major layout. Beside an entire chip switch that sounds tiny, a

2:27 compatible implementation still has to get it right. Already got a tensor in the right format. The helper can reuse it, otherwise it launches a conversion. Even this preparation step needs a

2:37 decision. Can the calculation use the supporting data as it stands, or does it need rearranging first? Back at the matrix trays, watch the blue tile stay put while a new orange tile arrives.

2:49 With operand reuse, an input can remain available for another piece of work. You don't have to fetch it again for that next calculation. Keeping that input nearby reduces repeated transfers. We

3:00 can't turn that observation into a speedup number, but we can see the work it avoids. Why move the same input again when the next calculation can use the copy that's already there? Now add a

3:10 second tray. While one set of tiles feeds the calculation, another stage can prepare incoming data. Using staged buffers and coordinating requests in flight lets these activities overlap.

3:21 Our workbench is starting to behave like a production line. Careful with that overlap, though. A calculation can't use data that hasn't arrived. Parallel stages need synchronization when one

3:31 depends on another's data. Picture a ready signal on each tray. Work can overlap, but the next stage still needs its inputs. Together those storage levels form a memory hierarchy.

3:42 Overlapping the stages is called pipelining. You've already watched both at work. Tiles move between storage levels and incoming data gets prepared while another set is involved in

3:52 calculation. Seen this way. Deepseek's contribution is easier to pin down. Its original deep gem is a CUDA kernel library. For ascend, it supplies implementations that handle the layouts

4:02 and data movement we followed. A relatively familiar interface has substantial engineering underneath it. For matrix multiplication, the library supports several number formats. BF16

4:13 uses 16 bits, FP8 uses 8 and FP4 uses four. Beyond that, MQA logits handles attention scores in multi-query attention and megae serves mixture of experts models. Supporting these

4:27 specific operations doesn't establish that a whole application has moved. Coverage has a specific gap too. Although the Redmi claims full API compatibility, the implementation

4:37 explicitly marks masked grouped matrix multiplication interfaces as unimplemented. Familiar entry points help, but you still need to check which operations your application actually

4:46 calls before planning a move. Check the target environment as well. According to the repository development and validation use the Ascend 950 series, you'll need CAN 9.20 and torch npu.

4:59 Those requirements come before any performance discussion. A familiar function name is doing a lot of public relations here. Calling code gets a recognizable doorway which helps. Walk

5:09 through it though and data preparations, supported operations and required software still determine whether your application can use what's behind it. Beyond that doorway, CUDA covers

5:19 compilers, runtime and driver interfaces, mathematical libraries, debugging tools, and profilers. Our matrix kernel occupies one part of that platform. Replacing it still leaves the

5:30 surrounding software to account for when you move an application. Hay's CAN provides Ascend's broader platform including compiler support, runtime interfaces, operator and communication

5:40 libraries and analysis tools. So CAN is the more useful comparison with CUDA. Deep Gem Ascend sits inside that wider environment supplying particular operations an application can use. As a

5:51 developer, you need more than one successful calculation. You've got to build the application, use its supporting libraries, inspect problems, and work out where execution time goes.

6:01 Compilers, debugging tools, and profilers help you do those jobs around the kernel. Years of engineering have also built up around CUDA. NVIDIA's historical ecosystem account describes

6:11 application ports, partner libraries, language integrations, and deployment tools. Alongside that history, its current documentation shows how much software developers have available

6:21 around the calculations themselves. Changing kernels may be only part of the move. A team may also need to replace integrations and learn different tools. CUDA's accumulated software helps

6:31 explain why switching can take work, but these sources don't tell us how much work any particular team would face. A reusable library can take on some of that work. If it covers an operation

6:41 your application needs, you may be able to use its implementation instead of writing the machinery for this chip yourself. Multiple applications can draw on the same engineering. to reuse it.

6:52 Your required operations need coverage. Your data needs to fit the interface and your environment needs the required software. Meeting those conditions could reduce migration work. How much time a

7:02 team would save isn't established by this release. On performance, Deepseek reports selected dense matrix multiplication results approaching its stated hardware ceiling. Measurements

7:12 use ascend 950DT, CAN 9.20, and cold L2 profiling. Keep the attribution attached. These are deepseeks figures, not independently reproduced measurements. Read those results at the

7:24 scale they measure, selected kernels under stated conditions. They don't establish a matched win against an Nvidia system or the throughput of a whole model. Each comparison would need

7:34 measurements that cover the software involved. To judge your application, measure its actual workload with the surrounding software included. For a developer considering ascend, I'd start

7:43 by mapping the operations the application needs. match them against the library's coverage, including the explicitly unimplemented interfaces. Then check the expected layouts and

7:53 software requirements before planning how to move the rest. Next comes measuring the workload you actually care about. A benchmark table can't attend your integration meeting for you. You

8:03 need to know how this implementation behaves inside your application with its required operations and surrounding software under conditions that make the comparison meaningful across

8:12 applications. Reusable engineering is the promising part. Layout conversion, operand reuse, and coordinated loading don't have to become separate projects every time. A maintained implementation

8:23 can handle that machinery for applications whose operations it covers, giving developers work they can build on. Broader adoption still needs coverage, dependable tooling, and

8:32 measured application performance. Deep Gem Ascend contributes to that effort, but its implementation and documented validation concern Huawei Ascend specifically. This release doesn't

8:42 establish a universal software layer for other chip vendors. Return to our original switch. Beneath a familiar call, the implementation repack supporting data, moves tiles through

8:52 different storage levels, reuses inputs, and synchronizes stages. Asking for the same mathematical result doesn't tell a different chip how to organize all that work. My verdict for developers

9:02 evaluating Huawei Ascend, Deep Gem Ascend is worth evaluating for the operations it supports. Judge it inside your application where reusable machinery could take some migration work

9:12 off your plate. Which parts of your workload would still need their own implementation?