Question 1

AVX-512는 있지만 AVX512BF16이 없는 Xeon Cascade Lake에서 DeepSeek V4 Flash가 쓰레기 출력을 반환하는 문제를 해결하는 방법

Accepted Answer

이 문제는 PR #2181에서 발생한 리그레션입니다: `kt-kernel/operators/amx/fp4-moe.hpp`의 `prepare_decode_down_input()`이 `__AVX512BF16__`를 사용할 수 없는 경우에도 최적화된 MXFP4 디코드 경로를 사용합니다. BF16을 지원하지 않는 CPU에서는 `down_ba_`가 채워지지 않으므로, down 프로젝션이 초기화되지 않은 메모리를 읽어 잘못된 값을 생성합니다.

PR `fix(kt-kernel): restore MXFP4 decode fallback without AVX512 BF16`이 포함된 빌드로 업데이트하거나, 최적화된 경로를 `__AVX512BF16__`로 제한하여 수정하세요:

```cpp
void prepare_decode_down_input(int expert_idx, int qlen) {
#if defined(__AVX512BF16__)
  if (qlen != 1 || config_.quant_config.group_size != 32 ||
      config_.intermediate_size % 32 != 0) {
    Base::prepare_decode_down_input(expert_idx, qlen);
    return;
  }
  assert(down_ba_[expert_idx]->natural_order);
#else
  Base::prepare_decode_down_input(expert_idx, qlen);
#endif
}
```

그런 다음 커널을 다시 빌드하세요. 이렇게 하면 AVX512F/VNNI는 지원하지만 AVX512BF16은 지원하지 않는 Xeon Platinum 8268/Cascade Lake와 같은 CPU에서 기본 폴백이 복원됩니다.

Question 2

ktransformers로 DeepSeek-V2-Lite에서 LoRA SFT를 실행할 때 `MoELayer._compute_routing`에서 발생하는 IndexError를 해결하는 방법은?

Accepted Answer

이 문제는 ktransformers 0.6.4에서 PEFT/LoRA가 DeepSeek MoE 게이트를 `nn.Linear`로 교체했음에도 `_compute_routing`이 여전히 `deepseek_gate` 분기로 진입하여 원시 로짓을 `(topk_ids, topk_weights, aux_loss)` 튜플로 처리할 때 발생합니다.

`kt_kernel/sft/layer.py`에 다음 한 줄 수정을 적용하세요:

```python
# 수정 전
if self.router_type == "deepseek_gate":

# 수정 후
if self.router_type == "deepseek_gate" and self._original_router is None:
```

이렇게 하면 교체된 Linear 라우터가 기존 `_original_router` 라우팅 경로를 사용하게 되며, 이 경로는 DeepSeek-V2-Lite에 대해 softmax 스코어링과 greedy top-k 선택을 수행합니다.

또한 LLaMA-Factory YAML에서 `lora_target: all`은 MoE 라우터 자체를 래핑하므로 사용하지 마세요. 다음과 같이 명시적인 대상 세트를 사용하세요:

```yaml
lora_target: q_proj,kv_a_proj_with_mqa,kv_b_proj,o_proj,gate_proj,up_proj,down_proj
```

패치와 설정 변경 후에는 DeepSeek-V2-Lite LoRA SFT가 정상적으로 진행되며, 이 수정은 20스텝 학습 실행과 성공적인 어댑터 내보내기를 통해 검증되었습니다.

Question 3

transformers-kt 5.x에서 GLM-4.5-Air의 출력이 약 4,000 토큰 이후에 품질이 저하되거나, 반복되거나, 깨지는 이유는 무엇이며, rope_theta가 10000으로 읽히는 문제는 어떻게 해결하나요?

Accepted Answer

모델의 `config.json`에는 올바른 값이 `rope_parameters` 아래에(`1000000`) 저장되어 있지만, transformers-kt 5.x는 최상위 `rope_theta`를 노출하지 않으므로 로더가 기본값 `10000`으로 폴백합니다. 잘못된 RoPE 기본 주파수로 인해 대략 4k 토큰 이후부터 퍼플렉서티가 폭증합니다.

영향을 받는 설정은 `sglang-kt 0.7.0.post4`, `kt-kernel 0.7.0.post4`, `transformers-kt 5.6.0.post5`에서 보고되었습니다.

중첩된 값을 읽도록 config/RoPE 초기화를 수정하세요:

```python
if getattr(config, "rope_parameters", None):
    rope_theta = config.rope_parameters.get(
        "rope_theta", getattr(config, "rope_theta", 10000)
    )
else:
    rope_theta = getattr(config, "rope_theta", 10000)
```

로터리 임베딩을 생성할 때 이 `rope_theta`를 사용한 다음 서버를 재시작하세요. 유효 값은 `10000`이 아니라 `1000000`이어야 합니다.

임시 로컬 해결 방법으로 모델의 `config.json`에 최상위 값을 추가하세요:

```python
import json, pathlib
p = pathlib.Path("/path/to/model/config.json")
c = json.loads(p.read_text())
c["rope_theta"] = c["rope_parameters"]["rope_theta"]
p.write_text(json.dumps(c, indent=2))
```

수정 후에는 롱컨텍스트 퍼플렉서티가 위치 4096 이상에서 급격히 상승하는 대신 대체로 평탄하게 유지되어야 합니다.

Question 4

kt_use_lora_experts와 FSDP2로 LoRA Experts를 저장할 때 발생하는 'Attempted to access the data pointer on an invalid python storage' 오류를 해결하는 방법

Accepted Answer

이 문제는 kt-kernel 0.6.4에 영향을 미칩니다. FSDP2 환경에서 LoRA-Expert 파라미터는 `DTensor` 샤드이지만, `save_lora_experts_to_adapter`가 `.data.cpu().clone()`을 직접 호출합니다. 이 호출은 샤드를 수집하지 않으므로, safetensors가 유효하지 않은 스토리지를 가진 텐서를 받아 학습 완료 후 충돌이 발생하고, `adapter_model.safetensors`에는 표준 PEFT LoRA 가중치만 남게 됩니다.

`kt_kernel/sft/lora.py`의 797–799번째 줄 부근을 패치하여 저장 전에 `DTensor`를 수집하세요:

```python
def _materialise_for_save(t):
    try:
        from torch.distributed.tensor import DTensor
    except ImportError:
        try:
            from torch.distributed._tensor import DTensor
        except ImportError:
            DTensor = ()

if DTensor and isinstance(t, DTensor):
        t = t.full_tensor()  # collective: must run on every FSDP rank

return t.detach().cpu().clone()

state_dict[f"{base_key}.le_gate.weight"] = _materialise_for_save(expert.le_gate.weight)
state_dict[f"{base_key}.le_up.weight"]   = _materialise_for_save(expert.le_up.weight)
state_dict[f"{base_key}.le_down.weight"] = _materialise_for_save(expert.le_down.weight)
```

`full_tensor()`를 rank 0에서만 호출하지 마세요. 이는 분산 콜렉티브 연산이므로 모든 rank가 진입해야 합니다. 실제 `safetensors.torch.save_file` 호출은 메인 프로세스만 체크포인트를 기록하도록 가드하는 것은 가능합니다.

수정 후에는 `adapter_model.safetensors`에 `le_gate`, `le_up`, `le_down` 텐서가 포함되어 있고, LoRA Experts를 사용하지 않은 실행보다 파일 크기가 더 큰지 확인하세요. 임시 해결 방법으로는 `kt_use_lora_experts`를 비활성화하거나 FSDP2가 아닌 DDP 구성을 사용하세요.

Question 5

ktransformers FSDP2 LoRA SFT gradient clipping에서 'aten._foreach_mul_.Tensor: got mixed torch.Tensor and DTensor' 오류를 해결하는 방법

Accepted Answer

이 문제는 FSDP2를 사용하는 ktransformers 0.6.4에서 발생하는데, 그 이유는 FSDP2가 일반 파라미터를 `DTensor`로 래핑하는 반면 CPU에 상주하는 expert-LoRA 파라미터는 일반 `torch.Tensor`로 남아 있기 때문입니다. 그 결과 HF Trainer는 혼합된 리스트를 `_foreach_mul_`에 전달하게 됩니다. 이 문제는 실제 클리핑(`max_grad_norm > 0`)과 로깅 목적으로만 `inf`를 사용해 클리핑을 호출하는 `_get_grad_norm()` 양쪽 모두에서 발생하므로, `max_grad_norm: 0.0`만 설정하는 것으로는 충분하지 않습니다.

gradient clipping을 비활성화한 상태의 임시 해결 방법:
1. 학습/YAML 설정에서 다음을 설정합니다:
```yaml
max_grad_norm: 0.0
```
2. 학습을 시작하기 전에 로깅 전용 gradient-norm 호출을 패치합니다:
```python
from transformers import Trainer

_orig_get_grad_norm = Trainer._get_grad_norm

def _safe_get_grad_norm(self, model, grad_norm=None):
    try:
        return _orig_get_grad_norm(self, model, grad_norm)
    except RuntimeError as e:
        if "DTensor" in str(e):
            return None
        raise

Trainer._get_grad_norm = _safe_get_grad_norm
```
이 방법을 사용하면 LoRA SFT를 실행할 수 있지만 gradient clipping은 수행되지 않으므로 프로덕션 품질의 학습에는 적합하지 않습니다.

올바른 수정 방법: FSDP2가 활성화된 경우 ktransformers expert-LoRA 파라미터를 replicated `DTensor` 파라미터로 등록하여 `model.parameters()`의 타입을 동일하게 만드는 것입니다. 또는 해당 expert-LoRA 파라미터를 Trainer/accelerate 클리핑 목록에서 제외하고 일반 텐서로 별도로 클리핑할 수 있습니다. 두 접근 방식 모두 클리핑과 gradient-norm 로깅 호출 지점을 모두 처리하며 `max_grad_norm > 0`을 복원합니다.

ktransformers

개요

README 미리보기

FAQ (5)

同类型项目

tensorflow

superpowers

everything-claude-code

flutter