最新

好奇团队在发展壮大并开始依赖多个系统时，如何处理集成问题？ 这个问题在什么时候真正成为一个难题？ 你们是通过内部工具、外部平台还是其他方式来解决的？

https://googlecloudplatform.github.io/scion/overview/

TLDR: 我修改了 PyTorch 和 Triton 的内部结构。我修改了注意力机制，使其具有线性第一层、中间二次方层和线性最后一层。 在测试中，推理速度大大加快，但困惑度略有下降。 全注意力机制 O(n²): 17.96 秒 / 5.6 个 token/秒 HybridAttention O(n·W + n·D): 0.35 秒 / 286.6 个 token/秒 我一直在 PyTorch 中从头开始构建一个专注于 Rust 的小型语言模型。这并非微调。它基于字节级别，从随机初始化开始，在 Rust 相关的语料库上进行训练，语料库在这里组装：https://codeberg.org/JohannaJuntos/Sisyphus 模型和训练设置 该模型有 2560 万个参数，上下文长度为 512。它使用 256 个字节级词汇表，具有 8 层、8 个头和 512 维嵌入。位置嵌入是学习的，嵌入和 LM 头的权重是绑定的。 使用单个 RTX 4060 Ti 8GB 在 173.5MB 的 Rust 语料库上训练了 3 万步。 最终指标是训练损失 0.5834，验证损失 0.8217，困惑度为 2.15。最佳验证损失出现在大约第 18.5k 步，这表明存在一些晚期过拟合或平台期。 架构 该模型是 GPT 风格的解码器，但用每个层中的 HybridAttention 块替换了标准的全注意力机制。这结合了局部窗口因果注意力机制和类似 GRU 的循环状态路径，以及一个混合两者的学习门控。 局部路径处理短程语法，而循环路径携带压缩的长程状态。门控偏置被初始化为在训练早期倾向于局部注意力。 推理使用 Triton 内核和自定义 torch.library ops。 语料库 最大的收获来自语料库的扩展。 运行开始时，大约有 31MB 来自 Rust 官方来源和主要项目，如 rustc、cargo、rust analyzer、tokio、serde、ripgrep、clap 和 axum。通过克隆前 500 个 crate，语料库扩展到 173.5MB，成功克隆了 461 个。 这种扩展比任何架构上的改变都更有影响。 推理性能 全注意力机制的运行速度约为每秒 5.6 个 token，而带有 KV 缓存的 HybridAttention 达到每秒 286.6 个 token。这大约是 51 倍的加速，且没有可见的质量损失。 KV 缓存使用 VRAM 中 64 个 token 的热窗口，而较旧的 token 被压缩为 8 位幅度和角度，并且可以选择性地提升回全精度。对于此设置，这会将有效复杂度从二次方变为接近线性。 质量 Rust 表面语法看起来不错，导入和函数签名通常是合理的。语义仍然很弱，重复和递归模式很常见。它看起来像 Rust，但还没有很好地推理。 有趣的地方 该项目结合了从头开始的字节级 Rust 预训练、混合局部注意力和循环架构、跨 Rust 生态系统的大规模语料库扩展，以及一种实用的 KV 缓存分页策略，可在消费级 GPU 上实现大幅加速。 下一步 我计划运行消融实验，比较混合注意力与仅局部和仅循环变体，评估大约 18.5k 步的检查点与最终模型，并添加语法级别的验证，例如解析和编译生成的代码。我还想探索将上下文长度从 256 扩展到 2048，并测试切换到 BPE 是否变得值得，因为语料库现在更大了。 问题 对于小型代码模型，除了困惑度之外，哪些评估最有帮助？ 有人看到混合局部加循环注意力机制在代码生成方面表现良好吗？ 考虑到这种设置，您会优先考虑更多 token、更长的上下文还是干净的消融实验？