<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>Hoijun Kim</title><description>Notes on building desktop developer tools in Go - what shape and fleet are made of, and what broke along the way.</description><link>https://hoijunkim.github.io/</link><item><title>얕은 스택은 상한을 다 쓴다</title><link>https://hoijunkim.github.io/blog/shallow-stacks-use-it-all/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/shallow-stacks-use-it-all/</guid><description>12편은 상한을 늘려도 쓸 수 있는 거리가 안 는다고 했다. 층을 둘셋으로 줄여 보니 그 구간에서는 상한을 한 자도 안 남기고 다 쓴다. 그리고 층을 4로 맞춰 다시 재니 12편이 그은 직선이 커널 3 에서 1.5 자 어긋난다 - 깊이가 섞인 점을 커널 축에 올렸었다.</description><pubDate>Fri, 30 Jan 2026 00:00:00 GMT</pubDate><language>ko</language></item><item><title>Shallow stacks use the whole bound</title><link>https://hoijunkim.github.io/blog/en/shallow-stacks-use-it-all/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/shallow-stacks-use-it-all/</guid><description>Part twelve found that raising the receptive-field bound does not raise the distance a CNN can use. Cut the depth to two or three layers and the whole bound gets used, with nothing left over. And matching the depth at four exposes an error: part twelve&apos;s line put depth-mixed points on a kernel axis, and kernel 3 sits 1.5 characters below it.</description><pubDate>Fri, 30 Jan 2026 00:00:00 GMT</pubDate><language>en</language></item><item><title>층을 쌓아도 안 늘었다</title><link>https://hoijunkim.github.io/blog/stacking-layers-added-nothing/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/stacking-layers-added-nothing/</guid><description>11편이 남긴 &apos;왜 12인가&apos; 를 여섯 구성으로 쟀다. 커널 5 는 층이 4든 6든 8이든, 수용장 상한이 16이든 24든 32든 정확히 12에서 끊긴다. 세워 둔 후보 두 개가 다 틀렸고, 실제로 늘어나는 것은 커널을 키울 때뿐이다.</description><pubDate>Sat, 24 Jan 2026 00:00:00 GMT</pubDate><language>ko</language></item><item><title>Stacking layers added nothing</title><link>https://hoijunkim.github.io/blog/en/stacking-layers-added-nothing/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/stacking-layers-added-nothing/</guid><description>Part eleven&apos;s open question - why 12 - measured across six configurations. Kernel 5 breaks at exactly 12 whether it has 4, 6 or 8 layers and whether its receptive-field bound is 16, 24 or 32. Both candidate explanations were wrong, and the only thing that extends the usable distance is a wider kernel.</description><pubDate>Sat, 24 Jan 2026 00:00:00 GMT</pubDate><language>en</language></item><item><title>어디서부터 못 하나</title><link>https://hoijunkim.github.io/blog/where-it-starts-failing/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/where-it-starts-failing/</guid><description>복사 거리를 2에서 60까지 바꿔 가며 다섯 구조를 같은 규약으로 돌렸다. RNN 은 4와 8 사이, LSTM 은 8과 16 사이에서 끊긴다. CNN 은 수용장이 17인데 거리 12까지만 풀고, 왜 그런지에 대한 내 설명은 세워 보자마자 반증됐다.</description><pubDate>Sun, 18 Jan 2026 00:00:00 GMT</pubDate><language>ko</language></item><item><title>Where it starts failing</title><link>https://hoijunkim.github.io/blog/en/where-it-starts-failing/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/where-it-starts-failing/</guid><description>Five architectures run under one protocol with the copy distance swept from 2 to 60. The RNN breaks between 4 and 8, the LSTM between 8 and 16. The CNN has a receptive field of 17 but only solves up to distance 12, and my explanation for why was refuted as soon as I set it up.</description><pubDate>Sun, 18 Jan 2026 00:00:00 GMT</pubDate><language>en</language></item><item><title>과제를 바꾸니 순서가 뒤집혔다</title><link>https://hoijunkim.github.io/blog/changing-the-task-inverted-it/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/changing-the-task-inverted-it/</guid><description>2편·5편·8편이 세 번 같은 단서를 달았다 - 이 결론은 앞쪽 글자가 안 중요한 과제에 붙어 있다고. 그래서 반드시 필요한 과제를 만들었다. 트랜스포머가 0.0002 로 완전히 풀고 RNN·LSTM·CNN 은 찍기에서 한 발도 못 움직인다.</description><pubDate>Mon, 12 Jan 2026 00:00:00 GMT</pubDate><language>ko</language></item><item><title>Changing the task inverted the order</title><link>https://hoijunkim.github.io/blog/en/changing-the-task-inverted-it/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/changing-the-task-inverted-it/</guid><description>Parts two, five and eight each attached the same caveat - this conclusion belongs to a task where the front of the sequence hardly matters. So here is one where it must. The transformer solves it outright at 0.0002 while RNN, LSTM and CNN never move off chance.</description><pubDate>Mon, 12 Jan 2026 00:00:00 GMT</pubDate><language>en</language></item><item><title>걸음으로 견준 것이 트랜스포머에 유리했다</title><link>https://hoijunkim.github.io/blog/steps-favoured-the-transformer/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/steps-favoured-the-transformer/</guid><description>7편이 남긴 빚을 갚는다. 재귀는 순서대로 가야 하니 느릴 줄 알았는데 LSTM 이 트랜스포머의 0.82배다. 순차성의 값은 융합 커널이 숨기고 있었고, 트랜스포머를 비싸게 만드는 것은 걸음당 값이 아니라 걸음 수였다.</description><pubDate>Tue, 06 Jan 2026 00:00:00 GMT</pubDate><language>ko</language></item><item><title>Comparing by steps favoured the transformer</title><link>https://hoijunkim.github.io/blog/en/steps-favoured-the-transformer/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/steps-favoured-the-transformer/</guid><description>Paying off part seven&apos;s debt. Recurrence goes in order, so it should be the slow one - and the LSTM comes in at 0.82 times the transformer. The cost of being sequential is there, hidden by a fused kernel, and what makes the transformer expensive is the number of steps rather than the price of one.</description><pubDate>Tue, 06 Jan 2026 00:00:00 GMT</pubDate><language>en</language></item><item><title>기울기를 멀리 보내면 손실이 나빠졌다</title><link>https://hoijunkim.github.io/blog/further-gradient-worse-loss/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/further-gradient-worse-loss/</guid><description>마지막 자리의 손실이 뒤로 몇 자까지 닿는지 다섯 구조에서 쟀다. 게이트는 도달을 거의 안 늘린다 - 파이토치 망각 게이트 바이어스가 0 이라 걸음마다 절반이 죽기 때문이다. 열면 문맥 전체에 닿는데, 그러면 손실이 단조롭게 나빠진다.</description><pubDate>Wed, 31 Dec 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>Sending the gradient further made the loss worse</title><link>https://hoijunkim.github.io/blog/en/further-gradient-worse-loss/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/further-gradient-worse-loss/</guid><description>How far back the loss at the last position reaches, measured for five architectures. Gates barely extend it - PyTorch starts the forget gate at bias 0, so half the signal dies every step. Open it and the gradient reaches the whole context, and the loss gets monotonically worse.</description><pubDate>Wed, 31 Dec 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>같은 예산이면 GRU 가 이긴다 - 700걸음 동안만</title><link>https://hoijunkim.github.io/blog/same-budget-gru-wins/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/same-budget-gru-wins/</guid><description>앞 시리즈 13편의 트랜스포머와 같은 파라미터 예산, 같은 코퍼스, 같은 최적화로 RNN·LSTM·GRU·1D 합성곱을 학습했다. GRU 의 최저 검증 손실 1.6449 가 트랜스포머의 1.7679 를 이긴다. 그런데 앞서는 구간이 500걸음에서 1200걸음까지뿐이고, 4000걸음에서는 3.4170 으로 무너진다.</description><pubDate>Thu, 25 Dec 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>At the same budget the GRU wins - for 700 steps</title><link>https://hoijunkim.github.io/blog/en/same-budget-gru-wins/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/same-budget-gru-wins/</guid><description>RNN, LSTM, GRU and a 1D causal CNN trained on the same corpus with the same parameter budget and optimiser as the transformer from the previous series. The GRU&apos;s best validation loss, 1.6449, beats the transformer&apos;s 1.7679. But it only leads between steps 500 and 1200, and by step 4000 it has collapsed to 3.4170.</description><pubDate>Thu, 25 Dec 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>풀링은 위치 3비트를 버린다</title><link>https://hoijunkim.github.io/blog/pooling-throws-away-position/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/pooling-throws-away-position/</guid><description>풀링이 사는 것과 내는 것을 따로 쟀다. 창 8이면 한 글자 밀어도 표현이 1.16 에서 0.22 로 덜 바뀌는 대신, 창 안 어느 자리였는지 3.00비트를 통째로 버린다. 다음 글자 맞히기에서는 그 거래가 손해다.</description><pubDate>Fri, 19 Dec 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>Pooling throws away three bits of position</title><link>https://hoijunkim.github.io/blog/en/pooling-throws-away-position/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/pooling-throws-away-position/</guid><description>What pooling buys and what it spends, measured separately. At window 8 a one-character shift moves the representation 0.22 instead of 1.16 - and the price is 3.00 bits saying which position inside the window won. For next-character prediction that trade loses.</description><pubDate>Fri, 19 Dec 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>창을 공짜로 넓혔더니 나빠졌다</title><link>https://hoijunkim.github.io/blog/wider-window-worse/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/wider-window-worse/</guid><description>합성곱의 수용장을 17자에서 125자까지 넓혀 같은 예산으로 학습시켰다. 넓힐수록 손실이 오른다. 파라미터도 채널도 층도 그대로 두고 팽창으로만 17을 61로 넓힌 경우조차 0.10 나빠진다 - 팽창은 넓히는 게 아니라 성기게 하기 때문이다.</description><pubDate>Sat, 13 Dec 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>Widening the window for free made it worse</title><link>https://hoijunkim.github.io/blog/en/wider-window-worse/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/wider-window-worse/</guid><description>The convolution&apos;s receptive field taken from 17 characters to 125 at the same budget. Wider is worse throughout. Even holding parameters, channels, depth and kernel fixed and widening from 17 to 61 by dilation alone costs 0.10 - because dilation does not widen so much as thin.</description><pubDate>Sat, 13 Dec 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>첫 층 커널이 배운 것은 줄 끝이었다</title><link>https://hoijunkim.github.io/blog/kernels-learned-line-endings/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/kernels-learned-line-endings/</guid><description>합성곱은 상태를 이고 가지 않는다. 자리마다 다섯 글자를 보는 커널 하나가 미끄러질 뿐이다. 학습된 첫 층에서 채널마다 제일 크게 반응하는 다섯 글자를 찾아 보면, 개행·소수점·백틱·쉼표를 잡는 것들이 나온다.</description><pubDate>Sun, 07 Dec 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>What the first-layer kernels learned was line endings</title><link>https://hoijunkim.github.io/blog/en/kernels-learned-line-endings/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/kernels-learned-line-endings/</guid><description>A convolution carries nothing along. One kernel reads five characters at a position and slides. Searching the trained first layer for the five characters each channel responds to most turns up detectors for newlines, decimals, backticks and commas.</description><pubDate>Sun, 07 Dec 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>게이트 하나를 없앤 쪽이 이겼다</title><link>https://hoijunkim.github.io/blog/gate-removed-won/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/gate-removed-won/</guid><description>GRU 는 LSTM 의 입력 게이트와 망각 게이트를 하나로 묶는다. 묶어도 되는 이유가 LSTM 이 원래 둘을 안 따로 쓰기 때문일 거라 봤는데, 재 보니 따로 쓴다 - 상관 0.071. 그런데도 진다. 같은 폭에서 파라미터를 23% 덜 쓰고도 GRU 가 앞선다.</description><pubDate>Mon, 01 Dec 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>The one with a gate removed won</title><link>https://hoijunkim.github.io/blog/en/gate-removed-won/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/gate-removed-won/</guid><description>A GRU merges the LSTM&apos;s input and forget gates into one. The obvious reason that would be safe is that the LSTM does not really use them separately - measured, it does, at a correlation of 0.071. And it still loses: matched on width, with 23% fewer parameters, the GRU is ahead.</description><pubDate>Mon, 01 Dec 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>게이트를 꺼내 보니 망각 게이트가 안 움직였다</title><link>https://hoijunkim.github.io/blog/pulling-out-the-gates/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/pulling-out-the-gates/</guid><description>LSTM 이 무엇을 여닫는지 학습된 가중치에서 직접 꺼낸다. 망각 게이트 평균이 0.495 로 초기값 sigmoid(0)=0.5 에서 거의 안 움직였고, 유닛 325개 중 반감기가 3자를 넘는 것이 하나도 없다. 그런데 상태는 그보다 오래 기억한다.</description><pubDate>Tue, 25 Nov 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>Pulling the gates out, the forget gate had barely moved</title><link>https://hoijunkim.github.io/blog/en/pulling-out-the-gates/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/pulling-out-the-gates/</guid><description>Reading what an LSTM opens and closes straight out of the trained weights. The forget gate averages 0.495, essentially the sigmoid(0) = 0.5 it started at, and not one of the 325 units holds anything longer than three characters. Yet the state remembers longer than that.</description><pubDate>Tue, 25 Nov 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>재귀 한 걸음이 하는 계산</title><link>https://hoijunkim.github.io/blog/one-recurrent-step/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/one-recurrent-step/</guid><description>은닉 상태 하나로 글을 읽는다는 게 무슨 뜻인지 열어 본다. 파라미터 63만 개 중 73%가 상태를 상태로 옮기는 행렬 하나에 있고, 683개 유닛 중 546번은 띄어쓰기를 볼 때마다 켜진다. 그리고 글자 하나를 바꾸면 네 자 만에 절반이 사라진다.</description><pubDate>Wed, 19 Nov 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>What one recurrent step computes</title><link>https://hoijunkim.github.io/blog/en/one-recurrent-step/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/one-recurrent-step/</guid><description>Opening up what it means to read text with a single hidden state. 73% of the 637k parameters sit in the one matrix that carries state to state, unit 546 of 683 switches on at every space, and changing one character leaves half its trace gone four characters later.</description><pubDate>Wed, 19 Nov 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>꼬리를 재니 12편의 k=8 이 47% 나쁘다</title><link>https://hoijunkim.github.io/blog/measuring-the-tail/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/measuring-the-tail/</guid><description>12편은 처리량으로 k=8 을 골랐다. 글자 사이 간격의 p99 를 재면 k=8 은 8.21ms 로 k=1 의 5.57ms 보다 47% 나쁘다. 12편이 이름만 대고 넘어간 프리필 조각내기도 재 봤는데, 프론티어 여섯 점 중 둘뿐이었다.</description><pubDate>Thu, 13 Nov 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>Measuring the tail put part twelve&apos;s k=8 47% behind</title><link>https://hoijunkim.github.io/blog/en/measuring-the-tail/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/measuring-the-tail/</guid><description>Part twelve picked k=8 on throughput. Measured on inter-token p99, k=8 sits at 8.21ms against k=1&apos;s 5.57ms - 47% worse. Prefill chunking, which part twelve named and left alone, turns out to hold two of the six points on the frontier.</description><pubDate>Thu, 13 Nov 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>프리필을 세니 1.56배가 1.22배가 됐다</title><link>https://hoijunkim.github.io/blog/counting-the-prefill/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/counting-the-prefill/</guid><description>9편부터 11편까지 스케줄을 견주면서 디코드 스텝만 셌다. 프롬프트를 밀어 넣는 값을 넣으면 연속 배치의 이득이 절반으로 준다 - 자리가 하나씩 나는 탓에 프리필을 8번이 아니라 144번 나눠 내기 때문이다.</description><pubDate>Fri, 07 Nov 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>Counting the prefill turned 1.56x into 1.22x</title><link>https://hoijunkim.github.io/blog/en/counting-the-prefill/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/counting-the-prefill/</guid><description>Parts nine through eleven compared schedules by counting decode steps only. Add the cost of pushing the prompt in and continuous batching&apos;s advantage halves - because slots free one at a time, it splits prefill into 144 calls instead of 8.</description><pubDate>Fri, 07 Nov 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>메모리를 1.6배 아끼고 시간을 1.7배 잃었다</title><link>https://hoijunkim.github.io/blog/blocks-saved-memory-not-time/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/blocks-saved-memory-not-time/</guid><description>10편은 조밀한 캐시 텐서의 길이를 제일 긴 행이 정한다는 데서 끝났다. 고정 크기 블록으로 쪼개면 최대 할당이 4,064에서 2,560 슬롯으로 준다. 그런데 흩어진 블록을 모아 오는 값이 아낀 것보다 컸다.</description><pubDate>Sat, 01 Nov 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>Saved 1.6x the memory, lost 1.7x the time</title><link>https://hoijunkim.github.io/blog/en/blocks-saved-memory-not-time/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/blocks-saved-memory-not-time/</guid><description>Part ten ended with a dense cache tensor sized by its longest row. Cutting it into fixed-size blocks takes the peak allocation from 4,064 slots to 2,560. Then gathering the scattered blocks cost more than the padding it removed.</description><pubDate>Sat, 01 Nov 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>빈 자리를 채웠더니 캐시가 길어졌다</title><link>https://hoijunkim.github.io/blog/filling-the-seat-cost-cache/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/filling-the-seat-cost-cache/</guid><description>9편은 길이순 정렬로 패딩 낭비를 47%에서 0.7%로 줄였다. 그 트릭은 생성 길이에는 안 통한다 - 미리 알 수가 없다. 연속 배치가 그 자리를 채우지만, 채운 대가로 어텐션이 읽는 캐시가 길어진다.</description><pubDate>Sun, 26 Oct 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>Filling the empty slot made the cache longer</title><link>https://hoijunkim.github.io/blog/en/filling-the-seat-cost-cache/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/filling-the-seat-cost-cache/</guid><description>Part nine sorted by length and took padding waste from 47% to 0.7%. That handle does not turn here, because generation length cannot be known in advance. Continuous batching fills the slot instead - and pays for it in the cache attention has to read.</description><pubDate>Sun, 26 Oct 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>패딩 낭비는 배치 문제가 아니었다</title><link>https://hoijunkim.github.io/blog/waste-cut-time-not/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/waste-cut-time-not/</guid><description>5편은 요청 길이가 흩어지면 패딩 낭비가 50%로 수렴한다고 쟀다. 그 숫자는 요청을 온 순서대로 묶는다는 전제 위에 있었다. 순서를 바꿀 수 있으면 낭비를 정하는 것은 배치 크기가 아니라 몇 개나 모아 뒀느냐다.</description><pubDate>Mon, 20 Oct 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>Padding waste was never about the batch</title><link>https://hoijunkim.github.io/blog/en/waste-cut-time-not/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/waste-cut-time-not/</guid><description>Part five measured padding waste converging on 50% once request lengths spread out. That number rested on taking requests in the order they arrive. Allow reordering and what sets the waste is not the batch size but how many are pooled.</description><pubDate>Mon, 20 Oct 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>0을 아무리 많이 만들어도 빨라지지 않는다</title><link>https://hoijunkim.github.io/blog/no-amount-of-zeros/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/no-amount-of-zeros/</guid><description>3편은 가중치를 int8 로 뭉갰다. 이번에는 아예 0으로 만든다. 어느 것을 0으로 만드느냐가 전부를 가르고, 같은 압축률에서 양자화에 진다. 그리고 99%를 0으로 만들어도 시간은 그대로다.</description><pubDate>Tue, 14 Oct 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>No amount of zeros makes it faster</title><link>https://hoijunkim.github.io/blog/en/no-amount-of-zeros/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/no-amount-of-zeros/</guid><description>Part three flattened the weights into int8. This sets them to zero instead. Which ones get zeroed decides everything, quantisation wins at every compression ratio, and zeroing 99% of them changes the clock not at all.</description><pubDate>Tue, 14 Oct 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>읽는 글자와 쓰는 글자의 값이 40배 다르다</title><link>https://hoijunkim.github.io/blog/read-and-write-cost-differently/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/read-and-write-cost-differently/</guid><description>같은 모델, 같은 가중치인데 프롬프트를 읽을 때와 글자를 뽑을 때의 글자당 값이 40배 차이 난다. 5편의 a 와 b 로 그 이유가 설명되고, 서빙 시스템이 두 단계를 왜 갈라 놓는지도 같이 나온다.</description><pubDate>Wed, 08 Oct 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>A character read costs a fortieth of one written</title><link>https://hoijunkim.github.io/blog/en/read-and-write-cost-differently/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/read-and-write-cost-differently/</guid><description>Same model, same weights, and reading a prompt costs 40 times less per character than producing one. Part five&apos;s a and b explain it, and so does why serving systems name the two phases separately.</description><pubDate>Wed, 08 Oct 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>캐시를 자르면 맨 앞을 남겨야 한다</title><link>https://hoijunkim.github.io/blog/cut-the-cache-keep-the-beginning/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/cut-the-cache-keep-the-beginning/</guid><description>2편에서 캐시가 가중치보다 커졌다. 오래된 것부터 버리면 되는데, 무엇을 남기느냐가 결과를 가른다. 맨 앞 여덟 자리를 남기면 캐시의 19% 로 전체와 거의 같은 손실이 나온다.</description><pubDate>Thu, 02 Oct 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>Cut the cache and keep the beginning</title><link>https://hoijunkim.github.io/blog/en/cut-the-cache-keep-the-beginning/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/cut-the-cache-keep-the-beginning/</guid><description>Part two ended with the cache larger than the weights. Dropping the oldest entries is the obvious fix, and what gets kept decides the outcome. Keeping the first eight positions runs at 19% of the cache for almost the full-cache loss.</description><pubDate>Thu, 02 Oct 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>배치 하나에 96%가 낭비였다</title><link>https://hoijunkim.github.io/blog/ninety-six-percent-was-waste/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/ninety-six-percent-was-waste/</guid><description>2편에서 값을 치르던 것은 곱셈이 아니라 오버헤드였다. 그 몫이 정확히 얼마인지 재고, 배치를 키워 그것을 처리량으로 바꾼다. 대가는 지연이다.</description><pubDate>Fri, 26 Sep 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>96% of a batch of one was waste</title><link>https://hoijunkim.github.io/blog/en/ninety-six-percent-was-waste/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/ninety-six-percent-was-waste/</guid><description>Part two found that what was being paid for was overhead, not multiplication. This puts a number on that share and then converts it into throughput by batching. The price is latency.</description><pubDate>Fri, 26 Sep 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>초안이 좋을수록 느려졌다</title><link>https://hoijunkim.github.io/blog/the-better-draft-was-slower/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/the-better-draft-was-slower/</guid><description>투기적 디코딩은 싼 모델이 여러 글자를 미리 쓰고 비싼 모델이 한 번에 검사한다. 출력 분포가 정말 안 변하는지 재고, 수락률이 0.9 인 초안이 왜 0.29 인 초안에게 지는지 본다.</description><pubDate>Sat, 20 Sep 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>The better the draft, the slower it got</title><link>https://hoijunkim.github.io/blog/en/the-better-draft-was-slower/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/the-better-draft-was-slower/</guid><description>Speculative decoding has a cheap model write several characters ahead and an expensive one check them in a single pass. This measures whether the output distribution really survives, and why a draft with 0.9 acceptance loses to one with 0.29.</description><pubDate>Sat, 20 Sep 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>가중치를 4분의 1로 줄이면 무엇이 사라지나</title><link>https://hoijunkim.github.io/blog/quartering-the-weights/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/quartering-the-weights/</guid><description>2편의 캐시가 가중치보다 커졌다. 이번에는 가중치 쪽을 줄인다. float32 를 int8 로 바꾸면 손실이 0.0017 밖에 안 오르는데, 뽑은 글은 스물두 번째 글자에서 갈린다.</description><pubDate>Sun, 14 Sep 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>What disappears when the weights are quartered</title><link>https://hoijunkim.github.io/blog/en/quartering-the-weights/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/quartering-the-weights/</guid><description>Part two&apos;s cache outgrew the weights, so this attacks the weights. Going from float32 to int8 costs 0.0017 of loss - and the generated text diverges at the twenty-second character.</description><pubDate>Sun, 14 Sep 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>같은 계산을 n 번 반복하고 있었다</title><link>https://hoijunkim.github.io/blog/the-same-computation-n-times/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/the-same-computation-n-times/</guid><description>글자 하나를 뽑을 때마다 앞 문맥을 통째로 다시 계산한다. 캐시를 붙이면 산술이 130분의 1로 줄어드는데 실제 시간은 3배만 빨라진다. 그 격차가 어디서 오는지 잰다.</description><pubDate>Mon, 08 Sep 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>The same computation, n times over</title><link>https://hoijunkim.github.io/blog/en/the-same-computation-n-times/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/the-same-computation-n-times/</guid><description>Every character drawn recomputes the whole preceding context. Adding a cache cuts the arithmetic 130-fold and the wall clock only 3-fold, and this measures where that gap comes from.</description><pubDate>Mon, 08 Sep 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>모델은 다음 글자를 고르지 않는다</title><link>https://hoijunkim.github.io/blog/model-does-not-pick/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/model-does-not-pick/</guid><description>학습된 모델이 내놓는 것은 글자가 아니라 분포다. 고르는 일은 그 뒤에 따로 붙는 선택이고, 그 선택이 결과를 얼마나 바꾸는지 13편에서 만든 모델로 직접 잰다.</description><pubDate>Tue, 02 Sep 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>The model does not pick the next character</title><link>https://hoijunkim.github.io/blog/en/model-does-not-pick/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/model-does-not-pick/</guid><description>What a trained model emits is a distribution, not a character. Choosing is a separate rule bolted on afterwards, and this measures how much that rule changes the result using the model built in part thirteen.</description><pubDate>Tue, 02 Sep 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>63만 개짜리로 글자를 예측해 본다</title><link>https://hoijunkim.github.io/blog/predicting-characters-end-to-end/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/predicting-characters-end-to-end/</guid><description>열두 편의 부품을 다 이어 붙여 실제로 돌린다. 손실이 왜 ln(어휘수) 에서 시작하는지, 인과 마스크를 빼면 무슨 일이 벌어지는지, 그리고 헤드 하나가 무엇을 배웠는지 꺼내 본다.</description><pubDate>Mon, 25 Aug 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>Predicting characters with 637,156 parameters</title><link>https://hoijunkim.github.io/blog/en/predicting-characters-end-to-end/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/predicting-characters-end-to-end/</guid><description>Twelve parts of pieces, wired together and actually run. Why the loss starts at ln(vocabulary), what happens when the causal mask comes off, and what one head turned out to have learned.</description><pubDate>Mon, 25 Aug 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>블록을 96개 쌓아 보면 무엇이 무너지나</title><link>https://hoijunkim.github.io/blog/stacking-ninety-six-blocks/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/stacking-ninety-six-blocks/</guid><description>잔차 연결과 정규화 위치 중 무엇이 깊이를 버티게 하나. 6층부터 96층까지 쌓아 가며 층별 기울기를 재면, 둘의 무게가 같지 않다는 것이 숫자로 나온다.</description><pubDate>Wed, 20 Aug 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>What breaks when you stack 96 blocks</title><link>https://hoijunkim.github.io/blog/en/stacking-ninety-six-blocks/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/stacking-ninety-six-blocks/</guid><description>Between residual connections and where the norm goes, which one carries depth? Stacking from 6 blocks to 96 and measuring the gradient at every layer puts a number on it, and the two do not weigh the same.</description><pubDate>Wed, 20 Aug 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>파라미터의 3분의 2가 있는 층</title><link>https://hoijunkim.github.io/blog/two-thirds-of-the-parameters/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/two-thirds-of-the-parameters/</guid><description>트랜스포머 블록에서 어텐션이 아니라 피드포워드가 파라미터의 2/3 를 쓴다. 비선형을 빼면 4배 확장이 정확히 아무것도 사지 못한다는 것과, 폭이 실제로 무엇을 늘리는지 재 본다.</description><pubDate>Fri, 15 Aug 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>The layer holding two thirds of the parameters</title><link>https://hoijunkim.github.io/blog/en/two-thirds-of-the-parameters/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/two-thirds-of-the-parameters/</guid><description>In a transformer block it is the feed-forward, not attention, that spends 2/3 of the parameters. This measures why the 4x expansion buys exactly nothing without a nonlinearity, and what the width actually adds.</description><pubDate>Fri, 15 Aug 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>머리를 여덟으로 쪼개면 무엇이 달라지나</title><link>https://hoijunkim.github.io/blog/multi-head-what-splitting-buys/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/multi-head-what-splitting-buys/</guid><description>파라미터 수가 똑같은데 왜 헤드를 나누나. 평균 하나로는 두 가지를 못 나른다는 것을 재고, 헤드 하나에 걸린 랭크 상한이 실제로 무엇을 막는지 - 그리고 내가 처음에 그걸 어떻게 잘못 읽었는지 - 본다.</description><pubDate>Sun, 10 Aug 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>What splitting the head into eight actually changes</title><link>https://hoijunkim.github.io/blog/en/multi-head-what-splitting-buys/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/multi-head-what-splitting-buys/</guid><description>The parameter count is identical, so why split at all. This measures the fact that one weighted average cannot carry two things, and what the rank ceiling on a head actually limits - along with how I misread it the first time.</description><pubDate>Sun, 10 Aug 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>위치 인코딩은 순서를 어떻게 집어넣나</title><link>https://hoijunkim.github.io/blog/positional-encoding-puts-order-in/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/positional-encoding-puts-order-in/</guid><description>8편에서 어텐션은 순서를 몰랐다. 위치를 그냥 숫자로 붙이면 왜 망가지는지, 사인파가 대신 무엇을 보장하는지, 그리고 흔히 말하는 &apos;거리가 멀수록 덜 닮는다&apos;가 왜 사실이 아닌지 재 본다.</description><pubDate>Tue, 05 Aug 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>How positional encoding puts order back in</title><link>https://hoijunkim.github.io/blog/en/positional-encoding-puts-order-in/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/positional-encoding-puts-order-in/</guid><description>Part eight left attention blind to order. This measures why writing the position in as a raw number breaks it, what sinusoids guarantee instead, and why the usual claim that similarity decays with distance is not true.</description><pubDate>Tue, 05 Aug 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>어텐션 가중치를 직접 꺼내 본다</title><link>https://hoijunkim.github.io/blog/attention-weights-drawn/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/attention-weights-drawn/</guid><description>어텐션은 가중평균인데, 그 가중치를 데이터가 정한다. 토큰 여섯 개로 행렬을 실제로 계산해 그려 보고, sqrt(d) 로 나누는 한 줄이 없으면 무슨 일이 벌어지는지 잰다.</description><pubDate>Fri, 01 Aug 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>Taking the attention weights out and looking at them</title><link>https://hoijunkim.github.io/blog/en/attention-weights-drawn/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/attention-weights-drawn/</guid><description>Attention is a weighted average whose weights the data decides. This computes the matrix for six tokens and draws it, then measures what happens when the one line dividing by sqrt(d) is removed.</description><pubDate>Fri, 01 Aug 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>정규화는 초기값을 지운다</title><link>https://hoijunkim.github.io/blog/normalisation-erases-the-init/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/normalisation-erases-the-init/</guid><description>4편에서 초기값 세 개가 만든 20층의 결과는 1e-16 과 0.97 과 0.15 로 갈렸다. 층마다 정규화를 한 줄 넣으면 셋이 소수점 넷째 자리까지 같은 값이 된다. 그 대신 무엇을 내주는지도 재 본다.</description><pubDate>Thu, 31 Jul 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>훈련 오차를 0으로 만드는 법과 그 대가</title><link>https://hoijunkim.github.io/blog/training-loss-is-not-performance/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/training-loss-is-not-performance/</guid><description>점 18개에 17차 다항식을 맞추면 훈련 오차가 3e-17 이 된다. 완벽하게 맞혔다는 뜻이고, 같은 분포에서 새로 뽑은 점에서는 오차가 3.9e10 이 된다. 그 사이에 무슨 일이 있는지 차수를 하나씩 올려 가며 본다.</description><pubDate>Thu, 31 Jul 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>Normalisation erases the initialisation</title><link>https://hoijunkim.github.io/blog/en/normalisation-erases-the-init/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/normalisation-erases-the-init/</guid><description>In part four three initialisations produced 1e-16, 0.97 and 0.15 after twenty layers. Add one line of normalisation per layer and all three land on the same number to four decimals. Here is what that costs.</description><pubDate>Thu, 31 Jul 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>How to drive the training error to zero, and what it costs</title><link>https://hoijunkim.github.io/blog/en/training-loss-is-not-performance/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/training-loss-is-not-performance/</guid><description>Fit eighteen points with a seventeen-degree polynomial and the training error is 3e-17. Perfectly fitted. On fresh points from the same distribution the error is 3.9e10. This walks the degrees to see what happened in between.</description><pubDate>Thu, 31 Jul 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>20층을 쌓으면 기울기가 사라진다</title><link>https://hoijunkim.github.io/blog/init-decides-whether-training-starts/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/init-decides-whether-training-starts/</guid><description>초기값을 0.01 로 두면 20층 뒤 활성은 1e-16 이 되고, 1.0 으로 두면 첫 층 기울기가 1e8 이 된다. 층마다 재서 그려 보면 초기화가 왜 하이퍼파라미터가 아니라 조건인지 보인다.</description><pubDate>Wed, 30 Jul 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>미니배치는 왜 더 시끄러운데 더 빨리 도착하나</title><link>https://hoijunkim.github.io/blog/why-minibatch-wins/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/why-minibatch-wins/</guid><description>전체 데이터로 정확한 한 걸음을 걷는 대신, 일부만 보고 부정확한 여러 걸음을 걷는다. 같은 데이터를 한 번 보는 동안 어느 쪽이 더 내려가는지 재 본다.</description><pubDate>Wed, 30 Jul 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>Stack twenty layers and the gradient disappears</title><link>https://hoijunkim.github.io/blog/en/init-decides-whether-training-starts/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/init-decides-whether-training-starts/</guid><description>Initialise at 0.01 and the activations are 1e-16 after twenty layers; initialise at 1.0 and the first layer&apos;s gradient is 1e8. Measure each layer and it becomes clear why initialisation is not a hyperparameter but a precondition.</description><pubDate>Wed, 30 Jul 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>Why a noisier minibatch arrives sooner</title><link>https://hoijunkim.github.io/blog/en/why-minibatch-wins/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/why-minibatch-wins/</guid><description>Instead of one exact step over all the data, take many inexact ones over parts of it. Measured over a single pass through the data, which one gets further down.</description><pubDate>Wed, 30 Jul 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>역전파는 장부다</title><link>https://hoijunkim.github.io/blog/backprop-is-a-ledger/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/backprop-is-a-ledger/</guid><description>노드 세 개짜리 그래프에서 미분을 손으로 따라가 보고, 수치미분과 대조한다. 역전파는 새로운 미분법이 아니라 곱한 값을 잊지 않고 적어두는 방법이다.</description><pubDate>Tue, 29 Jul 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>학습률에는 넘으면 안 되는 선이 있다</title><link>https://hoijunkim.github.io/blog/learning-rate-has-a-ceiling/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/learning-rate-has-a-ceiling/</guid><description>경사하강법이 손실 지형 위에서 걷는 걸음을 그려본다. 학습률을 올리다 보면 어느 순간 발산하는데, 그 경계는 감이 아니라 계산으로 나오는 값이다.</description><pubDate>Tue, 29 Jul 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>텐서는 사실 1차원이다</title><link>https://hoijunkim.github.io/blog/tensor-is-one-dimensional/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/tensor-is-one-dimensional/</guid><description>reshape 은 왜 공짜이고 transpose 는 왜 데이터를 옮기지 않는가. 배열이 메모리에 어떻게 놓여 있는지 한 번 보고 나면, 나중에 만날 에러 메시지 절반이 미리 설명된다.</description><pubDate>Tue, 29 Jul 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>Backpropagation is a ledger</title><link>https://hoijunkim.github.io/blog/en/backprop-is-a-ledger/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/backprop-is-a-ledger/</guid><description>Follow the derivatives through a three-node graph by hand, then check them against numerical differences. Backpropagation is not a new way to differentiate - it is a way of not throwing away what you already computed.</description><pubDate>Tue, 29 Jul 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>There is a line the learning rate cannot cross</title><link>https://hoijunkim.github.io/blog/en/learning-rate-has-a-ceiling/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/learning-rate-has-a-ceiling/</guid><description>Plot what gradient descent does to a two-parameter loss and the divergence boundary stops being a matter of taste. It falls out of a calculation, and the experiment agrees to three decimal places.</description><pubDate>Tue, 29 Jul 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>A tensor is one-dimensional</title><link>https://hoijunkim.github.io/blog/en/tensor-is-one-dimensional/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/tensor-is-one-dimensional/</guid><description>Why reshape is free and transpose never moves data. Once you have seen how an array actually lies in memory, half the error messages you will meet later are explained in advance.</description><pubDate>Tue, 29 Jul 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>한글 글에만 한글 폰트를 싣는 법</title><link>https://hoijunkim.github.io/blog/korean-typography/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/korean-typography/</guid><description>웹폰트로 한글을 쓰면 라틴 폰트의 수십 배가 든다. 글마다 그 글에 실제로 쓰인 글자만 잘라 실으면, 영어 글은 0KB, 한글 글은 수십 KB로 끝난다.</description><pubDate>Mon, 28 Jul 2025 00:00:00 GMT</pubDate><language>ko</language></item><item><title>One dataset, two views</title><link>https://hoijunkim.github.io/blog/one-dataset-two-views/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/one-dataset-two-views/</guid><description>This site claims that fiddly technical work should be visible and clickable. Making the claim in prose would have been the easy way out, so the work section renders itself twice from a single source instead.</description><pubDate>Mon, 28 Jul 2025 00:00:00 GMT</pubDate><language>en</language></item><item><title>Shipping Korean type only to the posts that need it</title><link>https://hoijunkim.github.io/blog/en/korean-typography/</link><guid isPermaLink="true">https://hoijunkim.github.io/blog/en/korean-typography/</guid><description>A Korean webfont costs dozens of times what a latin one does. Cut each post a subset containing only the characters it actually uses and an English post pays nothing while a Korean one pays tens of kilobytes.</description><pubDate>Mon, 28 Jul 2025 00:00:00 GMT</pubDate><language>en</language></item></channel></rss>