Skip to content
←

Split View: 기술 리포트 비판적으로 읽기 — 무엇이 적히고 무엇이 빠지는가

✨ Learn with Quiz
|

기술 리포트 비판적으로 읽기 — 무엇이 적히고 무엇이 빠지는가

들어가며

시리즈의 마지막입니다. 지금까지 config.json과 기술 리포트에서 수십 개의 숫자를 가져와 계산했습니다. 이번 글은 그 과정에서 쓴 판단 기준을 정리합니다. 어떤 숫자를 믿고, 어떤 숫자를 유보하고, 어떤 숫자는 아예 쓰지 않았는지에 대한 이야기입니다.

수치는 2026-08-12에 논문·공식 리포트·config.json에서 직접 확인했습니다. 모델은 갱신되므로 원본을 다시 확인하세요.

검증 가능한 것과 그렇지 않은 것

기술 리포트의 내용은 검증 난이도에 따라 세 층으로 나뉩니다.

첫째 층은 즉시 검증 가능한 것입니다. 층 수, 헤드 수, 어휘 크기, 전문가 수 같은 구조 값입니다. 공개된 config.json과 대조하면 몇 초 만에 확인됩니다. 이 시리즈에서 Qwen3와 DeepSeek-V3, Kimi K2의 리포트 표와 config를 대조했을 때 모두 일치했습니다.

둘째 층은 계산으로 검증 가능한 것입니다. 파라미터 수가 대표적입니다. 첫 글에서 config만으로 Qwen3-8B의 파라미터를 8,190,735,360으로 계산했고, 저장소가 보고하는 값과 정확히 일치했습니다. Mixtral-8x7B와 Qwen3-30B-A3B도 마찬가지였습니다. 세 모델 모두 오차 없이 맞았다는 것은 리포트가 밝힌 구조가 실제 가중치와 일치한다는 뜻입니다.

셋째 층은 검증 불가능한 것입니다. 학습 토큰 수, 데이터 혼합 비율, GPU 시간, 벤치마크 점수가 여기 속합니다. 이 값들은 리포트를 믿는 것 외에 확인할 방법이 없습니다.

자체 보고 벤치마크의 한계

셋째 층에서 가장 자주 인용되고 가장 주의해야 할 것이 벤치마크 점수입니다. 이 시리즈가 벤치마크 점수를 거의 인용하지 않은 이유가 있습니다.

모델 개발팀이 자기 모델을 평가해 발표한 수치는 독립적인 평가가 아닙니다. 이것은 부정직하다는 뜻이 아니라 구조적인 한계입니다. 평가 프롬프트, 사용한 예시 수, 디코딩 설정, 채점 방식이 팀마다 다르고, 비교 대상 모델은 대체로 그 팀이 실행하거나 다른 리포트에서 인용해 온 값입니다.

이 시리즈에서 유일하게 인용한 성능 수치는 Kimi K2 리포트의 데이터 재작성 실험이었습니다. 원본 10에폭, 1회 재작성 후 10에폭, 10회 재작성 후 1에폭에서 각각 23.76, 27.39, 28.94라는 값입니다. 이것을 인용한 이유는 모델 사이의 우열이 아니라 같은 팀이 같은 조건에서 통제한 비교였기 때문입니다. 그때도 저자 자체 실험이며 독립 평가가 아니라고 명시했습니다.

읽는 요령은 간단합니다. 점수를 볼 때 누가, 어떤 설정으로 측정했는지를 먼저 찾으세요. 그 정보가 없으면 그 점수는 비교에 쓸 수 없습니다.

config와 리포트가 어긋날 때

이 시리즈에서 실제로 마주친 불일치가 둘 있습니다.

첫째, Qwen3의 어휘 크기입니다. config의 vocab_size는 151936이지만 리포트는 151,669라고 적습니다. 토크나이저 파일을 직접 열어 보니 151,669였습니다. 결론은 둘 다 맞다는 것입니다. 서로 다른 것을 재고 있었을 뿐입니다. config는 임베딩 행렬 크기를, 리포트는 토크나이저 어휘 수를 말합니다.

둘째, Qwen3-8B의 문맥 길이입니다. config의 max_position_embeddings는 40960이고 리포트 표 1은 128K로 적습니다. 리포트 본문을 읽으니 장문맥 학습은 32,768에서 했고 추론 시 YaRN과 DCA로 네 배를 확보한다고 되어 있었습니다. 여기서도 결론은 같습니다. 서로 다른 것을 말하고 있었습니다.

이 두 사례의 교훈은 하나입니다. 불일치를 발견하면 어느 쪽이 틀렸는지 묻기 전에, 두 값이 같은 대상을 재고 있는지부터 확인하세요. 대개는 정의가 다릅니다.

확인할 수 없었던 것

정직한 글쓰기의 핵심은 확인하지 못한 것을 확인하지 못했다고 적는 일입니다. 이 시리즈에서도 그런 항목이 있었습니다.

Llama 3.1과 Gemma 2의 config.json은 접근이 제한되어 읽을 수 없었습니다. Llama 3.1의 경우 기술 리포트 표 3에 구조 값이 모두 실려 있어 그것을 출처로 삼았고, 본문에서도 config가 아니라 표 3에서 가져왔다고 밝혔습니다. Gemma 2는 config도 읽을 수 없었고 이 시리즈의 주제에 필요한 값을 확보하지 못해 아예 다루지 않았습니다.

이것이 이 시리즈가 지킨 규칙입니다. 확인하지 못한 값은 비워 두거나, 그 모델을 다루지 않습니다. 그럴듯한 숫자를 채워 넣으면 글은 매끄러워지지만 독자가 그 글을 근거로 판단할 수 없게 됩니다.

리포트에서 자주 빠지는 것

여러 리포트를 나란히 읽으면 공통적으로 비어 있는 칸이 보입니다.

가장 큰 공백은 데이터 혼합 비율입니다. 어떤 출처의 데이터를 몇 퍼센트씩 썼는지 정확히 밝히는 리포트는 드뭅니다. 도메인 이름 정도만 나열되는 경우가 많습니다.

둘째는 실패 기록입니다. 최종 설정만 적히고 무엇을 시도했다가 버렸는지는 대개 빠집니다. 예외적으로 Kimi K2 리포트가 어텐션 헤드를 두 배로 늘렸을 때 검증 손실이 0.5에서 1.2퍼센트만 낮아져 추론 비용을 정당화하지 못했다고 적은 것은 드문 사례입니다. 이런 서술이 있으면 결정의 근거를 독자가 검토할 수 있습니다.

셋째는 평가 조건의 세부입니다. 점수는 큼직하게 실리지만 프롬프트와 디코딩 설정은 부록에 있거나 없습니다.

좋은 리포트의 신호

반대로 신뢰도를 높이는 서술도 있습니다.

값이 학습 도중 바뀌었다고 적는 경우입니다. DeepSeek-V3 리포트가 편향 갱신 속도를 14.3조 토큰까지 0.001로 두었다가 이후 0으로 바꿨다고 적은 것이 예입니다. 이런 서술은 꾸며내기 어렵고 재현에 실질적으로 도움이 됩니다.

한계를 스스로 적는 경우도 마찬가지입니다. Kimi K2 리포트가 합성 데이터를 계속 확장하는 전략은 여전히 활발한 연구 영역이며, 다양한 출처로 일반화하면서 사실성을 해치지 않는 것과 환각을 줄이는 것이 핵심 과제라고 적은 부분이 그렇습니다.

수치에 조건을 붙이는 경우도 좋은 신호입니다. Kimi K2가 헤드 수를 늘렸을 때의 연산량 증가를 말하면서 시퀀스 길이 128k, 전체 전문가 384개 고정이라는 조건을 함께 적은 것이 그렇습니다. 조건 없는 배수는 해석할 수 없습니다.

스스로 확인하는 절차

마지막으로 이 시리즈에서 실제로 쓴 절차를 정리합니다.

첫째, config.json을 직접 받습니다. 모델 저장소의 원본 파일 주소로 접근하면 가중치를 내려받지 않고도 구조를 볼 수 있습니다.

둘째, 파라미터를 손으로 세어 공개 값과 맞춰 봅니다. 맞으면 그 config를 제대로 읽은 것이고, 리포트의 구조 서술도 검증된 셈입니다.

셋째, 리포트에서 해당 표를 찾아 config와 대조합니다. 어긋나면 정의 차이를 의심합니다.

넷째, 토크나이저가 중요하다면 토크나이저 파일을 받아 실제 텍스트로 측정합니다. 이 시리즈의 언어별 토큰 수는 전부 그렇게 얻었습니다.

다섯째, 확인되지 않는 값은 확인되지 않았다고 적습니다.

마치며

여덟 편에 걸쳐 config.json의 필드에서 시작해 MoE 라우팅, 어텐션 변형, 위치 인코딩, 정규화, 토크나이저, 학습 레시피까지 살펴봤습니다. 관통하는 주제는 하나였습니다. 모든 설계 선택에는 대가가 있고, 그 대가는 대개 메모리, 지연, 학습 안정성 중 하나로 나타난다는 것입니다.

모델은 계속 바뀝니다. 오늘 확인한 숫자는 내년이면 달라져 있을 것입니다. 그러나 config를 열어 파라미터를 세고, 리포트의 표와 대조하고, 확인되지 않는 값을 비워 두는 절차는 그대로 쓸 수 있습니다. 그것이 이 시리즈가 남기려는 것입니다.

참고 자료

직접 해보기

시리즈

Reading a Technical Report Critically — What Gets Written Down and What Goes Missing

Introduction

This is the last post in the series. Along the way we pulled dozens of numbers out of config.json files and technical reports and computed with them. This post sets out the judgment criteria used in that process: which numbers to trust, which to hold in reserve, and which were never used at all.

All figures were verified directly against papers, official reports, and config.json files on 2026-08-12. Models get updated, so check the originals again.

What Can Be Verified and What Cannot

The contents of a technical report fall into three layers by how hard they are to verify.

The first layer is immediately verifiable: structural values such as layer count, head count, vocabulary size, and expert count. Cross-check them against a public config.json and you have an answer in seconds. In this series, comparing the report tables of Qwen3, DeepSeek-V3, and Kimi K2 against their configs produced agreement in every case.

The second layer is verifiable by computation, and parameter count is the prime example. In the first post we computed the parameters of Qwen3-8B as 8,190,735,360 from the config alone, matching the value the repository reports exactly. The same held for Mixtral-8x7B and Qwen3-30B-A3B. That all three matched without error means the structure described in the reports agrees with the actual weights.

The third layer cannot be verified: training token counts, data mixture ratios, GPU hours, and benchmark scores. For these there is no way to confirm anything beyond trusting the report.

The Limits of Self-Reported Benchmarks

Within that third layer, the most frequently cited and most caution-worthy item is the benchmark score. There is a reason this series barely cited any.

Numbers a development team publishes from evaluating its own model are not an independent evaluation. This is not an accusation of dishonesty but a structural limitation. Evaluation prompts, the number of examples used, decoding settings, and grading methods differ by team, and the comparison models are generally either run by that team or quoted from other reports.

The only performance figures this series cited were from the data-rephrasing experiment in the Kimi K2 report: 23.76, 27.39, and 28.94 for the original at 10 epochs, one rephrasing at 10 epochs, and ten rephrasings at 1 epoch. They were cited because they are a controlled comparison by the same team under the same conditions, not a ranking between models. Even then it was stated that these are the authors' own experiments and not an independent evaluation.

The reading habit is simple. When you see a score, first find who measured it and under what settings. Without that information the score cannot be used for comparison.

When the Config and the Report Disagree

Two genuine discrepancies came up in this series.

First, the vocabulary size of Qwen3. The config vocab_size is 151936 while the report says 151,669. Opening the tokenizer file directly gave 151,669. The conclusion is that both are correct. They were simply measuring different things: the config states the embedding matrix size, the report states the tokenizer vocabulary count.

Second, the context length of Qwen3-8B. The config max_position_embeddings is 40960 while Table 1 of the report says 128K. Reading the body of the report, long-context training was done at 32,768, with a fourfold extension obtained at inference through YaRN and DCA. The conclusion is the same: they were talking about different things.

The lesson from both cases is one. When you find a discrepancy, before asking which side is wrong, check whether the two values are measuring the same object. Usually the definitions differ.

What Could Not Be Confirmed

The heart of honest writing is recording what you could not confirm as unconfirmed. This series had such items.

The config.json files for Llama 3.1 and Gemma 2 were access-restricted and could not be read. For Llama 3.1 the structural values are all present in Table 3 of the technical report, so that became the source, and the text states that the figures came from Table 3 rather than a config. For Gemma 2 the config could not be read either, and since the values this series needed were never obtained, the model was left out entirely.

That was the rule this series held to. Values that could not be confirmed are left blank, or the model is not covered. Filling in a plausible number makes the writing smoother but makes it impossible for a reader to base a judgment on the text.

What Reports Commonly Omit

Reading several reports side by side reveals consistently empty cells.

The largest gap is data mixture ratios. Reports that disclose exactly what percentage came from which source are rare. Often only domain names are listed.

The second is a record of failures. Only the final configuration gets written down, and what was tried and abandoned is usually missing. As an exception, the Kimi K2 report stating that doubling attention heads lowered validation loss by only 0.5 to 1.2 percent and therefore did not justify the inference cost is a rare case. Descriptions like this let a reader examine the basis for a decision.

The third is the detail of evaluation conditions. Scores are printed prominently while prompts and decoding settings sit in an appendix or nowhere at all.

Signals of a Good Report

Conversely, some kinds of writing raise credibility.

One is noting that a value changed during training. The DeepSeek-V3 report stating that the bias update speed was 0.001 until 14.3T tokens and then switched to 0.0 is an example. Details like this are hard to fabricate and genuinely help reproduction.

Stating limits about one's own work works the same way. The Kimi K2 report noting that using synthetic data for continued scaling remains an active area of investigation, with key challenges in generalizing across diverse source domains without compromising factual accuracy and in minimizing hallucinations, is such a passage.

Attaching conditions to a figure is another good signal. When Kimi K2 gives the increase in inference compute from raising head count, it states the conditions alongside: a sequence length of 128k with the total expert count fixed at 384. A multiplier without conditions cannot be interpreted.

A Procedure for Checking Things Yourself

Finally, here is the procedure actually used throughout this series.

First, fetch the config.json directly. Accessing the raw file address in a model repository lets you see the structure without downloading weights.

Second, count parameters by hand and reconcile them against the published value. If they match, you have read the config correctly and the report's structural description is verified along with it.

Third, find the corresponding table in the report and compare it against the config. If they disagree, suspect a difference in definitions.

Fourth, if tokenization matters to you, download the tokenizer file and measure with real text. Every per-language token count in this series was obtained that way.

Fifth, write down unconfirmed values as unconfirmed.

Closing

Across eight posts we went from the fields of config.json through MoE routing, attention variants, positional encoding, normalization, tokenizers, and training recipes. One theme ran through all of it: every design choice has a cost, and that cost usually shows up as memory, latency, or training stability.

Models keep changing. The numbers confirmed today will be different next year. But the procedure — open the config, count the parameters, compare against the report's tables, and leave unconfirmed values blank — carries over unchanged. That is what this series set out to leave behind.

References

Try It Yourself

Series