Agent Lab Journal

  Agent Lab Journal

    Guides
...

실습 실험실 · 로컬 모델 (Local models)

에이전트 워크로드 및 롱 컨텍스트(Long Context)에서의 Solar Open 2 테스트

      레벨: 고급 (advanced)
      읽기 및 실험 시간: 120분
      결과: 메모리, 속도, 도구 호출(tool-calling), 그리고 롱 컨텍스트(long-context) 비교
...

“대형 모델이 두 개의 GPU에서 실행된다”는 것은 배치(placement) 결과이지, 에이전트 성능 결과가 아닙니다. 양자화(quantization) 이후에는 가중치(weights)가 들어갈 수는 있지만, 사용 가능한 컨텍스트(context)가 줄어들거나, 첫 번째 토큰 생성 시간(time to first token)이 수용 불가능할 정도로 길어지거나, 유효해 보이는 도구 호출(tool calls)이 잘못된 인자(arguments)를 포함할 수 있습니다. 이 실험실은 벤치마크 수치를 지어내지 않고, 배포 주장을 메모리, 속도, 작업 품질에 대한 재현 가능한 프로필로 전환합니다.

무엇을 산출하게 되는가

• 모델, 양자화(quantization), 런타임(runtime), 채팅 템플릿(chat template) 및 하드웨어에 대한 버전이 지정된 기록;

• 양쪽 GPU 모두에 대한 유휴(idle), 로드(loaded), 프리필 피크(prefill-peak), 그리고 안정적 생성(steady-generation) 메모리 측정값;

• 첫 번째 토큰 생성 시간(time to first token), 프롬프트 처리량(prompt throughput), 생성 처리량(generation throughput), 그리고 엔드 투 엔드(end-to-end) 에이전트 지연 시간(latency);

• 도구 선택(tool selection), 스키마 유효성(schema validity), 인자 정확성(argument correctness), 그리고 다단계 완료(multi-step completion)에 대한 개별 점수;

• 여러 위치와 길이에서의 롱 컨텍스트(long-context) 검색 및 에이전트 결정 결과;

• 동일한 테스트 케이스에 대한 컴팩트한 베이스라인 모델(baseline model)과의 쌍을 이룬 비교.

증거 경계(Evidence boundary). 이 기사는 프로토콜, 피스처(fixtures), 스키마(schemas), 명령(commands) 및 보고서 템플릿을 제공합니다. 여기에는 특정 가중치, 양자화 결과물, 런타임 빌드 또는 2-GPU 호스트가 제공되지 않으므로, 측정된 Solar Open 2 결과값을 주장하지 않습니다. 모든 플레이스홀더(placeholder)를 본인이 저장한 실행 값으로 교체하십시오.

1. 주장을 정확하게 정의하기

Solar Open 2를 고정된 구성이 아닌 테스트 대상 후보로 취급하십시오. 어떠한 아키텍처 주장(architectural claim)을 하기 전에 정확한 모델 식별자(identifier)와 변경 불가능한 리비전(revision)을 기록하십시오. 여러 체크포인트나 변환(conversions) 과정에서 공유되는 이름만으로는 충분하지 않습니다.

대규모 Mixture-of-Experts (MoE) 모델은 각 토큰에 대해 전문가 용량(expert capacity)의 일부만 활성화할 수 있지만, 런타임(runtime)은 여전히 저장된 가중치(weights)의 전체 또는 대부분에 접근해야 합니다. 따라서 토큰당 연산량(Compute per token)과 모델을 유지하는 데 필요한 메모리는 서로 다른 양입니다.

두 개의 GPU에서 실행된다는 것은 런타임이 모델과 버퍼(buffers)를 성공적으로 분산했다는 사실만을 증명할 뿐입니다. 에이전트 배포(agent deployment)에는 다음과 같은 네 가지 추가 질문에 대한 답이 필요합니다:

• 실제 프롬프트(prompts), 동시 요청(concurrent requests) 및 출력을 위해 메모리가 얼마나 남아 있는가?

• 히스토리(history)가 길어짐에 따라 프리필 지연 시간(prefill latency)과 디코딩 속도(decoding speed)가 어떻게 변하는가?

• 도구 호출(tool calling)이 구조적 및 의미적으로 올바르게 유지되는가?

• 모델이 단순히 큰 입력을 수용하는 것을 넘어, 롱 컨텍스트(long context)를 안정적으로 사용하는가?

실험은 다음과 같은 진술을 생성해야 합니다: “이 정확한 아티팩트(artifact)는, 이 정확한 런타임 및 GPU 토폴로지(topology) 상에서, 측정된 헤드룸(headroom)과 함께 목표 워크로드(workload)를 완료하였으며 사전에 선언된 품질 임계값(quality thresholds)을 통과하였다.” 이는 모든 Solar Open 2 배포에 대한 보편적인 판결을 내리는 것이어서는 안 됩니다.

2. 구체적인 에이전트 사례 사용

테스트 에이전트는 합성된 서비스 장애(synthetic service incident)를 조사합니다. 에이전트는 긴 이벤트 타임라인(event timeline)을 수신하고, 네 가지 로컬 도구 중 하나를 선택하며, 증거 식별자(evidence identifiers)로 뒷받침되는 구조화된 답변으로 종료합니다. 도구들은 에뮬레이션(emulated)되며 외부 시스템을 변경할 수 없습니다:

• search_logs(service, query, start, end, limit)

• get_metric(service, metric, start, end, aggregation)

• lookup_runbook(runbook_id, section)

• finish(answer, evidence_ids, confidence)

코퍼스(corpus)에는 직접적인 요청, 누락된 파라미터(parameters), 모호한 서비스 이름, 종속적 호출(dependent calls), 도구 실패, 방해 요소(distractors), 그리고 신뢰할 수 없는 로그 내에 임베디드된 지침(instructions)이 포함되어야 합니다. 또한 점진적으로 길어지는 히스토리의 시작, 중간, 끝 부분에 필요한 사실들을 배치해야 합니다.

후보 결과(candidate results)를 검토하기 전에 컴팩트한 베이스라인(baseline)을 선택하십시오. 베이스라인은 다른 모델 제품군(model family)에 속할 수 있지만, 동일한 태스크 계약(task contract)을 지원해야 합니다. 두 모델 모두에게 동일한 케이스, 도구 스키마(tool schemas), 디코딩 제한(decoding limits), 채점 규칙(scoring rules), 그리고 합성 관측값(synthetic observations)을 제공하십시오.

3. 실험 매니페스트(experiment manifest) 고정

모델을 실행하기 전에 매니페스트를 생성하십시오. 문서화되지 않은 기본값(defaults)을 피해야 합니다. 런타임 업데이트, 토크나이저(tokenizer) 수정, 도구 파서(tool parser), 또는 채팅 템플릿(chat-template) 변경은 가중치 파일(weight files)을 변경하지 않고도 결과를 바꿀 수 있습니다.

experiment_id: solar2-selected-quant-two-gpu-001

candidate:
...

위의 컨텍스트 길이(context lengths)는 예시일 뿐, 모델 지원에 대한 확정적 주장이 아닙니다. 선택한 체크포인트(checkpoint), 위치 설정(positional configuration), 토크나이저, 그리고 런타임에서 지원하는 길이만 유지하십시오. 위치 스케일링(position scaling)이 활성화된 경우, 이를 별도의 실험 조건으로 기록하십시오.

호스트(host) 캡처

mkdir -p solar2-lab/{config,logs,raw,report}

nvidia-smi \
...

비공개 파일 시스템 경로(private filesystem paths)나 액세스 토큰(access tokens)을 게시하는 대신 해시(hashes)를 저장하십시오. 명령(commands), 매니페스트, 요청 본문(request bodies), 또는 서버 로그에 자격 증명(credentials)을 배치하지 마십시오.

4. 메모리 예산에 따른 양자화(quantization) 선택

VRAM 소비량은 모델 파일 크기와 동일하지 않습니다. 유용한 작업 분해 방식은 다음과 같습니다:

작업 VRAM ≈ 양자화된 가중치 (quantized weights)
             + KV 캐시 (KV cache)
             + 임시 텐서 (temporary tensors)
...

KV 캐시는 시퀀스 길이(sequence length), 활성 시퀀스(active sequences), 그리고 모델의 어텐션 설정(attention configuration)에 따라 증가합니다. 짧은 프롬프트(prompt)로 성공적으로 로드된 서버라도 실제 운영 규모의 히스토리(history)에서는 실패할 수 있습니다.

대상 컨텍스트 및 동시성(concurrency)에서 운영 여유 공간(operational headroom)을 확보할 수 있는 하나의 주요 양자화를 선택하십시오. 가능하다면, 품질 관리(quality control)를 위해 동일한 체크포인트의 더 높은 정밀도 또는 덜 공격적인 양자화를 추가하십시오. 이러한 제어 장치가 없다면 후보를 컴팩트한 베이스라인과 비교할 수는 있지만, 양자화를 통해 구체적으로 손실된 품질을 분리하여 파악할 수는 없습니다.

설정 (Configuration)
목적 (Purpose)
필수 기록 사항 (Required record)
...

만약 고정밀도 (higher-precision) 후보 모델을 가용 호스트에서 실행할 수 없는 경우, 해당 제한 사항을 보고하십시오. 관련 없는 기발표된 수치로 대체하지 마십시오. 하드웨어, 런타임 (runtime), 템플릿 (templates), 커널 (kernels) 및 워크로드 (workload)가 다를 수 있습니다.

5. 2-GPU 서버 시작

다음은 OpenAI 호환 런타임 (runtime)을 위한 예시 명령입니다. 모든 플래그 (flag)를 설치된 버전의 로컬 도움말을 통해 확인하십시오. 특히, 선택된 양자화 (quantization)와 체크포인트 (checkpoint)의 도구 호출 (tool-calling) 형식이 지원되는지 확인하십시오.

export SOLAR_MODEL_PATH="<local path or model identifier>"
export SOLAR_SERVED_NAME="solar-open-2-test"

...

필요한 경우 런타임의 명시적인 양자화 및 도구 파서 (tool-parser) 옵션을 추가한 다음, 최종적으로 정제된 명령을 매니페스트 (manifest)에 복사하십시오. 자동 감지는 증거가 될 수 없습니다. 로드된 형식 (format), 텐서 병렬 (tensor-parallel) 레이아웃, 최대 컨텍스트 (maximum context), 채팅 템플릿 (chat template) 및 파서 (parser)를 시작 로그에서 검사하십시오.

curl --fail --silent http://127.0.0.1:8000/v1/models \
  > solar2-lab/config/served-models.json

...

불균형한 분할은 중요합니다. GPU 0은 거의 가득 찬 반면 GPU 1에 수 기가바이트가 남아 있다면, 첫 번째 장치가 여전히 실질적인 최대치를 결정합니다.

6. 네 가지 상태에서의 메모리 측정

다음 상태에서 각 GPU를 별도로 기록하십시오:

• 서버 시작 전;

• 모델 로딩 후 및 첫 번째 요청 전;

• 각 컨텍스트 길이 (context length)에 대한 피크 프롬프트 프리필 (peak prompt prefill) 시;

• 테스트된 각 동시성 (concurrency)에서의 안정적인 디코딩 (steady decoding) 중.

nvidia-smi \
  --query-gpu=timestamp,index,memory.used,memory.free,utilization.gpu,power.draw \
  --format=csv,noheader,nounits \
...

샘플러 (sampler)를 별도의 터미널에서 실행하고 클라이언트 로그에 요청 시작 및 종료 시간을 표시하십시오. 200ms 간격은 실질적인 개요를 제공하지만 짧은 피크를 놓칠 수 있습니다. 결정이 미세한 차이에 달려 있다면 런타임 메트릭 (runtime metrics) 또는 프로파일러 (profiler)와 결합하여 사용하십시오.

모든 컨텍스트(context) 및 동시성(concurrency) 지점마다, 점수가 매겨지지 않은 1회의 웜업(warm-up)을 수행한 후 5회의 측정된 요청을 수행하십시오. 실제 토큰화된 입력 길이(tokenized input length)를 확인하십시오. 한 문장을 수천 번 반복하기보다는 다양한 합성 레코드(synthetic records)를 사용하십시오.

          Model
          Quantization
          Input tokens
...

메모리 부족(out-of-memory) 오류는 누락된 관찰값이 아니라 결과로 취급하십시오. 여유 공간(headroom)이 거의 없는 상태에서만 버티는 설정은 운영 측면에서 안정적이지 않습니다.

7. 프롬프트 처리(prompt processing)와 디코딩(decoding)의 분리

단일 "초당 토큰 수(tokens per second)" 값은 두 가지 서로 다른 단계를 숨깁니다. 최소한 다음 항목들을 캡처하십시오:

• 첫 번째 토큰까지의 시간 (TTFT, time to first token);
• 출력 토큰당 시간 (TPOT, time per output token);
• 프롬프트 처리 또는 프리필(prefill) 처리량;
• 생성(generation) 처리량;
• 엔드 투 엔드(end-to-end) 요청 지연 시간(latency);
• 전체 에이전트 루프(agent loop)의 엔드 투 엔드 지연 시간.

스트리밍 API(streaming API)의 경우, TTFT는 HTTP 헤더가 아니라 첫 번째 의미 있는 텍스트 또는 도구 호출(tool-call) 델타(delta)에서 종료됩니다. 도구 이름과 인자 조각(argument fragments)은 일반 텍스트와 분리된 필드로 도착할 수 있습니다.

request_started = monotonic()
first_content_at = None
response_finished = None
...

중앙값(median)과 개별 반복 횟수를 보고하십시오. 95백분위수(95th percentile)를 계산할 수도 있지만, 5회의 측정 실행으로는 대략적인 꼬리 지표(tail indicator)일 뿐입니다. 프로덕션 서비스 수준(service-level)을 주장하기 전에는 실질적으로 더 큰 실행 횟수를 사용하십시오.

          Model
          Context
          TTFT p50
...

8. 도구 호출(tool-calling) 스위트 구축

두 모델 모두에 대해 동일한 JSON 스키마(JSON Schema)를 사용하여 모든 도구를 설명하십시오. 모델별 채팅 템플릿(chat templates)과 네이티브 파서(native parsers)는 다를 수 있지만, 작업 계약(task contract)은 달라져서는 안 됩니다.

{
  "type": "function",
  "function": {
...

최소한 다음 테스트 카테고리들을 포함하십시오:

• 직접 선택 (Direct selection): 하나의 도구가 명확하게 필요한 경우.

• 인자 그라운딩 (Argument grounding): 정확한 값이 사고 기록(incident record)에서 추출되어야 하는 경우.

• 조합 (Composition): 두 번째 호출이 첫 번째 결과에 의존하는 경우.

• 절제 (Abstention): 호출이 부적절하거나 필요한 정보가 누락된 경우.

• 복구 (Recovery): 에뮬레이션된 도구가 오류를 반환하며, 이를 성공으로 보고해서는 안 되는 경우.

• 신뢰할 수 없는 콘텐츠 (Untrusted content): 로그 항목에 가짜 지시사항이나 가짜 도구 호출이 포함된 경우.

명시적인 기대 동작 저장

{
  "case_id": "metric-after-deploy-001",
  "expected": {
...

픽스처(fixtures)에 포함된 이름, 타임스탬프 및 값은 합성된 테스트 데이터이며, 고객의 사실 관계나 Solar Open 2의 결과가 아닙니다. 진정으로 모호한 사례에 대해서는 허용 가능한 변형(variants)을 미리 선언하십시오. 그렇지 않으면 정확한 자동 채점(automated scoring)에서 제외하십시오.

점수 구성 요소 분리

• 도구 선택 정확도 (Tool selection accuracy): 올바른 도구가 선택되었는지 여부.

• 스키마 유효성 (Schema validity): 인자가 파싱되고 스키마를 통과하는지 여부.

• 인자 정확성 (Argument exactness): 허용된 정규화(normalization) 이후에 필수 값이 일치하는지 여부.

• 시퀀스 성공 (Sequence success): 전체 체인이 올바른 순서와 의존성을 갖는지 여부.

• 오호출률 (False-call rate): 절제(abstention)가 예상되었음에도 도구가 호출된 비율.

• 복구율 (Recovery rate): 모델이 성공을 조작하지 않고 도구 오류를 처리하는 비율.

구성 요소들을 저장하기 전에 이 측정값들을 하나의 점수로 통합하지 마십시오. 모델은 잘못된 환경이나 시간 간격을 통과하면서도 올바른 함수를 일관되게 선택할 수 있습니다.

9. 실제 도구를 결정론적 에뮬레이터(deterministic emulator)로 교체

실제 서비스는 변화하는 데이터, 네트워크 지연(latency), 권한 및 부작용(side effects)을 유발합니다. 모델 비교 중에는 정형화된(canonicalized) 각 인자 세트에 대해 고정된 응답을 반환하십시오.

FIXTURES = {
    (
        "get_metric",
...

모든 에이전트 에피소드(agent episode)에 제한을 두십시오(예: 도구 호출 6회). 루프 제한 실패(loop-limit failure)는 잘못된 최종 답변과는 별도로 기록하십시오.

10. 효과적인 롱 컨텍스트(long context) 테스트

지원되는 컨텍스트 윈도우(context window)는 입력 제한일 뿐, 모든 위치의 정보가 답변에 영향을 미친다는 증거는 아닙니다. 제공된 문서의 특정 증거 없이는 해결할 수 없는 과업을 구성하십시오.

제어된 타임라인 생성 (Generate controlled timelines)

여러 토큰 길이에 걸쳐 합성된 사고 로그(synthetic incident logs)를 구축하십시오. 사용 가능한 히스토리의 5%, 50%, 95% 지점 근처에 고유한 사실을 삽입하십시오:

[event_id=ev-7f31]
service=ledger-worker
deployment_ticket=LAB-K4M9
...

각 케이스마다 새로운 무작위 마커(random markers)를 생성하십시오. 정확한 값과 해당 증거 식별자(evidence identifier)를 모두 요구하십시오. 이는 암기된 단일 마커로 인해 테스트 세트가 패턴 추측(pattern guessing)으로 변질되는 것을 방지합니다.

다음 네 가지 테스트 형태를 사용하십시오:

• 정확한 검색 (Exact retrieval): 하나의 값과 증거 식별자를 반환합니다.

• 레코드 연결 (Record linking): 공유된 식별자를 통해 두 레코드를 결합합니다.

• 시간적 추론 (Temporal reasoning): 두 타임스탬프 사이의 이벤트를 식별합니다.

• 에이전트 결정 (Agent decision): 초기 사실과 후기 제약 조건을 사용하여 도구(tool)를 선택합니다.

마지막 형태가 가장 대표적입니다. 마커를 찾는 것만으로는 모델이 이를 도구 결정에 적용할 수 있다는 것을 증명하지 못합니다.

완전히 렌더링된 요청 수 계산 (Count the fully rendered request)