AMD ROCm 환경에서의 Step-3.7-Flash 사용 시 ~94k 이상의 긴 컨텍스트 손상 및 추론 토큰 예산 설정 필요성

AMD 환경에서 ROCm을 사용하여 StepFun Step-3.7-Flash를 실행한 후의 짧은 노트입니다.
가장 중요한 두 가지 사항은 다음과 같습니다:

1. 컨텍스트를 ~94k 이상으로 실행하지 마세요. 제 설정에서는 ROCm이 약 94k 토큰 부근에서 긴 컨텍스트 (long context)를 손상시킵니다. 모델이 보통 충돌(crash)하지는 않습니다. 그저 루프를 돌며 토큰 예산 (token budget)을 소모할 뿐, 사용 가능한 답변을 내놓지 못합니다. Vulkan은 더 긴 컨텍스트에서도 정확성을 유지하지만, 프롬프트 처리 (prompt processing) 속도는 ROCm이 훨씬 빠릅니다. RAG 워크로드의 경우, 저는 컨텍스트를 90k로 제한하고 ROCm을 계속 사용하고 있습니다.

2. 엄격한 추론 예산 (thinking budget)을 설정하세요. Step의 추론 모드 (reasoning mode)는 기본적으로 활성화되어 있습니다. 저에게는 enable_thinking:false가 작동하지 않았고, reasoning_effort도 마찬가지였습니다. 효과가 있었던 방법은 llama.cpp의 추론 예산 (reasoning budget) 설정이었습니다: 서버 측: --reasoning-budget 256 또는 요청당: thinking_budget_tokens: 256. 중요: 요청당 thinking_budget_tokens는 서버가 이미 --reasoning-budget가 설정된 상태로 시작되지 않았을 때만 작동하는 것으로 보입니다.

예산 설정이 없으면 Step은 종종 2000개 이상의 토큰 동안 추론하다가 finish_reason: length에 도달하여 빈 콘텐츠를 반환하곤 했습니다. 256개와 같은 작은 예산을 설정하면 정상적으로 답변했습니다. 제 분류 작업 (classification task)에서는 64개에서 1024개의 추론 토큰 사이에서 품질이 기본적으로 동일했습니다.

저의 현재 실용적인 설정:

• ROCm 사용
• 컨텍스트를 90k로 제한
• thinking_budget_tokens를 보통 256으로 설정
• enable_thinking:false에 의존하지 말 것
• reasoning_effort에 의존하지 말 것

이것만으로도 저의 RAG/분류 워크로드에서 Step-3.7-Flash를 사용할 수 있게 되었습니다.

수정 사항: ~94k는 이전 빌드 기준이었으며, 현재 마스터 (4c6595503) 버전은 103k까지는 원문 그대로 깨끗하게 유지되다가 125k에서 퇴화(degenerate)합니다. KV 양자화 (KV quant, q8_0 vs f16)와 배치 크기 (batch size)는 차이가 없었습니다. 여유를 두기 위해 90k 제한을 유지하고 있습니다.

submitted by /u/neuromacmd