Please, Translate the following English into Korean: 
So, smooth quant makes the weight and activation into 8-bit. By smoothing the activations, pushing the quantization difficulty from the activation to the weight, improving the throughput for large language model. What about the batch size is small in the edge scenario or real-time interaction, like you want to talk to a robot, one-to-one conversation. When the batch size is small, we observe this is the real flying model. The x-axis is the compute intensity. The y-axis is the measured Tops per second. When the batch size is one, there is actually a pretty low utilization. This is your peak Tops per second. This is the measured Tops per second. It's very underutilized because it's highly memory-bounded. Because large language models are pretty big, like LAMA2-7b has 7 billion parameters. If you're using FP16, how many storage do you need? That's 14 gigabytes. That's pretty big. You have to fetch 14 gigabytes in an autoregressive manner, which means generating each token requires 14 gigabytes. So, it's a very high memory access. Remember, computation is cheap. Memory is expensive. We want to reduce those memory footprints. Compared with the weight, the activation is actually small. So the weight is 4K by 4K, but the activation, if it's a single batch, is 1 by 4K. It's a thousand times smaller. Therefore, we should focus on compressing the weight. That's why we introduced the memory. We should focus on compressing the weight. We should focus on this low-bit, weight-only quantization. We're also going to see that in the homework. So that's why we need such weight-only quantization, to reduce the memory bandwidth. Previously we had to fetch 14 gigabytes of memory. What about if we quantize the weight to 4-bit for LAMA7b? What is the memory footprint now? Three and a half. Three and a half. Three and a half gigabytes. Four times smaller. So this is naively doing that. This is a weight matrix. So using the IP16 representation, the four 8 by 4 matrix. This is the quantized version. It's again 8 by 4, but it's quantized using 3-bit, in this case, for easy to show it. But immediately we see it's perplexity degradation. The lower the perplexity, the better the quality. But here, unfortunately, there's a huge job of the perplexity, if we naively quantize it. Perplexity is a measurement of the quality of a language model. It's showing the accuracy of predicting the next word, whether you're accurately predicting the next word or not. So the lower, the better. So, unfortunately, you're actually doing to run to the nearest conspiracy to complete to a root del Mu, becauseứs andu a not exactly read each other, which is the biggest problem in computationandra mirroring the choice of theativity domain. All of the errors I gave are done byately. to nearest quantization using 3-bit hurt the accuracy a lot. Even if we're using this groupwise quantization, so here every 128 numbers are quantized together, and we have a shared scaling factor, a finer granularity of shared scaling factor every 128 elements, which we covered in the second lecture of this quantization part. Interestingly, we find not all the weights are equally important. Just by quantizing 1%, keep 1% of the rows in FP16, it helps a lot, immediately bring back the perplexity to the original value. This is so amazing, we seem to find a way to quantize that, right? Only keep 1% into FP16. Like here. Only one channel, keep it the same as before, just don't quantize it. Immediately bring back the perplexity, the quality. So therefore, we have two natural to-dos. One to-do is to think about how do we choose those salient channels, which channel is important. They exist, but the channel is only 1% of the channel. But how do we systematically, systematically select those 1% of the channels? The second to-do is, keeping FP16 will make the inference kernel difficult. How do we get rid of this mix of precision and still use full quantization? Everything will be in blue rather than having 1% in yellow. So let's answer those two questions. When we are doing pruning, how do we select these important weights? Which one to prune, which one to remove? We look at the weight itself, right? If it is large, we think, oh, that's an important weight, important channel, we should keep it. What if we do it here? We keep the weight. If it is large, we just keep it, otherwise we remove it. Unfortunately, the perplexity is pretty high. And we did it another way. Don't look at the weight. Since weight is multiplied with the activation. Let's look at those activations. Since during smooth quant we find some activations are pretty huge, we want to preserve those outlier channels. So say this is an outlier channel. This is a pretty big activation channel. And that is consistent for different inputs, different tokens. They are all big channels. And then, if this channel is big in the activation, this corresponding weight is considered salient or important. We should keep them. So using this way, activation, not the weight, that's why we call it activation-aware weight-only quantization. We are quantizing the weight. But you look at the activation to determine which weight is salient. By looking at the activation's magnitude, it's easier. To recover the perplexity. So we solve the first to-do. Look at the activation. Not the weight. To determine those 1% salient channel. Then we have the second to-do. Right? Can we not rely on this mixed precision? Still use all int 4 or all int 3 to get rid of this mixed precision. We tried a very simple technique. We just multiply this weight channel by 2 and divide the activation channel by 2. So they are mathematically equal, like smooth quant. So by multiplying it from 1.5, 2, and 4, we find this is a very effective way to recover the perplexity. Without introducing this Fp16, 1% of channels in Fp16, just multiply that salient channel by a number larger than 1 and bring back this perplexity. This is so amazing. Previously, we had to rely on 1% of the channels being unquantized in Fp16, making the kernel difficult to write. But now, just multiply the salient channel by a larger number, and it will recover. Another problem came up. How large should we multiply that channel? Here you see the perplexity decrease and the increase. There must be a sweet spot. We want to automatically search the multiplier. So let's analyze first, why enlarging the channel makes it easier to recover the perplexity? So this layer is the perplexity. So this layer is denoted by weight times deactivation. And then we care about the quantization error from the quantized variant of the W times x. So QW, the quantized variant of W, basically equal to, this is defining the range. We divide the range by the number of centroids. Since we have n bits, they are to the power of n minus 1, so we have n centroids. And this is the distance between each centroid. And then we give W divided by this number and multiply this number to the outside. And we have to round it to the nearest integer. So that's the quantized variant of W. What if we scale that? Like here, we scale it by 1.5, by 2, for those salient weights. What happens to that? We scale up the weight, and we have to scale down the activation. Previously, QW times x, now it's QW times s, times x divided by s. So they are still mathematically equal. s gets cancelled here. If we plug in Ws into the representation for the Q, we can see sw is here. Since W becomes sw. And x divided by s is here. What happens here is that the rounding function always has an expectation of 0.25. Since the rounding error ranges from 0 to 0.5. Like 1.5 gets rounded to 2, 1.75 gets rounded to 2 as well. The average is 0.25, it's a quarter. Since it's between 0 and 0.5. So this doesn't change. What about this delta? This delta is only dependent on the maximum of the weight. There are a group of weights in the vertical dimension. The group size is 128. Just scale up one channel, it's very unlikely to change the maximum value. Unless 1 in 125, 128, you hit that max value. Otherwise you are not going to change it. So this delta is not going to change. But only this s is something, s is larger than 1, so this error is scaled down. So when the s is greater than 1, the error is scaled down. That's why scaling up the salient channel can achieve the same effect of making that channel to be FP16. So one question about the scaling up. Is this scaling up after the quantization or before? Before the quantization. So it's easier to quantize. So we scaled it up. And then the equation is very similar to smooth quant. Make it easy for industry to put into products. Same infrastructure. You can do either smooth quant or AWQ. So here we times, W times s, x divided by s. This can be fused to the previous operation. Or fused into the layer norm. And then we take a data-driven approach to do a fast grid search. To search the best scaling factor, which is greater than 1. And later follow-up work even proposed a learning-based method to use gradient descent to learn the best scaling factor. So this is 3-bit group size 128 on LAMA. And also LAMA 2. AWQ shows consistent better performance compared with surround-to-nearest or GPT-Q or GPT-QR. Like 7B all the way to 30B models. It also works well for multi-model and large language model, which we're going to introduce in the next lecture on region transformers. So this is Flamingo image captioning. This is comparison with different baselines. Actually pretty significant improvement about the accuracy here. Given this image, the round-to-nearest baseline quantization model says a model airplane is flying in the sky. AWQ can say two toy airplanes sitting on a grass field. This one baseline model is saying a man is holding a gun and a baby elephant in his arm. Versus AWQ says a man and his daughter pose with an elephant. The last one, a man and a dog walking past some bushes. Versus AWQ, two dogs are working on the street. It can even use LAMA, quantized LAMA, to do visual reasoning. Like given this, there is some caption here, but this is all represented in the image format, although it has some text. You have to automate it to do OCR to understand it. Some chicken, like a world map. The baseline quantization RTM model says there are small pictures of the Earth and other planets placed on top of the food. Versus AWQ says a lighthearted and humorous take on the concept of looking at the pieces of the Earth from space. A plate of fried food, especially chicken nuggets, is presented with the caption, and the caption is actually exactly the same as the caption here. So it means this vision language model is automatically doing the OCR to understand the text here. One more example, able to recognize this, who is painting this, Leonardo da Vinci. Okay, so smooth quant and AWQ are widely used these days. That's why we also put it in the homework in the lab four, which we released last week. We give you the code, and also it will pave the way for lab five, which we are going to actually implement that on a laptop. Omidia, FASR Transformer, and TensorFlow RTLM, this is the library run large language model inference, which is actually a pretty amazing library, released actually last week. How amazing, how timely we are. TensorFlow RTLM, they are using the smooth quant and AWQ as their quantization approaches. Also Intel, who changed Berkeley's BLM, which we're going to talk about that, Berkeley Fast Chat, and Hugging Face, and SenseTime, and several open source community have been using that. Okay, so how do we translate these two concepts? So the first one is, how do we translate this theoretical saving into measured speedup? And can we deploy this large language model on edge devices, like on our laptops, our phones? Okay, so I'm going to introduce TinyChat, which is a lightweight chatbot for large language model on the edge. This is what we designed, 3D printed computer, which has an ORI Nano inside. And we also have a demo here on the right. So deploying large language model on the edge is quite useful. For example, you run CodePilot locally on your edge device, code completion, office, game chat, especially coding. Enterprise data is privacy sensitive, you don't want to upload to the cloud. But these devices are very resource constrained. Here is only a small JSON ORI Nano, resource constrained, low power, and also do not have access to the internet always. Privacy is important. Okay. So here is our TinyChat computer. It can ask you questions, and also scroll up to see the previous answers. So basically, TinyChat implements this 4-bit compressed A to the Q model. The weight is 4-bit to save the memory footprint. And here we are doing running it on different laptops. This is running the CodeLama, writing code using CodeLama. Pretty fast. And this is comparing MIT, Harvard, used to give it different prompts. Blazing fast. After Lab 4, you are going to implement something similar on your laptop. On Lab 5. And feel free to continue improving that and pushing to the code base. TinyChat engine is a very complex final project, which is open-ended. But this could be one of the choices. And a key technique to enable such fast inference is algorithm and system co-design. So on the algorithm side, 4-bit AWQ quantization. On the system side, is the Tiny Engine technique, parallel computing techniques. We introduced loop-by-routing, blocking, cache locality, right? And also multi-threading, CUDA programming, different techniques. And also how do we lay out the 4-bit weight in memory and run time decoded from 4-bit to 16-bit to avoid this decoding overhead. That is also one of the key techniques to make it run fast. This is comparing on the 1490 GPU without and with AWQ. How fast, how far, how much speed up we can get. So the FP16 version is showing both the weight and activation in FP16. So that's 50 tokens per second running on 1490 GPU. This is the AWQ version. The weight is only 4-bit. Activation is still 16-bit. Since this is the memory bottleneck, not the activation. So we keep activation in FP16 to preserve the accuracy. And we run time decode the weight from int4 by FP16 and do the arithmetic in FP16. Since computing is cheap, memory footprint is expensive. This is exactly the way we did in the efficient inference engine in ISCA 16. Now this method reborn and proved to be quite helpful to accelerate this large language model for real-time inference. This one already finished. This one is still slowly making progress. TinyChat is also flexible, support a lot of different large language models like MPT7B by Nozick, Falcon7B, and also Vicuna7B. It can also run the 13B parameter model on a MacBook. Even on a JSON-ORI, which is a mobile GPU, 30 tokens per second running on LAMA2.