MoE 모델부터 temperature까지, LLM 파라미터 제대로 이해하기

70B 규모의 대규모 언어 모델(LLM)에는 약 70B개의 학습된 파라미터가 있습니다. 반면 temperature를 0.2로 설정하면, 이를 지원하는 API에서 응답을 샘플링하는 방식이 달라집니다. 모델의 가중치 수가 바뀌는 것은 아닙니다. MoE 모델이든 다른 LLM이든, 파라미터라는 말에는 어떤 모델을 구동할지와 어떤 설정으로 출력을 요청할지라는 서로 다른 선택이 담겨 있습니다. 먼저 작업에 맞는 모델을 고른 다음, 해당 API와 버전에서 실제로 지원하는 설정만 적용해야 합니다.

2026년 10월 25일 각 제공업체의 공개 문서를 기준으로 확인했습니다. 이 구분은 예전보다 더 중요해졌습니다. 현재 일부 API는 샘플링 설정을 보내면 요청을 거부하고, 다른 API는 요청을 받아들이면서도 해당 설정을 무시합니다. 다른 곳의 설정값을 그대로 복사하면 요청 자체가 실패하거나 아무 효과도 없을 수 있습니다.

LLM 파라미터, 모델의 값과 요청의 설정은 다릅니다

모델 파라미터는 학습된 모델에 속하고, 생성 파라미터는 모델에 보내는 요청에 속합니다. 생성 설정을 바꾼다고 모델이 다시 학습되는 것은 아닙니다.

건물을 떠올리면 이해하기 쉽습니다. 하중을 지탱하는 구조는 건물이 무엇을 감당할 수 있는지 결정하고, 각도를 조절하는 차양은 공간을 사용하는 방식을 바꿉니다. 차양을 돌린다고 층이 하나 더 생기지는 않습니다. 마찬가지로 temperature를 바꿔도 작은 모델이 큰 모델로 변하지는 않습니다.

LLM에서 파라미터란 무엇인가요?

모델 규모를 말할 때 파라미터는 모델의 계산을 좌우하는 학습된 수치, 주로 가중치를 뜻합니다. 학습 과정에서는 데이터를 이용해 이 값을 조정합니다. API를 다루는 맥락에서는 출력 생성에 영향을 주는 설정도 흔히 ‘파라미터’라고 부릅니다. IBM의 설명도 학습된 값과 외부 설정을 구분합니다.

공급업체가 “우리 모델은 파라미터가 더 많다”고 하면 모델 자체를 이야기하는 것입니다. 개발자가 “청구서 추출용 파라미터를 바꾸자”고 하면 요청 설정을 뜻할 가능성이 큽니다. 어느 쪽이든 성능에 관한 주장으로 받아들이기 전에 어떤 의미로 쓰였는지 확인해야 합니다.

파라미터 하나는 구체적으로 무엇을 뜻하나요?

학습된 파라미터 하나는 신경망 내부에서 쓰이는 숫자입니다. 예를 들어 한 내부 신호가 다른 신호에 얼마나 크게 기여하는지 조절하는 가중치가 여기에 해당합니다. 사실 하나에 이름표를 붙여 보관한 것도, 문서 한 건도, 단어 하나를 별도 서랍에 넣어 둔 것도 아닙니다.

학습 하이퍼파라미터라는 별도 범주도 있습니다. 학습률처럼 학습이 진행되는 방식을 정하는 설정입니다. 이미 만들어진 모델을 호출하는 업무용 애플리케이션은 보통 이런 학습 설정이나 학습된 가중치를 직접 제어하지 않습니다.

토큰은 또 다른 개념입니다. 입력과 출력을 나누는 단위이며, 단어의 일부인 경우가 많습니다. 프롬프트에 토큰이 더 많다고 모델 파라미터가 더 많아지는 것은 아닙니다. 이 단위는 AI 토큰 가이드에서 설명합니다. 학습된 가중치를 바꾸지 않고 지시문으로 동작을 유도하는 방법은 시스템 프롬프트 가이드에서 다룹니다.

모델 파라미터 수로 알 수 있는 규모와 한계

파라미터 수는 저장 공간과 연산량을 추정하는 데 도움이 되지만, 업무에 가장 적합한 모델을 골라 주지는 않습니다. 인프라 계획은 파라미터 수에서 시작하되, 최종 판단은 실제 작업에 맞춘 평가로 내려야 합니다.

LLM 파라미터 수에서 B와 T는 무엇을 뜻하나요?

‘B’는 학습된 값의 수를 십억 단위로 표시합니다. 70B 모델이라면 파라미터가 약 70B개라는 뜻입니다. ‘T’는 조 단위입니다. 공개된 모델 이름에는 반올림한 수치가 쓰이기도 하므로, 배포에 필요한 자원을 정확히 추정하려면 실제 체크포인트와 저장 형식을 기준으로 삼아야 합니다.

파라미터 수가 같아도 아키텍처, 학습 데이터, 학습 방식, 특화 분야는 다를 수 있습니다. 같은 모델도 각 가중치를 저장하는 정밀도에 따라 차지하는 메모리가 크게 달라집니다.

업무용 모델을 구매할 때 중요한 질문은 도입 기준을 충족하는지입니다. 청구서의 합계를 정확히 추출하는지, 고객 식별자를 그대로 유지하는지, 필수 검사를 통과하는 패치를 만드는지를 확인해야 합니다. 파라미터 수가 더 크다는 사실만으로는 답을 얻을 수 없습니다.

70B 모델의 가중치 메모리 직접 계산하기

가중치 자체의 저장 용량은 파라미터 수에 파라미터당 바이트 수를 곱한 값입니다. 가중치가 정확히 70B개인 가상의 모델을 기준으로 계산하면 다음과 같습니다. 실제 배포 환경에서 측정한 결과는 아닙니다.

여기서 GB는 십진 단위입니다. 140 GB는 일부 메모리 도구가 표시하는 이진 단위로 약 130.4 GiB입니다. 환산으로 바뀌는 것은 단위이며, 모델 자체가 아닙니다.

Hugging Face 문서는 가중치를 더 낮은 정밀도로 저장하는 양자화가 정확도를 최대한 유지하면서 메모리 요구량을 줄이는 원리를 설명합니다. 형식별 차이와 절충점은 LLM 양자화 가이드에서 다룹니다.

프롬프트가 길어지거나 동시 요청이 늘어나도 서빙 부하는 달라집니다. Hugging Face의 모델 메모리 추정 도구 문서는 모델을 메모리에 올리는 단계와 응답을 생성하는 추론 단계를 명확히 구분합니다.

파라미터 수로 비용과 품질을 어디까지 판단할 수 있나요?

다른 조건이 같다면 가중치가 많을수록 저장과 실행에 더 많은 자원이 드는 것이 일반적입니다. 다만 ‘다른 조건이 같다’는 전제가 중요합니다. 정밀도, 아키텍처, 하드웨어, 배치 처리, 처리하는 텍스트의 양이 모두 결과에 영향을 줍니다.

직접 호스팅할 때 파라미터 수는 하드웨어 후보를 추리는 데 도움이 됩니다. 호스팅형 API에서는 이 숫자만으로 요금을 계산할 수 없습니다. 제공업체의 사용량 산정 규칙과 실제 워크로드가 비용을 결정합니다. 겉보기에는 효율적인 모델도 재시도나 사람의 수정이 많이 필요하면 운영 측면에서 좋은 선택이 아닐 수 있습니다.

품질을 판단할 때 모델 크기는 역량을 짐작하는 단서로 보아야지, 점수로 받아들여서는 안 됩니다. 구매 검토 문서에는 대표 입력에 대한 결과, 실패 사례, 평가 조건을 요구해야 합니다. 비공개 모델의 파라미터 수를 추측한 미공개 수치를 성능의 근거로 받아들여서는 안 됩니다.

MoE 모델의 전체 파라미터와 활성 파라미터는 어떻게 다른가요?

전체 파라미터는 모델 전체의 규모를, 활성 파라미터는 토큰 하나를 처리할 때 사용한다고 공개된 연산 경로의 규모를 나타냅니다. 전문가 혼합 모델, 즉 MoE에서는 두 수치를 함께 보아야 합니다.

MoE에는 전문가 하위 네트워크와 토큰마다 어느 전문가가 처리할지 선택하는 라우터가 있습니다. 여기서 ‘전문가’는 수학적 구성 요소입니다. 회계나 법무 업무를 지정해 맡길 수 있는 담당자가 아닙니다. 일부만 활성화하면 모델 전체를 활성화할 때보다 연산량을 줄일 수 있지만, 나머지 가중치도 어딘가에는 저장되어 있어야 합니다. PyTorch의 MoE 설명은 라우팅과 그에 수반되는 통신을 다룹니다.

‘활성 파라미터 104B’에는 개발사가 직접 공개한 사례가 있습니다. Moonshot AI의 Kimi K3.1 Pro 발표에 따르면 전체 파라미터는 2.8T, 활성 파라미터는 104B입니다. 전체를 2,800B로 환산하면 104 ÷ 2,800이므로 활성 비율은 약 3.7%입니다. 이 비율은 발표된 수치로 직접 계산한 값이며, 속도 향상을 측정한 결과나 품질 순위가 아닙니다.

또 다른 사례인 Qwen의 Qwen3-235B-A22B 모델 카드에는 전체 235B, 활성 22B로 명시되어 있습니다. 아래 그림에서 비활성 공간도 보이도록 한 이유는 특정 토큰이 다른 경로를 택하더라도 그 가중치를 저장할 필요는 사라지지 않기 때문입니다.

배포를 검토할 때는 모델 전체를 어떻게 저장하고 분산하는지, 전문가를 하드웨어에 어떻게 배치하는지, 실제 동시 요청 수에서 성능이 어떤지 물어야 합니다. 활성 파라미터 수는 그래픽 처리 장치(GPU)의 메모리 사양이 아닙니다. 이 인프라 문제는 MoE 해설에서 더 자세히 다룹니다.

생성 파라미터는 응답 방식을 어떻게 바꾸나요?

생성 설정은 모델의 역량 범위 안에서 토큰 선택 방식과 생성을 멈추는 조건을 바꿉니다. API는 애플리케이션이 응답을 요청하기 위해 호출하는 인터페이스입니다. 설정만으로 누락된 자료를 채우거나, 모호한 지시를 바로잡거나, 정답을 보장할 수는 없습니다.

LLM temperature: 다음 토큰 선택을 얼마나 집중시킬까

Temperature는 다음 토큰을 고를 때 사용하는 확률 분포를 바꿉니다. 값이 낮으면 가능성이 높은 후보를 더 강하게 선호하고, 값이 높으면 더 다양한 선택을 허용합니다. 일관된 표현이 필요한지, 폭넓은 초안이 필요한지에 따라 조정할 수 있습니다.

청구서를 처리하는 작업에서는 대개 다양성이 목표가 아닙니다. 캠페인 헤드라인 후보를 만들 때는 도움이 될 수 있습니다. 다만 temperature를 낮춘다고 지어낸 청구서 번호가 사실이 되지는 않으며, 높인다고 지식이 추가되지도 않습니다.

Temperature를 0으로 설정한 요청도 언제나 같은 결과를 보장하지는 않습니다. Anthropic 용어집은 temperature가 0이어도 동일한 입력에서 서로 다른 결과가 나올 수 있다고 명시합니다. 재현성은 서빙 시스템 전체를 대상으로 평가해야 합니다.

Top-p: 다음 토큰 후보를 어디까지 남길까

Top-p는 누클리어스 샘플링이라고도 하며, 누적 확률을 기준으로 후보 집합을 제한합니다. 후보의 개수나 전체 어휘에서 차지하는 비율이 아니라 확률의 임곗값입니다.

다음 토큰의 확률 분포가 0.60, 0.25, 0.10, 0.05라고 가정해 보겠습니다. Top-p가 0.9라면 앞의 세 후보가 필요합니다. 처음 두 후보의 합은 0.85이고, 세 후보를 합해야 0.95에 도달하기 때문입니다. 이는 설명을 위한 예시이며, 실제 모델 출력을 관측한 수치가 아닙니다.

Temperature는 확률 분포의 모양을 바꾸고, top-p는 선택할 수 있는 후보를 잘라냅니다. 업무용 설정을 처음 잡을 때는 샘플링 설정을 한 번에 하나씩 바꾸는 편이 좋습니다. OpenAI도 Chat Completions 레퍼런스에서 같은 방식을 권장합니다.

LLM 토큰 제한: 목표 분량이 아니라 출력 상한입니다

생성 토큰 제한은 응답의 상한을 정합니다. 정확히 그만큼의 토큰을 쓰라는 요청이 아니며, 모델이 대화를 처리할 수 있는 용량인 컨텍스트 윈도를 늘려 주지도 않습니다.

상한이 너무 낮으면 JSON 객체, 문장, 코드 패치가 중간에 끊길 수 있습니다. 반대로 상한을 높인다고 유용한 답변이 저절로 나오지는 않습니다. 원하는 분량은 프롬프트로 지시하고, 결과를 온전히 완성할 수 있도록 상한에는 여유를 두어야 합니다.

추론을 사용하는 경우에는 또 다른 구분이 필요합니다. OpenAI의 Responses 레퍼런스에 따르면 출력 상한에는 사용자에게 보이는 출력과 추론 토큰이 모두 포함됩니다. Anthropic의 Messages 레퍼런스도 thinking 토큰을 max_tokens에 포함합니다. 추론 요청의 예산을 잡을 때 허용된 토큰이 전부 최종 답변에 표시된다고 가정해서는 안 됩니다.

중단 시퀀스: 정해 둔 경계에서 생성을 끝냅니다

중단 시퀀스는 지정한 문자열이 나타나면 생성을 종료합니다. 본문에 등장할 일이 없는 명시적 종료 표식처럼, 애플리케이션이 확실하게 구분할 수 있는 경계가 있을 때만 사용해야 합니다.

여러 줄로 된 보고서에서 줄바꿈을 범용 중단 조건으로 쓰는 것은 좋지 않습니다. 중첩 JSON에서 닫는 중괄호를 범용 중단 조건으로 쓰는 것도 마찬가지입니다. 처음 일치하는 중괄호에서 응답이 너무 일찍 끝날 수 있습니다. 구조화된 데이터 추출에는 제공업체가 지원하는 스키마 기능을 우선 사용하고, 반환된 필드를 검증하는 편이 좋습니다.

처음에는 사용자 지정 중단 조건을 생략하는 것이 대체로 합리적입니다. 출력 토큰 상한과 결과 검증은 여전히 필요합니다.

반복 페널티: 반복을 줄이되 필요한 표현은 지켜야 합니다

**존재 페널티(presence penalty)**는 토큰이 한 번이라도 등장했는지에 반응합니다. **빈도 페널티(frequency penalty)**는 얼마나 자주 등장했는지에 반응합니다. 해당 값을 지원하는 엔드포인트에서는 양수가 재사용을 억제하고, 음수는 재사용을 유도할 수 있습니다.

반복이 언제나 결함은 아닙니다. 제품 코드, 고객 이름, JSON 키, 프로그래밍 식별자는 정확히 같은 형태로 다시 나와야 할 수 있습니다. 여기에 페널티를 주면 작업 목적을 해칠 수 있습니다.

추출과 코드 작업은 반복 페널티 없이 시작하는 편이 좋습니다. 초안을 작성할 때는 먼저 반복적인 구성을 유도하는 지시문부터 고쳐야 합니다. 그런 다음에만 지원 범위 내에서 작은 페널티를 검토하고, 필수 용어를 바꾸지 않으면서 초안이 개선되는지 확인해야 합니다. Google의 생성 레퍼런스도 음의 빈도 페널티가 같은 토큰을 끝없이 반복하는 현상을 유발할 수 있다고 경고합니다.

OpenAI·Anthropic·Google API의 설정 범위와 기본값

어떤 설정을 보낼 수 있는지는 엔드포인트, 모델, API 버전이 결정합니다. SDK에 같은 이름의 필드가 있다고 해서 모든 제공업체가 같은 기능을 구현한 것은 아닙니다.

아래 표에서 OpenAI는 Chat Completions, Anthropic은 Messages API 버전 2026-10-21, Google은 **Gemini Developer API의 generateContent**를 기준으로 합니다. Google의 Vertex AI나 Interactions API 설정을 가져와 적용한 표가 아닙니다.

NS는 인용한 최신 필드 문서에 수치 범위나 기본값이 명시되어 있지 않다는 뜻입니다. 0, 무제한, 미지원이라는 뜻은 아닙니다. 아래의 ‘생략’은 애플리케이션을 구성할 때의 권장 사항이며, 제공업체의 기본값을 임의로 정한 것이 아닙니다.

출처: OpenAI 요청 스키마, Anthropic 요청 스키마, Anthropic 버전 마이그레이션, Google 생성 스키마, Google 모델 메타데이터, Google의 top-p 범위.

Google의 일반 문제 해결 표에 나오는 temperature 범위는 생성 필드 레퍼런스보다 좁습니다. 필드 레퍼런스와 선택한 모델의 maxTemperature를 함께 확인해야 합니다. 모델별 값은 Model.temperature, Model.topP, Model.outputTokenLimit를 기준으로 삼아야 합니다. 예제 요청의 값을 문서에 명시된 기본값으로 간주해서는 안 됩니다.

OpenAI: 추론 설정과의 호환성부터 확인합니다

OpenAI의 최신 GPT-6 가이드는 추론 강도가 none이 아닐 때 temperature와 top_p를 제거하라고 안내합니다. GPT-6 Astra와 GPT-6.1 Sol은 none을 지원하지 않고, GPT-6 Sol과 GPT-6 Luna는 지원합니다. 이는 지원 여부에 관한 제한이지, temperature가 특정 숫자로 고정된다는 설명이 아닙니다.

엔드포인트도 중요합니다. Responses는 max_output_tokens를 사용하며, 현재 스키마에 명시된 최솟값은 16입니다. 수치 기본값과 모든 모델에 공통으로 적용되는 최댓값은 해당 스키마에 나와 있지 않습니다. Responses의 생성 요청 스키마에는 Chat Completions의 stop, presence_penalty, frequency_penalty 필드가 없습니다. Chat Completions 레퍼런스는 o3와 o4-mini에서 stop을 지원하지 않는다고 명시하며, max_tokens는 사용 중단 예정으로 표시하고 max_completion_tokens를 대신 쓰도록 안내합니다.

실무에서는 선택한 엔드포인트에 맞춰 요청을 만든 뒤 모델별 호환성 규칙을 적용해야 합니다. 위 표의 설정을 전부 하나의 요청에 복사해서는 안 됩니다.

Anthropic: API 버전에 따라 설정 자체가 사라집니다

Anthropic의 10월 21일 마이그레이션 가이드에 따르면 API 버전 2026-10-21에서 temperature, top_p, top_k를 보내면 기본값을 넣더라도 400 오류가 발생합니다. 이 필드를 생략했을 때의 동작에는 temperature 1.0이 포함됩니다.

이전 API 버전을 쓴다고 모든 모델에서 설정을 자유롭게 바꿀 수 있는 것도 아닙니다. Anthropic의 thinking 문서에 따르면 Claude Sonnet 5.5를 포함한 일부 모델은 thinking 활성화 여부와 관계없이 기본값이 아닌 샘플링 값을 거부합니다. 해당 모델의 top-p 기본값은 0.99이며, 1은 거부한다고 명시되어 있습니다. 예전의 일반적인 범위 안내보다 이 모델별 규칙을 우선해야 합니다.

실제로 응답을 생성하려면 모델 한도 내에서 양의 max_tokens 예산을 지정해야 합니다. 문서상 최솟값인 0은 응답 생성 없이 캐시를 미리 준비하는 용도이므로, 추출 작업의 시작 설정으로는 유용하지 않습니다.

Google: 요청이 성공해도 설정은 무시될 수 있습니다

Google의 Gemini 3.6 Flash 및 3.5 Flash-Lite 마이그레이션 가이드에 따르면 이 모델들은 사용 중단 예정인 temperature, top-p, top-k 설정을 무시합니다. 가이드는 개발자에게 해당 설정을 제거하라고 안내하며, 향후 모델 세대에서는 이를 보내면 400 오류로 거부할 것이라고 설명합니다.

이는 요청이 거부되는 것과 다른 형태의 실패입니다. 애플리케이션에서는 temperature 변경이 받아들여진 것처럼 보여도 모델은 이전과 똑같이 동작할 수 있습니다. 응답이 성공했다는 이유로 설정이 적용되었다고 판단하기 전에 선택한 모델의 문서를 확인해야 합니다.

업무별 LLM 설정은 어디서 시작해야 하나요?

제공업체가 지원하는 동작과 측정 가능한 성공 기준에서 출발해야 합니다. 아래 수치는 설정을 조정할 수 있는 엔드포인트에서 시도해 볼 만한 시작값입니다. 제공업체의 기본값도, 측정으로 확인한 최적값도, 어디에나 적용할 수 있는 프리셋도 아닙니다. 앞서 설명한 호환성 규칙이 우선합니다.

데이터 추출: 정확한 값을 지키는 것이 우선입니다

청구서 필드, 고객지원 티켓 분류, 계약 메타데이터를 추출할 때는 지원되는 경우에만 temperature 0 또는 0.2를 시도해 볼 수 있습니다. Top-p는 그대로 두고, 사용자 지정 중단 조건과 반복 페널티는 생략합니다. 이를 지원하는 OpenAI Chat Completions 모델에서는 두 페널티를 명시적으로 0으로 설정해 페널티 없는 기준선을 정할 수도 있습니다.

현재 Anthropic 요청과 앞서 언급한 Gemini Flash 모델에서는 샘플링 설정을 생략합니다. 대신 명확한 필드 정의, 허용 범주, 데이터 누락 사례, 제공업체가 지원하는 구조화 출력 기능을 활용해야 합니다. 형식이 올바른지와 별개로 결과 자체를 검증해야 합니다.

짧은 레코드를 추출한다면 호환되는 비추론 요청에서 출력 상한 1,000토큰을 초기 실험값으로 삼을 수 있습니다. 모든 작업에 통하는 한도는 아닙니다. 출력이 잘리는지와 실제 사용량을 확인하고, 필요한 경우 추론 예산을 별도로 고려해야 합니다. 없는 청구서 번호를 지어내는 대신 누락을 나타내는 표식을 반환하도록 요청해야 합니다.

통과 기준: 필수 필드가 모두 있고, 값이 원문과 일치하며, 없는 정보는 없는 상태로 남아 있어야 합니다. JSON 검증을 통과하는 것만으로는 부족합니다.

초안 작성: 표현은 다양하게, 사실은 그대로 유지합니다

영업 제안 이메일이나 제품 설명은 모델이 지원하는 기본 동작에서 시작합니다. 조정 가능한 엔드포인트라면 top-p를 유지한 채 temperature 0.7과 비교해 봅니다. 프롬프트에는 독자, 분량, 어조, 반드시 포함할 사실, 금지할 주장을 명시해야 합니다.

처음에는 페널티를 생략합니다. 이를 지원하는 OpenAI Chat Completions 모델이 원치 않는 문구를 계속 반복한다면, 문서에 명시된 범위 안에서 빈도 페널티 0.2를 적용하는 작은 실험을 해 볼 수 있습니다. 검토 결과 개선이 확인될 때만 유지해야 하며, 필수 제품명은 그대로 보존되어야 합니다.

샘플링 설정이 제거된 모델에서는 서로 다른 접근법을 명시적으로 요청합니다. 예를 들어 간결하게 사실을 전달하는 초안과 이야기를 풀어가는 초안을 요구할 수 있습니다. 차이는 실제 결과물로 판단해야 합니다.

통과 기준: 새로운 사실 주장을 추가하지 않으면서 유용한 변화를 만들어야 합니다. ‘더 의외인 표현’이 곧 ‘더 좋은 비즈니스 문안’은 아닙니다.

코드 작성: 패치를 끝까지 받고 동작을 확인합니다

조정 가능한 엔드포인트에서 범위가 명확한 패치를 만들 때는 temperature 0 또는 0.2가 합리적인 비교 기준이 됩니다. 추론 모델은 지원되는 구성을 따르고, 지원하지 않는 샘플링 필드는 생략해야 합니다. 검증된 프로토콜에서 요구하지 않는 한 반복 페널티와 사용자 지정 중단 조건도 생략합니다.

관련 코드, 제약 조건, 기대 동작을 제공해야 합니다. 패치를 완성할 수 있도록 출력 공간도 충분히 확보해야 합니다. 응답이 상한에 도달했다면 화면에 보이는 부분을 안전하게 적용할 수 있다고 가정하지 말고, 미완성 결과로 취급해야 합니다.

통과 기준: 패치가 명세를 충족하고 적절한 검사를 통과해야 합니다. 식별자의 반복은 코드에서 자연스러운 일이며, 그럴듯해 보이는 답변이 실행 가능하다는 증거는 아닙니다.

파라미터 수와 생성 설정으로 보장할 수 없는 것

숫자 하나로 평가를 대신할 수 있다는 주장은 과장입니다. 그 숫자가 가중치 수든 temperature든 마찬가지입니다.

큰 모델이 특정 업무에서 자동으로 더 나은 것은 아닙니다. MoE의 활성 파라미터 수가 작다고 모델 전체가 그만큼의 메모리에 들어가는 것도 아닙니다. 낮은 temperature는 사실성을 보장하지 않습니다. 높은 출력 상한도 완결된 논증을 보장하지 않으며, API 호출의 성공만으로 보낸 설정이 모두 적용되었다고 판단할 수 없습니다.

유용한 근거는 대표성 있는 입력, 명확한 성공 조건, 직접 검토한 결과입니다. 구매를 검토한다면 실제로 사용할 구성에서 공급업체가 워크플로를 시연하도록 요구해야 합니다. 직접 구축한다면 모델, 엔드포인트, API 버전, 프롬프트, 설정을 기록해야 합니다. 그래야 동작이 달라졌을 때 무엇이 바뀌었는지 이해할 수 있습니다.

구매·운영·개발 담당자는 다음에 무엇을 해야 하나요?

구매 담당자는 결과를 비교하고, 운영 담당자는 실패를 정의하며, 개발자는 지원되지 않는 설정을 제거해야 합니다. 이 세 역할은 같은 소규모 평가 데이터셋을 중심으로 만납니다.

호스팅 서비스를 고르는 구매 담당자는 서비스가 필요한 결과를 입증한다면 파라미터 수를 몰라도 도입을 진행할 수 있습니다. 직접 호스팅할 하드웨어는 전체 체크포인트, 정밀도, 워크로드를 기준으로 필요한 규모를 산정한 뒤 구매해야 합니다. 운영 중인 워크플로가 잘 작동한다면 다른 모델이 더 큰 숫자를 내세운다는 이유만으로 교체할 필요는 없습니다.

모델이나 API 버전을 바꾸는 개발자는 지금 호환성을 확인해야 합니다. 생성 설정이 노출되지 않는 관리형 인터페이스를 사용하는 운영 담당자는 요청 필드 문법의 영향을 거의 받지 않지만, 출력 검증은 여전히 필요합니다.

1. 1

   반드시 성공해야 하는 업무 사례를 모읍니다

   다음 월요일, 하나의 워크플로에서 대표 사례 20개를 모읍니다. 정보가 불완전하거나 모호한 입력, 유난히 긴 입력도 포함해야 합니다. 모델을 비교하기 전에 기대 결과나 검토 기준을 먼저 작성합니다.

2. 2

   요청 구성을 명확하게 기록합니다

   엔드포인트, 모델, API 버전을 기록합니다. 지원되는 설정을 확인하고 나머지는 제거한 뒤, 결과를 완성할 수 있는 출력 예산을 정합니다. 반드시 지켜야 할 용어와 데이터 누락 시 처리 방식은 프롬프트에 명시합니다.

3. 3

   한 가지씩 바꾸고 결과로 판단합니다

   기준 구성과 지원되는 설정 하나를 바꾼 구성을 비교합니다. 추출은 원문과의 일치 여부, 초안은 사실의 정확성과 유용성, 코드는 동작과 검사 결과를 확인합니다. 변경의 이점이 입증되지 않으면 더 단순한 구성을 유지합니다.

자주 묻는 질문

LLM의 temperature는 어떻게 작동하나요?

다음 토큰의 확률 분포가 얼마나 집중되는지를 바꿉니다. 값이 낮으면 가능성이 높은 후보를 선호하고, 높으면 더 다양한 선택을 허용합니다. 학습된 가중치가 아니라 샘플링 방식을 바꾸는 설정이며, 현재 일부 API는 이를 거부하거나 무시합니다.

70B 모델은 대략 어느 정도의 저장 공간이 필요한가요?

가중치가 정확히 70B개라면 가중치 자체의 저장 용량은 16비트에서 약 140 GB, 8비트에서 70 GB, 이상적인 4비트 저장에서 35 GB입니다. 이 십진 단위 수치에는 실행 중 메모리와 양자화 부가 용량이 포함되지 않습니다. 실제 배포에 필요한 자원은 체크포인트와 워크로드가 결정합니다.

파라미터는 네 가지 유형으로 나뉘나요?

LLM에 보편적으로 적용되는 네 가지 유형의 분류법은 없습니다. 이해를 돕기 위해 학습된 모델 파라미터, 아키텍처 설정, 학습 설정, 생성 설정으로 구분할 수는 있습니다. 이는 시스템을 이해하기 위한 범주이며, 모든 API에 설정이 네 개 있다는 뜻은 아닙니다.

GPT와 LLM은 어떻게 다른가요?

LLM은 대규모 언어 모델을 뜻하는 넓은 범주입니다. GPT는 생성형 사전 학습 트랜스포머를 뜻하며, 그 범주 안의 특정 모델 계열과 접근법을 가리킵니다. 다른 언어 모델 계열도 LLM에 포함됩니다.

LLM의 네 가지 유형은 무엇인가요?

네 가지로 나누는 단일 표준은 없습니다. 밀집 모델과 MoE의 구분은 아키텍처를, 공개 가중치와 비공개 가중치의 구분은 접근 가능 여부를 설명합니다. 서로 다른 질문에 답하는 구분이므로 이를 합쳐 품질 순위처럼 취급해서는 안 됩니다.

ChatGPT는 LLM인가요, AI인가요?

ChatGPT는 모델을 사용하는 AI 애플리케이션입니다. 애플리케이션 자체, 그 안에서 선택한 모델, 개발자가 사용할 수 있는 API 설정을 구분해야 합니다. 각각 서로 다른 계층입니다.

LLM이 아닌 AI도 있나요?

AI는 언어 모델보다 넓은 개념입니다. 사기 탐지 분류기나 컴퓨터 비전 시스템은 LLM 없이도 머신러닝 기법을 사용할 수 있습니다. 파라미터 수 역시 언어 모델에만 해당하는 개념은 아닙니다.

가장 똑똑한 LLM은 무엇인가요?

파라미터 수만으로 작업과 무관한 정답을 정할 수는 없습니다. 실제 업무를 대표하는 사례에서 같은 통과 기준과 문서화된 구성으로 모델을 비교해야 합니다. 하나의 벤치마크 결과가 모든 업무에서의 우열을 결정하지는 않습니다.

LLM은 AI의 어느 분야에 속하나요?

LLM은 언어 처리와 생성에 쓰이는 딥러닝 모델입니다. 학습된 파라미터는 모델에 속하고, temperature 같은 요청 설정은 애플리케이션이 모델을 사용하는 방식에 속합니다.

AI 시스템의 원리와 선택 기준을 실무 관점에서 살펴보고 싶다면 뉴스레터를 구독하세요.