在大模型的 Scaling Law 讨论里大家通常只盯三个变量参数量、数据量、计算量。只要它们按估算出的比例同步增长模型能力就会沿着一条相对稳的曲线往上走。这次在国际基础科学大会这项交流和报告中被提到的 JTok 工作把问题往前推了一步如果训练过程中不仅考虑模型的参数量、数据量还把 Token Embedding 的构造方式当成一个可独立设计的变量把它作为 Scaling Law 里的另一个轴去观察和建模会出现什么结果从论文标题看JTok 的核心研究对象是 Token Embedding切入角度是“another Axis of Scaling Law”。“另一个轴”这个说法很关键它意味着研究者在做一个维度扩展现行 Scaling Law 的坐标体系可能并不完整除了模型深度、宽度、数据规模之外token 的表示与切分粒度同样会影响最终表现。对做预训练、做 tokenizer 优化、或正在训练小规模语言模型的人来说这个方向值得直接关注。这篇文章会把 JTok 标题中能确定的信息拆开来讲同时补上研究思路、可验证的实验设计、训练工程中的显存与吞吐影响、以及一套可以自己复现并验证“Token Embedding 作为 Scaling Law 轴”的测试流程。需要提前说明的是当前可获得的材料主要来自论文标题和少量公开关键词PPT 图内结果、具体数据集、完整公式并未放全所以正文会把“标题确定信息”与“方向性推演”分开尽量不虚构任何性能数字。1. 论文方向速览项目内容说明项目名称JTok完整标题前缀为 On Token Embedding as another Axis of Scaling Law via Joint...报告场合国际基础科学大会相关交流核心研究对象Token Embedding即语言模型对 token 的嵌入表示方式切入角度把 Token Embedding 作为 Scaling Law 中独立于参数量、数据量的另一个轴可能的工作机制标题中的 “Joint” 暗示联合化或联合匹配关键词JTok、Token Embedding、Scaling Law适合读者LLM 预训练研究者、Tokenizer/嵌入层优化者、做小规模可复现 Scaling 实验的工程师需要澄清论文的详细公式、图表、实验数据材料未完整公开结论性内容需结合后续论文正文谨慎判断从表格能看出JTok 不是传统意义上的推理解码工具也不是可以直接下载的一键部署项目而是一个研究方向。它能给读者带来的价值主要有三个把“词表大小与 embedding 维度”重新拉回 Scaling Law 的分析框架提供了一种扩展实验坐标的方法论落地到工程上直接关系到显存占用、tokenizer 设计、预训练收敛速度和推理吞吐。2. JTok 题目拆解它在解决什么问题2.1 “Token Embedding”到底指什么在 Transformer 语言模型里Token Embedding 通常有两层含义。第一层是词嵌入矩阵。模型把离散 token ID 映射到一个连续向量空间这个映射就是 embedding 矩阵维度是vocab_size × hidden_size。这个矩阵在训练中会被更新所以它对显存、优化器状态、模型参数量都有直接影响。第二层是“把自然语言切分成 token”之后每个 token 到底用什么身份参与建模。同一个词切成 BPE、Unigram、WordPiece效果不一样同一个语料用大词表还是小词表训练收敛情况也不一样。很多人容易忽略这一点词表实际上决定了模型对数据的压缩方式。JTok 标题里把 Token Embedding 提出来说明它很可能把上面两件事放在一起看。换句话说这个轴不是单纯指 embedding 矩阵的维度而是指语言建模入口处的那一整条链路词表大小、切分粒度、嵌入维度、以及“这套表示是否和主干模型能力匹配”。2.2 现有 Scaling Law 缺了什么现在大家常说的 Scaling Law基本形式是模型最终损失或能力与参数量 N、数据量 D、计算量 C 之间存在幂律关系。比如常见近似式L(N, D) A / N^alpha B / D^beta E这个是理想化的容量边界。问题是真实预训练中哪怕 N 和 D 都固定两个模型完全可能因为词表设计不同、Embedding 初始化方式不同走出差距不小的损失曲线。为什么因为 N 本身是一个混合量。embedding 参数和 Transformer 主干参数对 Loss 的贡献并不等价。简单增加词表会让参数量上升但计算量却不一定等比例增加因为训练时只有部分 token 的 embedding 行会被更新。也就是说在“参数量膨胀”和“实际表达能力”之间可能出现偏离。JTok 要做的就是把这种“偏离”系统化地建模把 Token Embedding 单独抽出来作为一个坐标轴去研究而不是躲在大而化之的 N 里面。2.3 “另一个轴”的含义“另一个轴”意味着三个变化。第一预测目标从二维幂律关系变成涉及 token 表示策略的多维扩展关系。不止看“喂多少数据、用多少参数”还要看“把数据拆成什么 token、token 向量空间是否合理”。第二比较基线不再是同词表下加参数而是在不同词表、不同 embedding 结构下寻找最优配比。比如用小词表加更多 Transformer 层可能优于大词表加少层 Transformer这也意味着单纯比较参数量会产生误判。第三“Joint”暗示新方法不把 embedding 当作一个固定被学习的旁路而是将它和主干网络联合设计、联合调节。关于“via Joint…”后半段是什么材料里没有给出完整词汇比较保守的读法是 Joint Training / Joint Optimization / Joint Tokenization。无论哪种关键词都是“联合”。3. 为什么 Token Embedding 值得成为 Scaling Law 的一个轴3.1 词表大小决定“参数效率”的含金量如果你直接加大词表模型参数总量会跟着变大但计算成本并不一定同比例上升。难点在于词表增长会稀释每个 token 的训练频率。尾部词频很低的 token对应的 embedding 行往往得不到充分训练。这种情况下参数量 N 增长是真实的但模型看不到同等程度的 Loss 下降。JTok 如果能把词表变化与最终 Scaling 曲线之间的关系描述清楚它其实是在帮你回答一个工程问题预算固定时是把参数花在词表上还是花在主干网络上3.2 Tokenizer 是隐藏的超参数很多团队在做预训练时tokenizer 往往是从开源模型里直接抄过来用的。可问题在于不同语料分布、不同目标语言、不同文本密度对 tokenizer 的要求完全不同。从JTok的角度看tokenizer 不再是一个固定的前处理模块它直接参与决定 Token Embedding 的表示质量。一个过大的词表会把大量 embedding 参数花在长尾符号上一个过小的词表会让序列变长计算量上升上下文容纳能力被削弱。3.3 Embedding 维度必须与词表、层数联动Embedding 维度改变不只是影响一层矩阵它会影响 attention 的 head 数、FFN 中间层尺寸、以及整个计算图的比例。传统做法里hidden_size 跟着参数量目标一并定下词表大小常被当作一个固定常数。JTok 的潜在贡献是把公式变成多维联动给定计算预算后在vocab_size、hidden_size、num_layers和训练数据之间寻找平衡点。这个方向如果在理论或系统实验上做得足够系统会直接影响早期架构选型阶段的决策方式。4. 方法论与研究思路推演以下内容属于方法层面的梳理不来自论文原文需要根据公开标题和常识做出判断具体量化结论应以 JTok 论文正式版为准。4.1 Joint 意味着联合设计与全链路评估“Joint”这个词决定了它不是只换一个 tokenizer 再跑一轮实验而是更接近把以下三个环节绑定优化Tokenization如何切分数据词表定多大Embedding 空间维度、初始化、是否做 tied embedding、是否需要词表裁剪主干网络层数、注意力头数、FFN 尺寸。只有这三者联合变化才能被称为“另一个轴”。如果是单独调参那只是常规消融实验。4.2 构建可量化的 Scaling 关系研究这类问题一般会先设定一组固定计算预算例如用相同的总 FLOPs 或相同总参数预算只把预算分配方式变换成不同的词表大小和 embedding 维度组合。参考实验逻辑固定数据量 → 固定预算 → 变化词表大小 → 观察 Loss 与下游能力如果小词表在相同预算下能获得更低 Loss说明这部分预算放在主干网络更合算如果大词表在长尾任务上表现更好说明 embedding 行本身承载了知识记忆功能。4.3 一套可落地的小规模验证流程在没有完整论文实现代码前可以用一套自己设计的脚本验证这个问题。下面是一个可行的预实验方案。# 1. 拉取一个轻量训练框架示例实际包名以官方文档为准 # 这里以 Hugging Face transformers datasets 为例 pip install transformers datasets accelerate# 2. 分别用小词表和大词表构建 tokenizer from tokenizers import Tokenizer from tokenizers.models import BPE from tokenizers.trainers import BpeTrainer for vocab_size in [8000, 16000, 32000]: tokenizer Tokenizer(BPE()) trainer BpeTrainer(vocab_sizevocab_size, special_tokens[unk, s, /s, pad]) tokenizer.train(files[./corpus.txt], trainertrainer) tokenizer.save(f./tokenizer_{vocab_size}.json)# 3. 统计两个关键指标平均序列长度和覆盖率 from transformers import AutoTokenizer import json results [] for vocab_size in [8000, 16000, 32000]: tok AutoTokenizer.from_pretrained(f./tokenizer_{vocab_size}) total_len 0 sample_count 0 rare_tokens 0 with open(./corpus_sample.txt, encodingutf-8) as f: for line in f: ids tok.encode(line) if tok.encode(line) else [0] total_len len(ids) sample_count 1 if len(ids) 1: rare_tokens 1 results.append({ vocab_size: vocab_size, avg_len: total_len / max(sample_count, 1), single_token_ratio: rare_tokens / max(sample_count, 1) }) print(json.dumps(results, ensure_asciiFalse, indent2))这个脚本不直接做模型训练它可以快速确定词表变化会带来多少序列长度差异从而为 Scaling Law 实验提供解释变量。如果你已经有小规模训练管线完整流程可以概括为保留同一份语料训练多组词表例如 8k / 16k / 32k在相同步数、相同 batch size、相同总 token 数下训练小模型记录每条训练曲线和评测集 Loss把词表大小作为横坐标把同预算下的 Loss 作为纵坐标观察是否存在稳定趋势。如果多组实验都显示“某个词表区间内 Loss 变化不敏感”说明当前任务下 Token Embedding 这个轴是缓变轴如果 Loss 对词表大小非常敏感说明现有 Scaling Law 缺了这个轴之后确实会导致架构选型时出现系统性偏差。5. 怎么做实验才能比较不同 Token Embedding 策略这一块很关键因为任何 Scaling Law 方向的结论都需要严格的控制变量。5.1 控制变量设计变量名称固定值建议说明训练语料同一份采样语料避免数据分布差异干扰总训练步数固定步数比如统一训练 5000 步Batch Size固定 token 数保证数据吞吐一致优化器与学习率同一套配置学习率峰值可做小范围采样激活函数、Norm 位置同一架构不要同时改架构词表大小实验变量如 8k / 16k / 32kEmbedding 维度实验变量与词表组合进行网格搜索模型总计算量尽量接近若无法严格对齐记录 FLOPs 并单独分析注意不能只改动词表大小其他保持不变就直接比较因为总参数不同会导致训练时间不同。更好的方式是固定计算预算让每个模型在总 FLOPs 相近时停止训练再比较曲线。5.2 需要记录的指标建议至少记录以下内容训练 Loss 曲线、验证 Loss 曲线平均序列 token 数词表外 token 覆盖率每一步的 GPU 显存占用总训练时间与总 token 吞吐下游评测任务得分最终模型中 embedding 向量的平均 L2 范数、词向量余弦相似度分布。这些指标足够区分Loss 差异到底来自表示容量还是单纯来自参数数量变化。5.3 用 WB 或本地日志统一记录{ project: jtok-word-embedding-scaling, method: fixed_token_budget, total_tokens: 1000000000, vocab_sizes: [8000, 16000, 32000], embed_dims: [256, 384, 512], gpu_device: cuda:0, log_interval: 50, save_interval: 500 }# 训练完成后把全量结果汇总到一个 CSV 再进行拟合 python collect_results.py --output scaling_results.csv# 简单的幂律拟合示例只做趋势参考不代表 JTok 原文公式 import pandas as pd from scipy.optimize import curve_fit df pd.read_csv(scaling_results.csv) def model_loss(vocab_size, embed_dim, total_params, a, alpha, b, beta): return a / (vocab_size ** alpha) b / (total_params ** beta) # 注意真正的 Scaling Law 公式需要大量实验后验证这里仅演示流程 popt, _ curve_fit( lambda X, a, alpha, b, beta: model_loss(X[0], X[1], X[2], a, alpha, b, beta), (df[vocab_size].values, df[embed_dim].values, df[total_params].values), df[loss].values, p0[1.0, 0.1, 1.0, 0.1] ) print(popt)6. 对训练工程的直接影响6.1 Embedding 矩阵的显存开销JTok 这类研究一旦落地最直接的工程问题就是显存。Embedding 矩阵显存公式很容易算embedding_params vocab_size × hidden_size embedding_memory embedding_params × bytes_per_param在混合精度训练中参数、梯度和优化器状态都需要显存。以 AdamW 为例一个参数通常要占据约 12 到 16 字节所以一个大词表带来的开销并不可忽视。# 用 Python 快速估算 embedding 显存占用 python -c vocab_size 32000 hidden_size 4096 params vocab_size * hidden_size print(fembedding params: {params / 1e6:.1f}M) print(ffp16/bf16 mixed training approx: {params * 16 / 1024 / 1024 / 1024:.2f} GB) 如果把词表从 32k 提升到 128khidden_size 固定为 4096embedding 参数会从约 1.3 亿上升到约 5.2 亿。这在小模型上已经会对显存和优化器产生明显影响。6.2 Tokenizer 再也不是“随便选一个”按照“Token Embedding 是另一轴”的思路实际训练前要多花一天时间做 tokenizer 步数实验。选择词表不能只看压缩率还要结合小规模模型训练曲线。实践优先级排序先在小数据上训练 2000 步设置多个候选词表挑选收敛较快且验证 Loss 更低的词表再看词表的语言覆盖与长尾表现最后把最优词表用于全量训练。如果大量实验表明 token embedding 这个轴与主干模型规模存在联合规律那以后选 tokenizer 就不是盲试而可以基于已有的 Scaling Law 直接估算最优词表。6.3 Tied Embedding 与 Untied Embedding 的取舍常规模型中输入 embedding 矩阵可以与输出层 logits 的权重共享也就是 tied embedding。共享可以省参数但限制了输入输出两侧的表达自由。从另一个轴的角度去判断如果你把词表本身当作变量tied 和 untied 的行为很可能不同。小词表下 tied embedding 往往能稳定训练大词表下 untied embedding 的灵活度更高。这个决定不能在训练后修改所以需要在实验阶段就纳入记录否则后续做 scaling 分析时所有曲线都被权重共享策略混杂了。7. 普通训练者怎么阅读和复现这类研究7.1 不需要一上来就复现全量实验这类 Scaling Law 研究报告往往需要几十甚至上百次完整预训练。个人开发者很难直接复现全部图表。但有两个低门槛切入点一是只复现 small-scale 的可行规律比如用 50M 或 100M 参数的小模型做五组词表对照实验看趋势是否和论文一致。二是只做 tokenizer 和 embedding 层单独对照不动主干网络衡量不同词表对数据压缩效率与长尾分布的影响。7.2 训练脚本建议从 NanoGPT 或类似最小实现改最小实现的优势是代码短、依赖少、显存要求低。# 安装最小依赖示例 pip install torch numpy tiktoken启动前先规划好三个变量# 配置示例具体参数按实际显存调整 python train.py \ --vocab_size 8000 \ --n_embd 256 \ --n_layer 6 \ --n_head 4 \ --batch_size 32 \ --block_size 256 \ --max_steps 5000再跑一组python train.py \ --vocab_size 32000 \ --n_embd 256 \ --n_layer 6 \ --n_head 4 \ --batch_size 32 \ --block_size 256 \ --max_steps 5000重点不是追求两个模型谁更强而是观察两条 Loss 曲线的形状差异。如果大词表模型在小步数下收敛更慢但在更长时间后反转那么 Token Embedding 这个轴就要考虑“训练阶段依赖”。7.3 关注 Loss更要关注“数据效率”只看最终 Loss 会漏掉一个重要维度数据效率。同一个语料在大词表下可能变成更少的 token而更少的 token 通常意味着更短的训练时间。所以判断哪个词表更好不能只看同一步数的 Loss还要看训练耗时。每步算力一致时若大词表序列平均长度短实际每个 epoch 看到的文本更多收敛需要的步数就少。这类工程变量正是论文要系统解释的内容。建议在实验表格中记录“达到某个 Loss 需要的标准 Hours”而不是只记步数。这种口径更能反映真实训练部署效率也方便和其他 Scaling Law 结论对比。8. 局限性与开放问题8.1 当前材料的限制这篇论文目前公开信息有限。围绕 JTok 的完整实验配置、Joint 后半部分的具体策略、使用的模型规模、评测集等仍需以最终论文或官方资料为准。这里的阅读策略是把标题传达的研究视角作为核心收获先把问题意识学会再等细节公开后核对具体结论。8.2 Token Embedding 能否成为独立轴部分相关研究倾向于认为Loss 主要由计算量和数据量决定词表只是改变常数系数而不是改变指数斜率。如果这个判断成立Token Embedding 就不能完全算“独立的轴”而只是一个有影响力的附加项。JTok 要挑战的正是这种观点。要证明它是真正的轴至少需要观察到在词表大小变化时Loss 随计算量变化的幂指数本身发生了显著改变而不仅是平移。单一模型群很难给出稳定结论需要跨多个规模重复。这套实验成本极高这也是为什么相关方向通常不会很快出大结论。8.3 Joint 到底联合的是哪些元素标题截断在 “via Joint...” 处无法确定完整对象。它可能是Joint Training把 embedding 参数和主干网络用不同学习率联合训练Joint Optimization把词表大小、embedding 维度一起纳入自动搜索Joint Tokenizationtokenizer 与语言模型同时更新的端到端方案。不同对象对应的实验设计差异巨大。只看论文标题不能断定全部内容。9. 关于数据、评测与合规的研究提醒不管 JTok 后续公开的代码与数据形式如何在做相关预训练 Scaling 实验时有几个边界必须守好。第一训练语料必须有合法授权或开放许可。不能因为他人的 Scaling Law 论文里用了某份数据就直接以抓取方式复制语料进行训练。中文互联网数据的版权模糊地带很多训练前建议先确认语料的来源和许可。第二涉及人脸、隐私、机构内部文档的数据不得用于预训练实验也不得混入下游评测集中。如果研究目标是验证 embedding 的泛化能力可以用公开 Benchmarks 或自己整理的无敏感数据集。第三如果要发布预训练模型注意开源协议与模型许可。词表文件、tokenizer 文件同样属于模型产物转发与商用都需检查原始授权范围。第四学术研究求真但工程落地时要留一份数据溯源表说明每一份语料的来源、收集时间、清洗规则和授权状态。许多本地复现实验只需要 1 到 2 GB 的公开语料不要为了凑实验覆盖面而使用来源不明的数据。10. 怎么持续跟进 JTok 相关方向最直接的方法是跟踪论文公开渠道和预印本平台用标题关键词检索 JTok、Token Embedding、Scaling Law 的最新版本。普通实践者不必等论文最终版才行动完全可以按第 4 章的小规模流程先用 8 小时左右的 GPU 时间测一测本地语料下词表大小与 Loss 曲线的关系。这里有一个比较适合做实验的小步骤准备 1 GB 左右纯文本语料训练三个候选 tokenizer8k、16k、32k用同一份最小预训练框架分别训练 1500 到 3000 步记录 Loss、训练速度、显存占用、每步吞吐画出 Loss 与词表大小的关系并结合平均序列长度解释结果。如果做完整训练实验不方便还可以退而求其次直接对比不同 tokenizer 编码后的语料统计特征平均 token 长度、重复度、词频长尾、压缩率。这些指标能快速判断词表设计对数据压缩的影响再决定是否需要投入模型训练资源。此外也可以把注意力放到 tokenizer 社区的新方法上。很多相关工作都在探索如何把词表扩展得更“经济”核心思路仍是让 embedding 参数承担更多有效信息减少无意义的长尾噪声。JTok 的价值很可能是给这些分散的工程经验提供一个统一解释框架。阅读时不妨一边读一边问自己如果把词表大小和嵌入维度同时纳入预算分配我自己的模型能不能少踩几个“参数量涨了但效果没涨”的坑。从结论上看JTok 真正值得学习的不是某一组训练超参而是它试图把 Token Embedding 从“工程参数”提升为“理论坐标”的思考方式。这个角度一旦立住未来模型规模比较就不能只写参数量和训练 token 数还得写清楚词表大小、embedding 维度与 token 化策略。对成本敏感的团队来说这种信息会直接改变预算分配方式。建议把这篇论文收藏起来等完整版本发出后再对照小实验验证。关注重点可以放在三处Loss 与词表的联合曲线、不同规模下的指数稳定性、以及 Joint 设计里是否引入额外训练开销。如果你也在做小参数量模型的预训练实验不妨先用一张消费级显卡把词表对照实验跑起来结果会比任何静态分析都更能说明问题。