꼬리를 재니 12편의 k=8 이 47% 나쁘다

12편은 요청 256개를 끝내는 데 걸린 전체 시간으로 스케줄을 줄 세웠다. k 개씩 모아서 프리필하면 k = 8 이 제일 좋다는 결론이었다.

전체 시간은 처리량이다. 요청 하나를 낸 사람이 겪는 것은 그게 아니다. 자기 글자가 얼마나 고르게 나오는지가 그 사람이 보는 전부인데, 12편의 표에는 그게 없다.

글자와 글자 사이

이미 돌고 있는 요청이 다음 글자를 받기까지 걸린 시간을 잰다. 디코드 걸음 하나가 지나가면 살아 있는 모든 요청이 글자를 하나씩 받으므로, 디코드와 그 앞 디코드 사이의 시간이 곧 그 간격이다. 사이에 프리필이 끼면 그만큼 벌어진다.

처음 쟀을 때는 모든 스케줄이 똑같이 나왔다. 최대가 3.5에서 4.5ms 사이로 다 비슷했다. 코드를 보니 간격을 직전 연산에서 재고 있었다. 프리필 바로 뒤의 디코드는 프리필이 끝난 시각부터 재게 되니, 프리필 값이 숫자에서 통째로 빠져 있었다. 재려던 것이 정확히 그것이었는데.

중앙값과 꼬리가 반대로 간다

고쳐서 다시 재면

              프리필   디코드     p50    p99   p99 사분위    처리량
고정 배치           8    512    1.14  14.06  13.45~14.84    1.000
연속 k=1         144    336    1.76   5.57   5.41~ 6.88    1.207
연속 k=2          88    338    1.38   6.16   5.95~ 7.49    1.263
연속 k=4          48    348    1.17   6.99   6.34~ 7.91    1.318
연속 k=8          27    364    1.13   8.21   7.51~11.30    1.392
연속 k=16         15    410    1.13  10.78   9.83~12.07    1.273
연속 k=32          8    512    0.90  14.06  13.14~15.48    1.202

k 를 올리면 p50 은 1.76 에서 0.90 으로 좋아지는데 p99 는 5.57 에서 14.06 으로 나빠진다. 같은 손잡이가 두 숫자를 반대 방향으로 민다.

이유는 12편에 다 있다. k 가 작으면 프리필을 자주 하지만 한 번이 작고, k 가 크면 드물게 하지만 한 번이 크다. 자주 하는 쪽은 모든 걸음이 조금씩 늦어져 중앙값이 나쁘고, 드물게 하는 쪽은 대부분의 걸음이 깨끗한 대신 가끔 크게 멈춘다.

12편이 고른 k = 8 은 p99 가 8.21 로 k = 1 의 5.57 보다 47% 나쁘다. 두 사분위가 겹치지도 않는다 - 7.51~11.30 대 5.41~6.88. 처리량은 1.392 대 1.207 로 k = 8 이 낫다. 12편이 틀린 게 아니라, 12편이 본 축에서는 그게 맞았다.

프리필을 조각내면

12편은 이 문제를 이름만 대고 넘어갔다. 프롬프트를 통째로 밀어 넣지 말고 c 개씩 끊어 넣고 조각 사이에 디코드 한 걸음을 끼우면, 멈추는 시간이 프리필 전체가 아니라 조각 하나가 된다.

k = 8 에서 조각 크기를 바꿔 보면

            프리필   디코드     p50    p99   p99 사분위    처리량
통짜            27    364    1.13   8.21   7.51~11.30    1.392
조각 32         55    373    1.23   6.88   6.19~ 7.32    1.250
조각 16        108    390    1.30   5.86   5.39~ 7.23    1.120
조각 8         208    421    1.96   5.50   5.02~ 7.22    0.933

꼬리는 8.21 에서 5.50 으로 줄고 처리량은 1.392 에서 0.933 으로 준다. 조각 8이면 고정 배치보다도 느리다.

조각내도 아무 일도 안 일어나는 곳

k = 32 에서 같은 걸 하면 반대로 간다.

            프리필   디코드     p99   p99 사분위    처리량
통짜             8    512   14.06  13.14~15.48    1.202
조각 32         16    512   14.41  13.71~16.83    1.217
조각 16         32    512   17.83  17.46~19.34    1.147
조각 8          64    512   24.81  22.39~26.75    1.044

디코드 걸음 수가 512 로 붙박이다. k = 32 는 자리가 다 빌 때까지 기다렸다 채우므로, 프리필이 도는 동안 살아 있는 요청이 하나도 없다. 조각 사이에 끼울 디코드가 없으니 조각내기는 프리필을 여러 번으로 쪼개기만 하고, 고정 오버헤드를 그만큼 더 낸다. 그 값이 고스란히 하나의 간격에 쌓여 p99 가 14.06 에서 24.81 로 간다.

조각내기는 조각 사이에 돌릴 것이 있을 때만 값을 한다.

프론티어

두 손잡이를 한 판에 놓는다.

지배당하지 않는 점은 여섯 개다.

k=8            처리량 1.392   p99  8.21
k=4            처리량 1.318   p99  6.99
k=2            처리량 1.263   p99  6.16
k=1            처리량 1.207   p99  5.57
k=1 조각 32     처리량 1.091   p99  5.48
k=1 조각 8      처리량 0.849   p99  5.29

넷이 통짜고 둘이 조각내기다. p99 8.21 에서 5.57 까지 - 쓸 만한 범위의 대부분 - 은 k 하나로 덮이고, 그 사이에 조각내기가 낄 자리가 없다. 조각내기가 프론티어에 나타나는 것은 5.57 아래인데, 거기서 5.29 까지 0.28ms 를 더 줄이는 데 처리량 1.207 에서 0.849 로 30%를 낸다.

이 워크로드에서 조각내기는 대체로 살 값이 아니다. 그리고 그 이유는 프롬프트가 짧아서다. 여기 프롬프트는 최대 64자이고, 통짜 프리필 한 번이 디코드 몇 걸음 값밖에 안 된다 - 12편에서 1.34에서 7.48 걸음이었다. 애초에 크지 않은 덩어리를 쪼개 봐야 얻을 게 적다.

남는 것

프롬프트가 수천 자로 가면 이야기가 달라진다. 통짜 프리필 하나가 디코드 수백 걸음 값이 되고, 그 하나가 p99 를 혼자 정한다. k 를 아무리 내려도 프리필 자체가 크므로 손을 못 대고, 조각내기 말고는 방법이 없어진다. 이 모델은 문맥이 128자라 그 영역을 못 만든다.

최대값은 표에서 뺐다. 설정마다 디코드 걸음 수가 336 에서 512 로 다르니 표본 수가 다르고, 표본이 많을수록 최대는 커진다. 분위수는 그 영향을 덜 받는다.

그리고 여기서 요청은 256개가 한꺼번에 도착한다. 실제로는 띄엄띄엄 오고, 그러면 자리가 비어 있는 시간이 생겨 프리필이 공짜에 가까워지는 구간이 생긴다. 그 경우는 안 쟀다.

그래서

• 같은 k 손잡이가 p50 과 p99 를 반대로 민다. p50 은 1.76 에서 0.90 으로 좋아지고 p99 는 5.57 에서 14.06 으로 나빠진다
• 12편이 고른 k = 8 은 p99 가 k = 1 보다 47% 나쁘다. 사분위가 안 겹친다
• 조각내기는 k = 8 의 꼬리를 8.21 에서 5.50 으로 줄이고 처리량을 1.392 에서 0.933 으로 줄인다
• k = 32 에서는 조각내기가 꼬리를 14.06 에서 24.81 로 키운다. 조각 사이에 돌릴 것이 없으면 오버헤드만 는다
• 프론티어 여섯 점 중 넷이 통짜다. 조각내기는 p99 5.57 아래에서만 나타나고, 거기서 0.28ms 에 처리량 30%를 낸다
• 프롬프트가 짧으면 쪼갤 덩어리가 애초에 작다