Other

技术解读

以下内容由 GitRead 中文社区 编辑团队基于项目 README 与官方资料整理, 结合中文开发者的常见使用场景补充技术选型建议。具体以项目官方文档为准。

项目背景与痛点

zengxiao-he/tessera 是一个从零构建的语言模型提炼与服务引擎,旨在优化大型语言模型的部署与推理速度。它通过自定义的 Triton/CUDA 内核、FSDP 蒸馏、分页 KV 批处理、推测性解码等技术,提供了一个高度优化的模型和服务框架。该项目不仅关注模型的训练效率,更注重模型服务中的性能优化,使得整个系统能够高效地部署于生产环境中。

许多现有的 LLM 系统中普遍存在的一大痛点是模型的推理速度慢和资源消耗大,尤其是在多用户并发请求时,模型服务效率不高且资源消耗严重。tessera 项目的设计初衷就是解决这一痛点,加快推理过程的同时降低计算资源消耗。

核心技术揭秘

tessera 项目中应用了多种前沿的技术来优化模型的服务效率。具体来说,项目包括:

  • 自定义 Triton/CUDA 内核:利用 NVIDIA Triton Inference Server 中的自定义 CUDA 内核,通过硬件加速来提升模型的推理速度。

  • FSDP 蒸馏:通过全规模数据并行蒸馏,将大型模型的权重压缩到轻量级模型中,大幅减少模型的实际推理所需计算资源。

  • 分页 KV 连续批处理(paged-KV continuous batching):将内存中的键值对进行分页存储,并采用连续批处理的方式减少访问次数和提升缓存命中率。

  • 投机性解码(speculative decoding):在某些预测任务中,模型可以预先推测下一步的操作,从而减少等待时间和计算负载。

graph TD A[用户请求] --> B[调用 Rust Gateway] B --> C[触发 JAX Oracle] C --> D{"模型类型?"} D -->|"小型模型"| E{"执行分页KV批处理"} D -->|"大型模型"| F{"执行FSDP蒸馏"} E --> G{"加入投机性解码队列"} F --> H{"执行Triton/CUDA加速"} G --> I[完成解码] H --> I I --> J[返回结果]

功能亮点与差异

tessera 相较于其他 LLM 系统,其独特之处在于几个关键技术点与差异化设计:

  1. 自定义内核和异构计算加速:通过结合 Triton/CUDA 内核,实现模型推理过程中的异构计算加速。

  2. 分页 KV 和推测性解码:分页 KV 批处理优化了内存访问,而推测性解码大幅减少了计算资源的非必要消耗。

  3. 开源社区支持:该项目不仅提供了代码,还积极吸收和融入社区优化,保持持续的迭代和优化。

以上这些差异化设计,使得 tessera 在实际应用中具有显著的性能与资源优化能力,尤其适用于数据量大、响应时间要求高的场景。

应用场景与落地建议

在生产环境中使用 tessera 项目,意味着需要在硬件资源与软件工程方面进行一系列的调优工作。硬件上,建议使用拥有 NVIDIA GPU 的机器,以便发挥 GPU 加速带来的性能提升。软件架构上,需确保网络带宽和内存资源的合理分配,尽量减少瓶颈影响。特别是在大规模分布式环境下,需要细致地监控资源使用情况,确保系统在高负载情况下的平稳运行。

tessera 适用于多种场景,尤其是在需要高性能推理能力的应用中。例如:

  • 对话系统:实时获取用户的对话并提供高质量回复。
  • 推荐系统:实时推荐内容,加速用户转化。
  • AIGC:加速文本生成、图像处理、代码生成等生成式任务。

综合评价

总体而言,tessera 在技术上展示了众多前沿的技术叠加呈现,从硬件加速、批处理、推测性解码到整体可扩展的架构设计,都非常成熟有力。但从另一方面而言,作为一项复杂的综合性技术工程,其部署和维护相对复杂,需要较高的技术门槛和资源投入。总之,tessera 是一项强有力的技术产品,适合那些在特定场景内对推理速度与资源优化有明确需求的企业和项目。

关于

GitHub 原始描述(英文)

From teacher to tiles — a from-scratch LLM distillation & serving engine: custom Triton/CUDA kernels, FSDP distillation, paged-KV continuous batching, speculative decoding, a Rust gateway, a JAX oracle, and interpretability tooling.

描述取自 GitHub 官方 API,保持仓库作者书写的原文。

语言占比

Cuda
Python
Rust

贡献者

README

Tessera

A small, from-scratch LLM stack built around one goal: distill a large teacher into a small student, then serve that student efficiently. Keeping that goal end-to-end means touching most of the pieces that matter in practice — custom GPU kernels, sharded training, an inference engine, quantization, and a serving front end — without any of it being a toy.

CI License Python Rust

It runs and is unit-tested on a laptop (CPU or Apple MPS). The Triton/CUDA kernels are written for NVIDIA GPUs; on anything else the model transparently falls back to a torch reference, and the kernels are checked against that reference whenever a GPU is available.

flowchart LR T[Teacher 40M] -->|distill, FSDP/ZeRO-3| S[Student 6M] S -->|int8 / AWQ / FP8| ENG[Inference engine] subgraph ENG[Inference engine] direction TB PK[paged KV cache] --- SCH[continuous batching] --- SPEC[speculative decode] end K[(Triton + CUDA kernels)] -.-> S & ENG GW[Rust tokio/axum gateway] -->|PyO3| ENG client([client]) --> GW

What’s in it

Training side:

  • Decoder transformer with RMSNorm, RoPE, grouped-query attention and SwiGLU (tessera/model).
  • Knowledge-distillation losses: temperature-scaled KL, optional hard CE, hidden-state matching (distill/losses.py).
  • FSDP/ZeRO-3 written from scratch — flat-parameter sharding with a sharded Adam optimizer. It’s checked to be numerically identical to single-process training, in one process and across two gloo ranks (distill/fsdp.py).
  • Atomic, sharded checkpoints with resume-from-latest (distill/checkpoint.py).

Kernels:

  • A FlashAttention forward kernel in Triton: online softmax, causal masking, GQA, autotuned tile sizes (kernels/triton/flash_attention.py).
  • Fused RMSNorm, a fused SwiGLU GEMM, and an int8 weight-only matmul that dequantizes in the K-loop (kernels/triton).
  • Raw CUDA C++ versions of RMSNorm and attention for the low-level memory work, plus nvtx ranges and Nsight notes (kernels/cuda).

Serving:

  • Block-paged KV cache with a ref-counted allocator for prefix sharing (serve/paged_kv.py).
  • A continuous-batching scheduler that recomposes the batch every step, with admission control and preemption under memory pressure (serve/scheduler.py).
  • Speculative decoding with the standard accept/reject sampling (serve/speculative.py).
  • Post-training quantization: int8 weight-only, AWQ, and an FP8 (E4M3) path (quant).
  • A Rust gateway (tokio + axum) that handles HTTP and admission back-pressure and calls into the Python engine over PyO3 (tessera-rs).

Extras:

  • A JAX/XLA reimplementation of the forward pass, used as an independent parity check against PyTorch (jax_ref).
  • Interpretability helpers: activation hooks, a logit lens, and induction-head detection (interp).
  • A byte-level BPE tokenizer plus image-patch and log-mel audio front ends for multimodal data (data).

Quickstart

git clone https://github.com/zengxiao-he/tessera && cd tessera
python -m venv .venv && source .venv/bin/activate
pip install torch --index-url https://download.pytorch.org/whl/cpu   # or a CUDA build
pip install -e ".[dev]"

pytest -m "not gpu"          # CPU tests; the kernel tests skip without a GPU
tessera info                 # list presets and parameter counts
python examples/serve.py     # continuous batching + speculative decoding
python examples/train_distill.py --steps 30
python examples/interp_demo.py

On a Linux box with an NVIDIA GPU:

pip install -e ".[dev,gpu]"  # adds Triton
pytest -m gpu                # Triton kernels vs the torch reference

Rust gateway:

cd tessera-rs && cargo test && cargo run --release
curl -s localhost:8080/generate -H 'content-type: application/json' \
  -d '{"prompt":"hello","params":{"max_new_tokens":16}}'

Benchmarks

These are from an Apple M2 Pro running the torch reference path, so treat them as a floor rather than what the fused kernels do on a real GPU. Run pytest -m gpu and the scripts in benchmarks/ on NVIDIA hardware for the numbers that actually matter.

Workload Config M2 Pro
Forward pass tessera-tiny (6M), B=2, T=128, MPS ~100k tok/s, 2.6 ms
Attention (reference) B=2, H=8, T=256, D=64, MPS 1.85 TFLOP/s, 0.15 ms
Engine decode tessera-tiny, 6 reqs x 48 tok ~200 tok/s
Speculative decode self-draft, greedy 98-100% acceptance
python benchmarks/bench_attention.py --seq-len 1024
python benchmarks/bench_throughput.py --requests 8

Tests

The repo is small enough to test thoroughly, and most of the tests check a property rather than a fixed output:

  • Incremental decode with the KV cache matches a full forward pass.
  • Each Triton kernel matches its torch reference within fp tolerance (run with -m gpu).
  • The JAX forward matches PyTorch to about 2e-4.
  • Sharded Adam matches torch.optim.Adam step for step, in one process and over two gloo ranks.
  • Self-speculation reproduces greedy decoding exactly.
  • The engine drains every request under tight memory and preemption without leaking KV blocks.

Layout

tessera/            model, kernels, quant, serve, distill, interp, data
  kernels/triton/   Triton kernels      kernels/cuda/  raw CUDA C++
  serve/            paged KV, scheduler, speculative, engine
  distill/          KD losses, FSDP, checkpoint, trainer
tessera-rs/         Rust tokio/axum gateway + PyO3 bindings
jax_ref/            JAX/XLA reference
tests/  examples/  benchmarks/  docs/

More detail in docs/architecture.md, with notes on the kernels, serving, and distillation.

Status

Everything above works and is tested on CPU. Things I haven’t done yet, marked in the code: a fused attention backward kernel, a fused paged-attention decode kernel, an FP8 tensor-core GEMM for Hopper, and pjit/shard_map training on the JAX side.

License

Apache-2.0, © Zengxiao He.

评论

暂无评论