GPT가 자동 생성한 주석이나 기존에 정의된 상수를 중복해서 작성한 코드가 보여서, 이런 부분은 삭제가 필요하다고 생각함. 예를 들어, const MAX_SEQ_LEN: usize = 80 같은 상수들은 이미 lib.rs에 있으니 주석에서 안내한 대로 해당 상수들을 그대로 사용하는 것이 낫다고 봄
이런 부분이 남아 있는 것은 개발자가 실제로 이해하고 만든 결과물이 아님을 보여주는 지점이라고 생각함
혹시 관련 PR을 보냈는지 궁금함
상수 사용 방식에 대해서는, 저자도 그냥 방법을 몰라서 그랬을 수도 있다고 생각함. 나도 Rust 첫 주에는 이름 붙이기나 코드 구조에 대해 고민이 많았던 기억이 있음
vibe코딩 스타일의 Rust가 언어의 전반적인 코드 품질을 떨어뜨릴지도 모른다는 생각은 어떤지 궁금함
이 지적이 정말 맞는 말이라고 생각함
Python 의존성 지옥에서 며칠을 소모한 경험이 있어서, cargo run 한 번이면 끝나는 Rust 방식이 정말 꿈만 같음. 하지만 프레임워크 없이 맞닥뜨린 가장 고통스러운 부분이 궁금함. 내기하자면 백프로파게이션 로직 디버깅이 아닐지 예상함
uv라는 도구를 추천함. 직접 써본 결과 파이썬 프로젝트 실행이 90% 더 편해졌음 uv 바로가기
가장 힘든 점은 GPU 등 리소스 활용 쪽이라고 생각함
파이썬 의존성 문제 표현은 2010년 정도면 이해할 만했지만, 2025년엔 너무 심한 과장이라고 생각함
cargo run이 꿈 같다는데, 사실 cargo build 특유의 전체 인터넷을 재컴파일하면서 겨울에 CPU를 데워주는 경험이 더 낫다고 생각함
cargo를 칭찬하는 사람들은 의존성 관리의 트레이드오프를 잘 모르는 경우가 많다고 느껴짐. C처럼 모든 라이브러리를 매번 새로 만드는 것도 비효율이지만, npm이나 cargo처럼 너무 쉽게 의존성을 가져오게 되면 정작 의존성의 난립, 빌드 타임, 보안문제 등의 심각한 단점이 생긴다고 생각함. 빌드 시스템이 좋다는 게 의존성 추가가 쉬운 것과 반드시 같은 개념은 아니며, 중앙집중 패키지 저장소에서 아무나 의존성을 얽는 방식 역시 건강한 패턴은 아니라고 봄
비슷한 Rust 프로젝트를 진행 중임. 웹어셈블리로 브라우저에서 구동되는 버전이 있으며 브라우저 데모와 소스코드도 공개함
ndarray, rand, rand_distr 패키지 구성이 깔끔해 보임
curiosity에 의해 cargo tree로 의존성 트리를 살펴봤는데, 아직까진 깔끔한 상태로 보임
이 트리가 대단한 의미는 없다고 생각함. 직접 구현을 비효율적으로 해둔 코드일 수도 있고, 경우에 따라 외부 라이브러리를 적절히 쓰는 게 오히려 더 나을 수도 있다고 봄
이 평가가 풍자인지, 아니면 맥락이 더 필요한지 궁금함
Rust의 메모리 안전성이 트랜스포머 구현에서 버퍼 오버플로우를 줄이는 데 꽤 유용하다고 생각함. CUDA 커널은 여전히 성능에서는 우위임. 토크나이저도 BPE를 새로 만드는지, 아니면 기존 라이브러리를 사용하는지 궁금함
축하의 뜻과 함께, LLM에서 transformer block을 재사용하지 말고 각각 인스턴스를 달리하는 게 좋겠다는 사소한 지적을 하고 싶음. 나 역시 예전에 Zig와 MLX로 비슷하게 기초를 쌓아가는 실습을 해봤고, 이후 점점 기능을 추가하다가 PyTorch/Transformers 쪽으로 갈아탐
단, 이런 실습은 직접 코드를 작성할 때만 의미가 있다고 생각함. GPT의 도움을 받지 않고 스스로 만드는 경험에 의미가 있음
절차적/객체지향 스타일이 강해서, 엄밀히 좋은 Rust 스타일이라고 하긴 힘듦. 반복자(Iterators)나 enum을 쓰는 함수형 스타일이 더 간결하고 이상적이라고 여겨짐. 하지만 아이디어 실험으로선 충분히 괜찮음
Rust가 이렇게 읽기 쉽게 될 수 있다는 걸 몰랐음. 오히려 Rust 엔지니어들이 이런 심플한 코드를 피해서 일종의 자학 컨테스트를 하고 있다는 인상도 받음. Rust 커뮤니티와 채용 문화 등에서 겪었던 경험이 모두 이해됨
데이터셋 출처가 궁금함. 직접 찾아볼 예정이지만, 질문을 남겨봄. 나는 CPU 위주로 동작하고 백프로파게이션이 없는 아키텍처를 개발했으며, 클래시피케이션 데이터셋에서 잘 돌아감. 단일 예제 인크리멘탈 업데이트가 가능해서 지속학습에도 쓸 수 있을 듯함. toy demo로 tiny.txt에 대해 트레이닝해본 경험만 있고, 대형 언어모델(LLM)은 시도해 본 적 없음. 내 아키텍처가 온디바이스나 온프레미스 도우미로 꽤 잘 작동할 것 같아서 계속 실험할 예정임. 추천할만한 오픈소스 LLM 트레이닝 데이터셋이 있을지 궁금함
huggingface에는 다양한 openai, anthropic 사용자-보조자 체인이 있는데, 주의할 점은 환각(hallucination)이 많다는 것임. instruction fine-tuning 용으론 꽤 괜찮음. 원하는 게 instruction following이면 kimi k2 distillation을 추천함
본 프로젝트는 main.rs 파일 안에 바로 학습 데이터를 포함하고 있음. 내용은 일반 상식에 대한 짧은 문장 50개 남짓이며, 아마도 학습 시간을 줄이기 위한 선택인 듯 보임. 그래서 스크립트 기반이 아니면 성능이 급격히 나빠짐. 예시 프롬프트와 결과:
"hello" 입력시: "Eclipses occur when one celestial body moves into the shadow of another" 등 잘 맞음
"what are facts" 입력시: 의미 없는 단어 나열이 반복됨
"how are mountains formed?" 입력시: 일관성 없는 단어와 의미없는 출력이 나옴
Hacker News 의견
GPT가 자동 생성한 주석이나 기존에 정의된 상수를 중복해서 작성한 코드가 보여서, 이런 부분은 삭제가 필요하다고 생각함. 예를 들어,
const MAX_SEQ_LEN: usize = 80같은 상수들은 이미 lib.rs에 있으니 주석에서 안내한 대로 해당 상수들을 그대로 사용하는 것이 낫다고 봄Python 의존성 지옥에서 며칠을 소모한 경험이 있어서, cargo run 한 번이면 끝나는 Rust 방식이 정말 꿈만 같음. 하지만 프레임워크 없이 맞닥뜨린 가장 고통스러운 부분이 궁금함. 내기하자면 백프로파게이션 로직 디버깅이 아닐지 예상함
비슷한 Rust 프로젝트를 진행 중임. 웹어셈블리로 브라우저에서 구동되는 버전이 있으며 브라우저 데모와 소스코드도 공개함
ndarray,rand,rand_distr패키지 구성이 깔끔해 보임Rust의 메모리 안전성이 트랜스포머 구현에서 버퍼 오버플로우를 줄이는 데 꽤 유용하다고 생각함. CUDA 커널은 여전히 성능에서는 우위임. 토크나이저도 BPE를 새로 만드는지, 아니면 기존 라이브러리를 사용하는지 궁금함
나도 Rust로 picogpt를 만들면서 jaykmody의 GPT from scratch 블로그를 많이 참고했음. 프로젝트 링크
축하의 뜻과 함께, LLM에서 transformer block을 재사용하지 말고 각각 인스턴스를 달리하는 게 좋겠다는 사소한 지적을 하고 싶음. 나 역시 예전에 Zig와 MLX로 비슷하게 기초를 쌓아가는 실습을 해봤고, 이후 점점 기능을 추가하다가 PyTorch/Transformers 쪽으로 갈아탐
프로젝트 저자의 코멘터리가 Reddit에 정리되어 있음
전체 프로젝트가 정말 읽기 쉬운 구조임이 마음에 듦
데이터셋 출처가 궁금함. 직접 찾아볼 예정이지만, 질문을 남겨봄. 나는 CPU 위주로 동작하고 백프로파게이션이 없는 아키텍처를 개발했으며, 클래시피케이션 데이터셋에서 잘 돌아감. 단일 예제 인크리멘탈 업데이트가 가능해서 지속학습에도 쓸 수 있을 듯함. toy demo로 tiny.txt에 대해 트레이닝해본 경험만 있고, 대형 언어모델(LLM)은 시도해 본 적 없음. 내 아키텍처가 온디바이스나 온프레미스 도우미로 꽤 잘 작동할 것 같아서 계속 실험할 예정임. 추천할만한 오픈소스 LLM 트레이닝 데이터셋이 있을지 궁금함