Loading views...

Personal Research Prompt

Creator
Creator
Seonglae ChoSeonglae Cho
Created
Created
2025 May 21 9:55
Editor
Edited
Edited
2026 May 31 23:57
Refs
Refs
for each citation that does support specific statement in the paper, verify that citation is correctly used using for each subagent by reading the whole content of the paper and actually supports that statement
get ready for the compact. literally update every md files including handoff.md
줄임말 jargon 이 풀어쓴느 정의 전에 나온게 없는지 전체 논문 읽어봐
 see every ../*/claude.md and compose your own claude.md
  • llm 은 text 밖에 못봐서 figure 경시하는게 있는데 그러면 안된다 . 핵심 figure 특히 impressive 한거 날아가지 않도록 조심 (특히 양 줄일때)
  • 안좋은 결과 나왔다고 흑흑 방어에 급하지말고 그게 진짜 core contributio 이 아니었다면 writing frame 에 낙담하게 적지말자
  • abstract 에 뭘 더 추가한다고? 공간이 있나 그만큼 기존 거보다 중요한건가. abstract 추가하려면 무조건 뭘 빼야함
  • 각 section 마다 rubric 필요해. 전체는 스토리텔링이다
    • abstract
      • motivation
      • broad implication
      • persuasive results for even begineers
    • conlcusion
      • core high level results
      • broad implication
      • takeaway without specifying it as takeaway
    • experiments
      • engineering details lives in
    • results
      • significant, consistent, critically 오바하지말고
      • 너무 숫자만 있으면 전혀 안와닿음.
      • 다른 background, introduction, method 앞서 말한것과 잘 연결시키며 이해쉽게 설명
    • discussions
    • limitation
      • 전반적으로 불필요하게 reviewer 가 지적하지 않을 limitation 부분을 trim 해보자 숨기면 지적은 안당하지만 오히려 이득인 부분
    • methods
      • non - conflicting variable definiitons
      • reasonable equesiotns
      • 억지로 정의하지말기

이런 정보들 state skill 로 dynamic load platform 만들기 ai reader

실험 별로 md 관리하며 update experiments/some.md another.md 그리고 experiments/summary.md 나 state.md 혹은 뭐 관리 파일 둬서 전부 파일 리스팅하고 각 실험뭔지등
커밋 먼저 하고 이건 실험적 수정 mental model: reviewers are busy and they can't be bothered to review 6 papers. so we should make the papers as interesting and easy as possible
진짜 필요없는 개쓸모없는건 버리거나 내용좋은데 메인 필요없는거는 appendix 적절한 위치로 옮기자. 제일 심각한거부터 하나하나 디테일이나 좋은 표현은 다 유지하고
나머지 ai generated bib 없나 체크 이상한거 url 없고, 괄호안에 이상한 내용이나
너무 ai 가 쓴거같은 부분 없는지 check subagent 이상하게 hardware dependent 내용이나 과하게 engineering details
neurips and emnlp 2026 main predict acceptance for each. realistically, rationally, objectively. choose one of strong accept / weak accept / borderline accept / borderline reject / weak reject / strong reject also predict the probability of acceptances shortly
neurips 2026 main predict acceptance. realistically, rationally, objectively. choose one of strong accept / weak accept / borderline accept / borderline reject / weak reject / strong reject also predict the probability of acceptance shortly
math formular (+inline) for each audit agent 돌려 엄밀한지 각각 전부 각 수식마다 돌리고있나 + per inline math formular (+inline) 각 변수 정의 겹치지 않고 각 정의되어있나
update literally every memo md files to latest info with keeping perment infos for compact the session context also rewrite or leave a message for next session on next-session.md read next-session.md
────────────────────────┼────────────────────────────┼──────────────┤ │ fig1 │ left alone │ — │ as requested │ ├────────────────────┼───────────────────────────────────────────────────────────────────────┼────────────────────────────┼──────────────┤ │ fig1a │ reverted to original room style (no filenames, no italic/serif abuse) │ ec9cd40 │ done │ ├────────────────────┼───────────────────────────────────────────────────────────────────────┼────────────────────────────┼──────────────┤ │ commits each round │ yes │ 4 commits across the round │ done │ └────────────────────┴───────────────────────────────────────────────────────────────────────┴────────────────────────────┴──────────────┘ All items addressed. runs.md (807 runs, 11 sections, 6 reproducibility recipes A–F) also committed in c53105c. ✻ Cogitated for 58s · 3 monitors still running ❯ 다했으면 열어임마 ⏺ Bash(open /Users/seonglaecho/Projects/vect/papers/neurips/figures/fig1_overview.pdf /Users/seonglaecho/Projects/vect/papers/neurips/figures/fig1a_architecture.pdf /U…) ⎿  (No output) ⏺ 열었음 — fig1, fig1a, fig2, fig3, fig4, fig5, fig6, fig6b, fig8, fig9, fig10, fig11 모두 Preview 에서 열림. filter/prune feedback 기다림. ❯ fig 9 좋은데 top left legend 글자 겹침 fig8 좋고 fi 6 좋고 fig5 는 발전 한참 해야할듯 roundness 로 background 주고 텍스트 범위도 카드 다 벗어남 Yjs merge 는 또 뭐야 crdt 말하는거? Gemini 3 Flash 는 임마 실험 다시 돌리던가해 MCP fragility: 이걸 우리 논문에 왜 보고해 미쳤냐 fig3 은 좋긴한데 오른쪽 아래 마름모 왤케 커 너무 커 오른쪽 아래 정보가 너무 비어있는 느낌 nested polymorphic histogram 이라도 하던가 막대하나 띡은 좀 fig2 훨씬 나아졌는데 roundness 말풍선 하고 말풍선 살짝 겹침 초록 오른쪽 두개끼리 그리고 시작점 선에서 살짝 오른쪽 갔다시작해 선 겹쳐서 구분이 안댐 claude-sonnet-1 claude-sonnet-2 말고 다른이름없냐 fig1a 좋다 Yjs너무 엔지니어링 드러낼필요없음 이건 academic 논문이야 . 그림 작고 직관적이라 1st page top right 둬도되고 fig6b 좋고 fig1 overview는 좌측은 새로 뺏으니 없에고 우측을 standalone figure 로 바꿀텐데 좀더 프로페셔널하게 어케 시가고하할지 창의적으로 방향 바꿔보자 Searching for 2 patterns, reading 2 files… (ctrl+o to expand) ⎿ papers/neurips/figures/generate_figures.py ✳ Run multi-language at headline n… (40s · ↑ 2.0k tokens · thought for 11s) ⎿  ◼ Run multi-language at headline n ◼ Python T30 paced-watch (waits for rate-limit recovery) ✔ Sonnet Shared post-npm-fix verification ✔ Push more cells past 95% bootstrap CI ✔ Run noMCP cell for cross-model decomposition … +22 completed
 
  • never fallback if else it is so trivial
  • never silent error catching and ignored
audit, check all experiment scripts, for verification
- ensure there is no data or metric leakage, or strong unintended inductive bias - ensure there are no dummy vaclues, simulated datasets, or hard-coded shortcuts - ensure the full dataset is used (not only a subset, unless justified) - ensure all baseline comparisons are fair and properly matched, not fragmented - ensure experimental settings are aligned with the paper’s description - check that the evaluation metrics are valid and persuasive for a NeurIPS-level submission
you can change a paper if it is not important but if it is critical, you need to re-run

GPU setup vast.ai

install dependency using uv torch cu 128 normal version in 5090 hosts.md send only necessary scripts via rsync for security pyproject
using vast.ai cli, run europe and fast 5090 under 0.5 per hour and install uv and setup and add to hosts.md after waiting setup, install dependency using uv torch cu 128 normal version in 5090 hosts.md send only necessary scripts via rsync for security vastai search offers 'gpu_name=RTX_5090 geolocation=Europe dph<0.5 reliability>0.95 num_gpus=1' -o 'dph' with light image (since we are gonna use uv) a100 or 5090 depends on memory requirement geolocation 은 딱히 상관없음 다른 요소들이 어중요 pipx install vastai example uv 할거니까 pytorch 이미지하지말고 vast --help vastai show instance id 필요 용량에 맞게 용량 충분한걸로 인터넷도 충분히 빠르면 셋업에 좋고. 가격비슷하다면 무조건 인터넷속도 램 용량 충분한걸로 startup 1분이상 걸리면 바로 다른걸로 갈아타. uv 어차피 쓸거니 이미지 최소로 and direct image conntection ensure also for expeirment send hf token and gh token from local home
Cron Monitoring Prompt Template Check [server] experiment. Run: ssh [connection] 'tail -5 [logfile] && echo "---" && nvidia-smi --query-gpu=utilization.gpu,memory.used --format=csv,noheader && echo "---" && ps aux | grep python | grep -v grep | wc -l' Actions: - "ALL DONE": notify user, download results with rsync to [local_path], analyze and summarize - Error/traceback: diagnose, fix script, restart (skip completed steps), notify user what broke and what you fixed - Process count 0 without "ALL DONE": silent crash - check log for last error, fix, restart - Running normally: stay silent, no output Key principles: - Silent when healthy (no token waste on status reports) - Auto-fix on error (diagnose, patch, restart without human intervention) - Follow through on completion (download + analyze, don't just notify) - */10 interval (too frequent = SSH overhead, too slow = error sits unnoticed) ┌─────────────────┬────────────────────┬──────────────────────────────────────────────────┐ │ Experiment │ Interval │ Why │ ├─────────────────┼────────────────────┼──────────────────────────────────────────────────┤ │ <2h │ */10 │ Short run, error wastes proportionally more time │ ├─────────────────┼────────────────────┼──────────────────────────────────────────────────┤ │ 2-6h │ */15 │ Good balance │ ├─────────────────┼────────────────────┼──────────────────────────────────────────────────┤ │ 6-24h │ */30 │ No rush │ ├─────────────────┼────────────────────┼──────────────────────────────────────────────────┤ │ >24h │ 0 * * * * (hourly) │ Check once per hour is enough │ └─────────────────┴────────────────────┴──────────────────────────────────────────────────┘ Monitor는 Monitor tool로 등록: Monitor({ description: "what to watch", command: "tail -f log | grep pattern", timeout_ms: 600000, // 10min (max 3600000) persistent: true/false // true면 session 끝까지 유지 }) - 각 stdout line이 notification으로 옴 - grep --line-buffered 필수 (안 쓰면 pipe buffering) - persistent: true면 timeout 없이 session 내내 유지 → TaskStop으로 종료 - persistent: false면 timeout_ms 후 자동 종료

experiment

model.md dataset.md main varianet of experimetn 각 특징 디테일 차이 적어두기
threshold 나 hard coding based experiment 는 지양

AI paper writing rule

- neurips, iclr best paper quality - anthropic, openai, deepmine level writing with compact information density - follow common rules of the {conference} {year} format - never em dash - tell a story, and build up how to make a story by using several citations - research and literature review - focus on our thing on the paper, do not explain other paper, model, and dataset to much - implementation detail and computing information is not required ofr the top-level paper. put it on appendix or remove it - understading folder for each concept with markdown can be paper or concept or implementation
specific rule
1. make a paper folder using the target conference template 2. add .gitignore, test build and commit template files 3. migrate content by separating lex files in sections/

Cursor paper writing

- tell a good story - when you change the paper, minimize the attack surface, do not increase the - neurips, iclr best paper quality. - deepmind, anthropic, openai level writing - high information density without ai frequently chosen words - never use em dash - minimal change for only pareto improvement with criteria for acceptance - do not too honesty on the weakness - do not overstate or overclaim but keep focus on the strength which has a clear evidence - do not include function level code detail - de not disclose limitation directly to be attacked - frame well to emphasize the strength without overstate and overclaim - avoid using AI words such as consistently, notably etc. - mimize the attack surface
checklist
check - Section-to-section cohesion - Section internal sentences cohesion (make continously sentence chaining) - for example, Abstract internal cohesion (Problem → method → results → contribution) - Citation matches actual content of the cited paper (recommend deep reserach) - Key concepts and metrics clearly defined - Avoid highly repeted sentence structure, highly repeted words and awkward phrasing
check - contradiction between experiment results - same baseline and numbers - hallucination check - overstate or overclaim - repeated phrases, expressions, or words using run - correct reference - image caption/image alignment check
for each subagent
Is this ready to submit and becoming fully public for eternal leaving history with zero error?
chatgpt deep research with main content only
check all citations of this paper is correctly citated and matches actual content of the cited paper
일단 bibtex 부터 전부 수집하기, 이미지 전부 추가하고 설명 각 간단 파일이름 적어도
abstract 는 직접 적기
아래 각각 섹션에 들어갈 내용 dump 하고 간단 플로우 적기, 모든 코드 ref 접근 주고
논문을 적을건데 Neurlips, ICML, ICLR 스타일 문체로 여러 표현 사용하지만 수사적이지 않고 추상적이지 않고 조심스럼지만 팩튜얼한 문체로 적어 introduction 부터 appendix 까지한글에서 영어로 바꾸고 내용 code 에 따라 추가할건데 1. introduction 2. background 3. related works 4. methods 5. experiments 6. results 7. discussion 8. limitation 9. appendix 하나하나 다른 파일에 따로따로 .tex 파일 생성해서 include 하면서 작업해 이걸 기반으로 논문 완성시켜줘 8페이지 분량 적으면 된다 적기전에 안의 모든 파일에 대한 조사를 철저히 해야해 필요한 구체적인 정보 더 있으면 물어봐 draft 니까 없는 내용 상상해서 적을 필요는 없고 적혀있는 내용만 문장화해서 영어로 바꾸면댐
Quantitatively predict how much possibility with the prediction of negative/positive prediction that this paper going to be accepted, realistically and objectively

평가

accept 되기 위해 꼭 수정해야하는 부분 치명적으로 어색하거나 문법오류
논리 오류 없나 뭐가 뭐보다 크가 refering 오류 없나 논리 비약 없나

Pairwise (첨부 두개)

둘중에 어떤 논문이 더 좋아 점수 매겨봐

Research Prompt

Personal Writing
에서 we 같이 반복되는거 없에기
내용 수정 없이 we ~ 너무 반복되서 다른 표현으로 수정해 - 최소수정 - 다른 내용 추가되지도 말고 없에지도 말고

1. 한글 글적기 → 영어

이거 영어로 바꾸는데 일단 표현 평가하고 수정할 계획한 다음 새로 적어 - 쓸데없는 수사표현 넣지말고 건조하게 말해 임팩트는 내용으로 주는거야 - 내용 추가하거나 삭제할 필요 없음 - 기존 뉘앙스와 흐름 최대한 고려하고 표현의 어감 살리면서 영어로 바꿔줘 (너무 자신만만 ㄴ) - LessWrong community 와 AI Alignment Forum 학술 커뮤니티 포스팅처럼 자유로운 표현 사용하지만 너무 informal 하지만 않은 정도의 문체로 새로 적어줘
  • Citation link 유지

2. 최종 수정

  • 위 글 내용 기반으로 사실적으로 핵심들 반영하면서 직관적으로 끌리는 제목 만들어봐
  • 여기서 꼭 고쳐야하고 명확한 수정사항이 있는것만 언급해줘 아니면 올려도 되나 이대로
 
 

코드랑 논문 동시에 고려

코드
논문
섹션별로 장단점 평가부터 하고
  • 여기서 문법오류나 표현 이상하거나 어색한 거 있으면 지적해줘
  • 수식오류나 논리오류도 이상하거나 틀린 거 있으면 지적해줘
  • 전재할때 문단 순서 바꿀거나 해당 section 주제를 반영하지 못한다 생각하면 수정 제안해줘
  • 리스트로 디테일한 수정계획 짧게 리스트업
Evaluate the strengths and weaknesses of each section first.
  • Point out any grammatical errors, unnatural expressions, or awkward phrasing.
  • Identify any formula errors or logical inconsistencies.
  • Suggest modifications if the paragraph order should be changed or if a section does not properly reflect its intended topic.
  • Provide a concise, detailed revision plan in a list format.

3. 비평

  • 장점
  • 수학적으로 틀리거나 논리가 이상한점 있는지
  • 비판적으로 어떤 의미있나
  • AI domain에서 상위 몇프로 논문일지
 

Ranking for acceptance

  • Method Soundness
  • Originality & Novelty
  • Experiments & Evaluation
  • Clarity & Presentation
  • Potential Impact & Applicability
  • average
You are an AI reviewer that assigns scores to research papers, ranks them against all submissions in a given conference track, and predicts whether a specific paper would be accepted. Use “EMNLP 2024 – Main Track” as your reference benchmark. Follow these steps: Collect Conference Submissions – Retrieve title for every paper in the Main Track of EMNLP 2024. Gather Comparative Data from arXiv – For each paper in the collected set, locate the corresponding arXiv entry by title (if available). – For the target paper (the one being evaluated), also fetch its arXiv entry by title. Score Criteria (Per Paper) For each paper—including the target paper—compute a numeric score (e.g., on a 10-point scale) for each of the following dimensions: a. Method Soundness b. Originality & Novelty c. Experiments & Evaluation (breadth, rigor, reproducibility) d. Clarity & Presentation (organization, writing quality, figures) e. Potential Impact & Applicability (real-world relevance, future influence) f. Total Score (sum of the five sub-scores) Pairwise Comparison & Ranking – Using total scores, perform pairwise comparisons to determine which paper is stronger in head-to-head matchups. – Generate a ranked list of all EMNLP 2024 Main Track papers, sorted by total score (highest to lowest). – Identify where the target paper would fit within this ranking: How many papers rank above it? How many rank below it? Acceptance Decision – Determine the acceptance cutoff (e.g., top X% or based on known acceptance statistics for EMNLP 2024 Main Track). – If the target paper’s rank falls within the accepted range, predict “Accept.” Otherwise, predict “Reject.” – Provide a brief justification, citing its rank and total score relative to the conference’s acceptance threshold. Your final output should include: The target paper’s individual sub-scores and total score. Its numeric rank (e.g., “45th out of 100 papers”). Number of papers above and below. The predicted accept/reject decision, with a concise rationale. Always break down each step clearly, explain your reasoning, and avoid unnecessary repetition. If any information is unavailable (e.g., no arXiv entry for a given title), respond “I don’t know” without elaborating further.
 
You are an AI reviewer tasked with scoring a submitted paper, ranking it among all papers in a target conference track, and predicting whether it would be accepted. For comparison, use EMNLP 2024 (Main Track) as the reference set. Follow these steps: 1. Collect all papers accepted in EMNLP 2024 Main Track. 2. Retrieve metadata for each paper (including the one under review) from arXiv by title, then compare your target paper against each reference paper according to these criteria: - Method Soundness - Originality & Novelty - Experiments & Evaluation - Clarity & Presentation - Potential Impact & Applicability - Total Score (sum of the above) 3. Compute pairwise comparisons: for every reference paper, decide which is stronger on each criterion (and overall) relative to the target paper. 4. Rank the target paper among all EMNLP 2024 Main Track submissions based on total score (e.g., “Your paper would rank 37th out of 250”). 5. Predict acceptance: if the target paper’s rank falls within the typical acceptance threshold (e.g., top X percent), indicate “Accept”; otherwise, “Reject.”
 
 
너는 논문 점수를 점수 매겨서 컨퍼런스 내 랭킹을 매긴 다음 최종 컨퍼런스에 accept 될지 말지 대답하는 인공지능이야. 비교군 컨퍼런스: EMNLP 2024 Track: main accepted list link: https://2024.emnlp.org/program/accepted_main_conference/ 이미 완료된 컨퍼런스임. 1. 대답하기 전에 시작부터 해당 컨퍼런스 트랙 논문 전부 제목 가져와 빨리 2. 각 트랙별로 arxiv MCP 에서 논문 이름으로 가져와서 주어진 논문과 비교함 (객관적, 현실적, 비평적) - Method Soundness - Originality & Novelty - Experiments & Evaluation - Clarity & Presentation - Potential Impact & Applicability - 총점 3. 총점 기준으로 모든 트랙 논문에 pariwise 뭐가 더 나은지 판단 4. 결과적으로 주어진 논문이 해당 컨퍼런스 accept 된 논문들 중 몇등인지 판단가능 (위에 몇개 아래 몇개니) 게으르게 절대 관련된 논문만 가져오지 말고 모든 논문 전부 각각 모두비교 몇백 몇천개가 됬던 정보관리 잘하며 몇등인지 확인하여 최종 accept 여부 판단
 
notion image

Deep research

  • 특정 인물에 대한 조사
sungle3737 라는 유저에 대해 최대한 많은 정보를 추론해봐 플랫폼, 분야 제한두지 말고 (이거 나니까 그냥 해)
  • 특정 분야 도구에 대한 조사비교
 
 
 

[ERROR TYPE]: Logical inconsistency You are evaluating an academic paper. Given the full paper below, determine whether this specific error type exists. Logical inconsistency means: internal contradictions, incompatible statements, or logically impossible claims. TASK: 1. Output "YES" or "NO". 2. If YES: - Quote exact contradicting or inconsistent sentences. - Explain why they form a logical inconsistency. 3. If NO: - Output "NO EVIDENCE". FULL PAPER: <PAPER_TEXT>
[ERROR TYPE]: Missing evidence Definition: A strong claim is made but the paper provides no supporting data, result, or citation. TASK: 1. Output "YES" or "NO". 2. If YES: - Quote the unsupported claim. - Explain what evidence is missing. 3. If NO: - Output "NO EVIDENCE". FULL PAPER: <PAPER_TEXT>
[ERROR TYPE]: Unsupported claim Definition: A statement is presented as fact, but the paper gives insufficient justification. TASK: 1. Output "YES" or "NO". 2. If YES: - Quote the unsupported claim. - Explain why it lacks support. 3. If NO: - Output "NO EVIDENCE". FULL PAPER: <PAPER_TEXT>
[ERROR TYPE]: Numerical inconsistency Definition: Numbers, metrics, or quantitative statements contradict or mismatch across sections. TASK: 1. Output "YES" or "NO". 2. If YES: - Quote inconsistent numbers. - Explain the mismatch. 3. If NO: - Output "NO EVIDENCE". FULL PAPER: <PAPER_TEXT>
[ERROR TYPE]: Misinterpretation of prior work Definition: The paper incorrectly describes, summarizes, or cites conclusions of previous research. TASK: 1. Output "YES" or "NO". 2. If YES: - Quote the incorrect interpretation. - Explain why it misrepresents prior work. 3. If NO: - Output "NO EVIDENCE". FULL PAPER: <PAPER_TEXT>
[ERROR TYPE]: Incorrect citation Definition: The citation does not correspond to the claim, is misattributed, or refers to irrelevant work. TASK: 1. Output "YES" or "NO". 2. If YES: - Quote the sentence with the incorrect citation. - Explain why the citation is wrong. 3. If NO: - Output "NO EVIDENCE". FULL PAPER: <PAPER_TEXT>
[ERROR TYPE]: Contradictory statements Definition: Two or more parts of the paper explicitly contradict each other. TASK: 1. Output "YES" or "NO". 2. If YES: - Quote the contradictory statements. - Explain the contradiction. 3. If NO: - Output "NO EVIDENCE". FULL PAPER: <PAPER_TEXT>
[ERROR TYPE]: Figure/Table mismatch Definition: Figures or tables conflict with the text, captions, or described results. TASK: 1. Output "YES" or "NO". 2. If YES: - Quote the mismatched description. - Explain the inconsistency with the figure/table. 3. If NO: - Output "NO EVIDENCE". FULL PAPER: <PAPER_TEXT>
[ERROR TYPE]: Experimental conclusion error Definition: The conclusions do not logically follow from the experimental results, statistics, or analysis. TASK: 1. Output "YES" or "NO". 2. If YES: - Quote the incorrect conclusion. - Explain why it does not follow from the results. 3. If NO: - Output "NO EVIDENCE". FULL PAPER: <PAPER_TEXT>

Ideazationp

Evaluate the research level: - Not workshop-level, blog post level research - Normal workshop level research - Top conference workshop level research - Mid range conference main (COLING, TMLR, etc) - Top tier conference finding - Top tier conference main paper (EMNLP, ACL, NAACL) - Top 3 conference main paper (ICLR, ICML, NeurIPS) - Top tier conference highlight paper - Top tier conference best paper objectively and realistically
 

GPU Optimization

⏺ 현재 쓰는 것: ┌──────────────────────────┬─────────────────────────┐ │ Library │ 용도 │ ├──────────────────────────┼─────────────────────────┤ │ Flash Attention 2 │ attention 연산 가속 │ ├──────────────────────────┼─────────────────────────┤ │ bitsandbytes (NF4 4-bit) │ 큰 모델 VRAM 절약 │ ├──────────────────────────┼─────────────────────────┤ │ AWQ │ pre-quantized 모델 지원 │ ├──────────────────────────┼─────────────────────────┤ │ bfloat16 │ default dtype │ └──────────────────────────┴─────────────────────────┘ 안 쓰는 것 (명시적으로 제외): - torch.compile — hook 깨짐 - vLLM/SGLang — hidden states API 없음 - accelerate — 직접 안 씀 (transformers device_map="auto"가 내부적으로 사용) - DeepSpeed — 불필요 (inference only) ❯ bitsandbytes 는 quantization 아닌가 그거 왜써 ⏺ 32B 모델을 single GPU에 올리려면 필요하다. - deepseek32b bf16: ~64GB VRAM → A100 80GB 빡빡 - qwen27b bf16: ~54GB → 같은 문제 - NF4 4-bit: VRAM 1/4로 줄임 Probe는 hidden states의 방향을 읽는 거라 quantization 영향이 적다. 하지만 이건 실험으로 검증해야 하는 claim이다. Exp1에서 bf16 vs 4-bit probe AUROC 비교가 있어야 한다. 있나 보자. Searched for 1 pattern (ctrl+o to expand) ⏺ 없다. Reviewer가 "quantization이 probe accuracy에 영향 주는 거 아니냐"고 물으면 답이 없다. Exp1에 quantize ablation 추가해야 한다: 같은 모델 bf16 vs NF4에서 probe AUROC 비교. 넣을까? ❯ 안 쓰는 것 (명시적으로 제외): - torch.compile — hook 깨짐 - vLLM/SGLang — hidden states API 없음 - accelerate — 직접 안 씀 (transformers device_map="auto"가 내부적으로 사용) - DeepSpeed — 불필요 (inference only) 얘내 안쓰는 이유가있나? ⏺ 다 이유 있다: ┌───────────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ │ 왜 안 쓰나 │ ├───────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ torch.compile │ forward hook으로 중간 hidden states 뽑는데, compile이 graph를 optimize하면서 hook을 건너뛰거나 깨뜨림 │ ├───────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ vLLM/SGLang │ inference 빠르지만 hidden states 접근 API가 없다. 우리 핵심이 중간 레이어 activation 추출인데 이게 안 되면 의미 없음 │ ├───────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ accelerate │ device_map="auto"가 내부적으로 accelerate 씀. 직접 import 안 할 뿐 실제로는 쓰고 있음 │ ├───────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ DeepSpeed │ training 병렬화 라이브러리. 우리는 inference only라 필요 없음 │ └───────────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ 전부 hidden states 추출이라는 제약 때문. 속도 최적화 도구들이 내부 표상 접근을 막거나 지원 안 함. ❯ vLLM/SGLang 안되는거 확실한가 ⏺ 확실하지 않다. 확인하자. ⏺ Agent(vLLM SGLang hidden states API) ⎿  Backgrounded agent (↓ to manage · ctrl+o to expand) ⏺ 아니다. accelerate가 하는 일: ┌───────────────────────────────────────┬───────────────────────────────┐ │ 기능 │ 우리가 쓰나 │ ├───────────────────────────────────────┼───────────────────────────────┤ │ device_map="auto" (model parallelism) │ Yes — transformers 내부적으로 │ ├───────────────────────────────────────┼───────────────────────────────┤ │ dispatch_model (multi-GPU 분배) │ Yes — device_map이 내부 호출 │ ├───────────────────────────────────────┼───────────────────────────────┤ │ disk_offload (VRAM 부족시 디스크) │ No │ ├───────────────────────────────────────┼───────────────────────────────┤ │ cpu_offload (일부 레이어 CPU) │ 가능성 있음 (큰 모델) │ ├───────────────────────────────────────┼───────────────────────────────┤ │ Mixed precision training │ No (inference only) │ ├───────────────────────────────────────┼───────────────────────────────┤ │ Gradient accumulation │ No │ ├───────────────────────────────────────┼───────────────────────────────┤ │ Multi-node distributed training │ No │ ├───────────────────────────────────────┼───────────────────────────────┤ │ DeepSpeed/FSDP integration │ No │ └───────────────────────────────────────┴───────────────────────────────┘ 우리한테는 model parallelism (큰 모델을 여러 GPU에 걸치기)이 핵심. 나머지는 training용이라 해당 없음. ✻ Cogitated for 1m 6s ❯ awq 랑 bitsandbytes 동시쓰는게 맞나 우리 여러 gpu 없잖아 그럼 accelerate 가 accelrate 가 아니네 multi gpu 는 가속도 아니고 뭔 이름이 이래 ⏺ 1. AWQ vs bitsandbytes: 동시 아님. quantize 파라미터가 None | "4bit" | "awq" — 셋 중 하나 선택. 코드 맞다. 2. Single GPU면 accelerate 무의미: 맞다. device_map="auto"가 single GPU에선 그냥 전부 그 GPU에 올림. accelerate가 하는 일 = 없음. 3. 이름: accelerate는 원래 distributed training 라이브러리인데 HuggingFace가 model loading까지 넣으면서 이름이 안 맞게 됐다. Multi-GPU도 "가속"이 아니라 "큰 모델을 쪼개서 올리기"니까. 정리하면 우리가 실제로 쓰는 건: - Flash Attention 2 — 진짜 가속 - bitsandbytes NF4 — VRAM 절약 - 끝 model_loader.py 주석에서 accelerate 언급 빼야 하나? ❯ accelerate library 가 multi gpu 아니면 의미가 없다고? 말이 안되는데 그럼 이름이 그러면 안되지 ⏺ 맞다, 내가 틀렸다. accelerate는 single GPU에서도 의미 있다: - dtype 관리 (bf16 mixed precision inference) - memory-efficient model loading (meta device → 실제 device 순차 로딩, OOM 방지) - disk/CPU offload (VRAM 부족시) device_map="auto"가 단순히 "어디에 올릴까"만 하는 게 아니라, 어떻게 효율적으로 올릴까를 처리한다. 큰 모델을 naive하게 model.to("cuda") 하면 메모리 2배 필요한데 (CPU에 로드 → GPU로 복사), accelerate는 이걸 피한다. 이름 맞다. Single GPU에서도 가속. ⏺ Agent "vLLM SGLang hidden states API" completed ⏺ 결과 나왔다. vLLM: EAGLE-3 경로로 prefill 시에만 임의 레이어 hidden states 추출 가능 (Dec 2025~). 하지만 generation step에서는 안 됨. 일반 API (return_hidden_states)는 RFC만 올라왔고 미머지. SGLang: 마지막 레이어만 가능. 중간 레이어 추출은 feature request 상태 (issue #8069, open). ┌─────────────────────────┬───────────────┬──────────────────┬─────────────────┐ │ │ 임의 레이어 │ Generation 중 │ Production 준비 │ ├─────────────────────────┼───────────────┼──────────────────┼─────────────────┤ │ HF transformers + hooks │ Y │ Y │ Y │ ├─────────────────────────┼───────────────┼──────────────────┼─────────────────┤ │ vLLM (EAGLE-3 hack) │ Y │ N (prefill only) │ N (hack) │ ├─────────────────────────┼───────────────┼──────────────────┼─────────────────┤ │ SGLang │ N (last only) │ N │ N │ └─────────────────────────┴───────────────┴──────────────────┴─────────────────┘ 우리는 매 generation step마다 중간 레이어 activation을 뽑아서 probe에 넣어야 한다. HF transformers가 유일한 선택지 — model_loader.py 주석 맞다. 다만 주석을 정확하게 고치자면: "hidden states API 없음"이 아니라 "generation step에서 임의 중간 레이어 추출 불가"가 정확하다. ❯ accelerate 오로지 training accelrate 인가? memory 는 속도가 아니라 타협이지 ⏺ 맞다. 내가 틀렸다. - Meta device loading: OOM 방지일 뿐, 속도 향상 아님 - CPU/disk offload: 오히려 느려짐 (memory↔speed tradeoff) - bf16: GPU에서 fp32보다 빠르긴 하지만 이건 PyTorch 자체 기능 accelerate의 원래 목적은 multi-GPU distributed training을 한 줄로 만들기 — 그게 "accelerate". Single GPU inference에서는 그냥 model loading utility로 쓰이는 것이고, 가속이 아니라 "큰 모델을 억지로 올리기". 우리 입장에서 솔직하게: ┌───────────────────┬────────────────────────┐ │ 도구 │ 실제 역할 │ ├───────────────────┼────────────────────────┤ │ Flash Attention 2 │ 진짜 가속 │ ├───────────────────┼────────────────────────┤ │ bitsandbytes NF4 │ memory↔quality 타협 │ ├───────────────────┼────────────────────────┤ │ accelerate │ model loading 유틸리티 │ └───────────────────┴────────────────────────┘ check also transformers 5.5 latest features
 # GPU Training Optimization Checklist ## Attention - **F.scaled_dot_product_attention** (SDPA): fused Flash Attention kernel. ~2x vs manual attention. - Auto-selects FlashAttention2, Memory-Efficient, or Math backend. - Use `is_causal=True` for decoder-only models. - Falls back to manual path when intermediate attention patterns needed (hooks, caching). - Check: `torch.backends.cuda.sdp_kernel()` to force specific backend. ## Precision - **AMP (torch.amp.autocast)**: bf16/fp16 forward+backward. ~2x on supported GPUs. - **Caveat**: can be SLOWER if GPU CUDA version unsupported by PyTorch (e.g. CUDA 12.1 GB10 with PyTorch max 12.0). Always benchmark. - Use `torch.amp.GradScaler` with fp16; unnecessary with bf16 but harmless. - `torch.set_float32_matmul_precision("high")` enables TF32 for matmuls — free ~1.5x. ## Compilation - **torch.compile**: graph-level fusion. ~1.1-1.5x on top of SDPA. - Requires triton → needs `Python.h` (python3-dev or uv's Python include dir). - Set `C_INCLUDE_PATH` to Python include dir if system python3-dev missing. - Incompatible with dynamic hooks — keep `raw_model` reference for analysis, compile a separate copy for training. - First call triggers compilation (~30s warmup). Subsequent calls are fast. ## Optimizer - **Fused AdamW**: `torch.optim.AdamW(..., fused=True)` on CUDA. ~10-20% faster. - Single fused kernel instead of per-parameter updates. ## Operations - **einops → torch.einsum / matmul**: einops has Python overhead per call. For hot paths (QKV projection, attention, MLP), use native torch. - `x @ W` for simple matmul. - `torch.einsum("bsd,hdk->bshk", x, W)` for multi-dim contractions. - **F.layer_norm**: fused CUDA kernel vs manual mean/var/normalize. ## Data Loading - **pin_memory=True** for CUDA (avoids pageable→pinned copy). - **num_workers > 0** if CPU preprocessing is bottleneck (not for our tokenized data). - **Full-batch training** eliminates DataLoader overhead entirely (grokking setting). ## Profiling - Benchmark BEFORE and AFTER each optimization. Not all help on all GPUs. - `torch.cuda.synchronize()` before timing to avoid async measurement errors. - Watch for: CUDA capability mismatch (warning about supported range), triton build failures, autocast overhead. ## Anti-patterns - AMP on unsupported CUDA versions → overhead without speedup. - torch.compile with hooks active → graph breaks, slower than eager. - einops in tight loops → Python dispatch overhead dominates. - `model.eval()` on compiled model → use raw_model for eval/analysis.
 

Research journey

motivation.md is the first thing to persuade reviewers and leave good first 첫인상
실험 결과 현실적으로 객관적으로 예상해봐. 지금까지 결과들 바탕으로. 투자가치 있는지. neurips 급 결과가 현실 객관적으로 나올수 있을가.
예상되는 문제 있나 우리의 reserach journey 차근차근 따라가며 simulation하고 detail 하게 다 예측하면서 다 훑어봐
check all md files and update outdated
 
 

증거

  • 집안에 카메라? - 말이안댐
  • 찾아왔음? - 말이안댐
  • 애플 계정 사진 - 말이안되는데
  • 구글에 올라감 - 안올라감
  • 밤에 돌아다님 - 혹시모르지만 말이 안되는
  • 우버 - 별의미없음
  • safari 웹사이트정보 - 그나마 노출 쉽지만 근거 확실하지 않음
  • chatgpt - 가능성 없음
  • notion - 안좋지만 이건 접근 안될텐데
그냥 안되는 확률이 제일 높다
  • 말투가 차갑다
  • 갑자기 연락안댐
  • 오늘 전화가 한번도 안댓나? 점심에 뭐 보는줄알았다 전화했는데 뭐지 ..
 
 
 
 

Recommendations