왜 AI는 우리 서버에서 돌지 않는가

이 사이트를 떠받치는 기계에서는 어떤 언어 모델도 돌지 않습니다. 요약은 작업을 가져가고, 일을 하고, 문장을 되가져오는 두 번째 장치에서 계산됩니다.

까닭은 산수입니다. 3B 모델은 1기가바이트 넘는 메모리를 차지하고 답 하나에 몇 초가 필요합니다. 이 응용 전체에서 가장 무거운 데이터베이스 조회는 581밀리초입니다. 그 둘을 같은 보드에 올리면 379,000개 카운터의 그림이 텍스트 생성기 뒤에서 기다리는 셈이고, 그것들이 바로 실제 제품입니다.

그 값은 무엇이고, 무엇을 사는가

값은 두 번째 기계와 대기열입니다. 작업은 한 번에 스무 개까지 나가고, 대기열에는 천장이 있으며, 가득 차면 새것이 만들어지지 않습니다 — 이미 쓰인 문장은 계속 보입니다. 한 주 된 요약은 괜찮습니다. 요약이 없는 것도 괜찮습니다. 보드 위의 다른 무언가가 생각하고 있어서 느린 통계 페이지는 괜찮지 않습니다.

사는 것은 계수 경로가 결코 예측할 수 없는 무언가와 기계를 나눠 쓰지 않는다는 사실입니다. 카운터 그림을 그리는 것은 작고 경계가 있는 일입니다. 텍스트를 만드는 것은 아닙니다. 여기서 문장 하나의 측정 범위는 5.4초에서 54.3초로, 빠른 경우와 느린 경우 사이에 열 배이고, 서버가 미리 볼 수 있는 어떤 것도 그것을 정하지 않습니다.

무엇이 집 밖으로 나가는가

이 대목은 무엇을 짓기 전에 정해야 했습니다. 나중에는 고칠 수 없는 대목이기 때문입니다.

두 번째 기계는 카운터 자신의 통계 페이지에 이미 공개된 숫자만 받고, 통계 페이지가 아예 공개인 카운터에서만 받습니다 — 비공개도 아니고 비밀번호로 보호된 것도 아닌 카운터입니다. 그 작업자는 그 페이지를 연 방문자가 읽을 수 없는 것은 아무것도 알지 못합니다.

코드가 그렇게 나온 데 따른 다행스러운 부수 효과가 아닙니다. 후보 조회가 그것으로 거르고, 그 거르개가 없다면 이 기능 전체는 남의 데이터를 두 번째 장치로 옮기는 일이 됩니다. "조심해서 다루겠다"는 판본 가운데 보내지 않는 것만큼 좋은 것은 없습니다.

일반적인 모양

여기서 나온 규칙 둘은 기능 자체보다 값어치가 큽니다.

경계 없는 일을 경계 있는 경로에서 떼어 두십시오. 실행 시간이 한 자릿수 안에서도 예측되지 않는 것은, 밀리초 안에 답해야 하는 기계에 있어서는 안 됩니다. "대개 괜찮다"가 아닙니다 — 중요한 것은 느린 경우이고, 그것은 언제나 옵니다.

무엇을 지을지 정하기 전에 무엇이 나갈 수 있는지 정하십시오. 답이 "작업자에게는 비공개 카운터도 필요하다"였다면, 옳은 대응은 전송을 안전하게 만드는 것이 아니었습니다. 이 기능이 비공개 카운터를 다루지 않는다는 것이었고, 실제로 그렇게 합니다.