此次开放的主要是Google Labs里的Project Genie网页原型（体验入口）Project Genie由Genie 3驱动，并结合Nano Banana Pro与Gemini提供生成与交互能力。文字或上传/生成图片“勾勒世界”（可在进入前预览并微调画面，支持第一/第三人称视角等设置）、在世界中实时探索（移动时实时生成前方路径并可调镜头）、以及基于他人作品的提示词进行“重制/再创作”，并可下载探索视频。

生成世界可能不够逼真或不完全符合提示词/物理规律；角色控制可能出现延迟；单次生成/体验时长目前限制为60秒；此外，Genie 3在2025年8月公布的一些能力（例如可用文本触发的世界事件）尚未被纳入Project Genie原型。

AlphaGenome 的核心定位是统一的DNA序列模型：输入最长可达100万碱基对（1 Mb）的DNA序列，在单碱基分辨率下输出上千条功能基因组预测轨迹，并可通过对比突变序列与参考序列的预测差异，对变异影响进行评分。

论文摘要列出的预测模态覆盖基因表达、转录起始、染色质可及性、组蛋白修饰、转录因子结合、染色质接触图谱，以及剪接位点使用与剪接连接（splice junction）坐标/强度等；作者称其目标是缓解既有方法在长序列上下文与高分辨率预测之间的取舍。

开放与使用方式方面，DeepMind 在 GitHub 发布了配套研究代码（含JAX实现与API实现），代码采用 Apache-2.0 许可；预训练权重可在 Kaggle 或 Hugging Face 下载，但需接受非商业模型条款。仓库同时提示本地运行对算力要求较高（例如建议使用H100级别GPU）。

在评测结果上，论文报告：在变异效应预测的26项评估中，AlphaGenome 有25项达到或超过“最强外部模型”的表现；并展示了其在TAL1致癌基因附近的临床相关变异机制复现能力。训练数据方面，DeepMind 表示模型使用了多个公共联盟数据资源（包括 ENCODE、GTEx、4D Nucleome、FANTOM5 等），覆盖人类与小鼠多种细胞类型/组织的调控相关测量信号；其应用重点指向占基因组大部分的非编码调控区域（常被描述为约98%）。

外部反馈与限制方面，多位专家在 Science Media Centre 的评论中强调：模型在若干任务上表现突出，但细胞类型特异性调控仍是挑战，且目前并不适合直接用于临床患者决策；媒体报道也提示其仍需要实验验证、并受训练物种范围等因素限制。

STAT 报道称，AlphaGenome 自2025年6月上线预览以来，已有接近3000名来自160个国家的科研人员通过API进行非商业研究使用，API日调用量约100万次（DeepMind在发布会上对媒体披露）。

Qwen3-ASR 将语种识别与 ASR 合并为单模型“all-in-one”流程：官方说明其覆盖 52 个语种与方言，其中包括 30 种语言与 22 种中文口音/方言；推理侧同时支持离线与流式，并面向语音、歌唱及带 BGM 的歌声等音频类型。

配套的 Qwen3-ForcedAligner-0.6B 采用非自回归（NAR）时间戳预测方式，用于文本-语音对的强制对齐；官方给出的语种覆盖为 11 种语言，并宣称其时间戳精度在评测中优于多种主流强制对齐方案。效率指标方面，技术报告给出的示例为：Qwen3-ASR-0.6B 在 128 并发下可实现“1 秒转写 2000 秒语音”，平均首 Token 延迟（TTFT）最低 92ms；同时报告与仓库将 1.7B 版本描述为开源模型中的 SOTA，并称其可对标最强商业 API（均为自述评测结论）。

工具链方面，仓库提供 qwen-asr PyPI 包（Transformers 与 vLLM 两种后端）、本地 Gradio Web UI 与浏览器麦克风流式 Demo、以及 Docker 镜像与 vLLM 服务化命令封装，目标是覆盖批处理、高并发与在线服务场景。

在 GPU 侧，Google 在 2026 年 1 月 28 日的更新中宣布：此前在 Google I/O 2025 预告的“高级加速能力”已进入 LiteRT 生产栈并对开发者可用；GPU 引擎以 ML Drift 为核心，覆盖 OpenCL / OpenGL / Metal / WebGPU，目标是让同一套推理逻辑跨 Android、iOS、桌面与 Web 平台更一致。官方给出的量化口径是：相较旧版 TFLite GPU delegate，LiteRT GPU 平均可实现约 1.4× 性能提升；并通过“异步执行 + 零拷贝 buffer 互操作”降低 CPU 介入和内存搬运带来的系统级开销，特定场景宣称最高可到约 2× 的端到端加速。

NPU 侧，LiteRT 把“端侧碎片化”作为主要工程问题：不同 SoC 的编译器/运行时差异会迫使应用层处理大量适配。Google 的描述是，LiteRT 提供统一 NPU 部署工作流以抽象底层厂商 SDK，并提供 AOT（可选的预编译）与 JIT（端上编译）两种策略；同时保持失败回退到 GPU/CPU 的路径。2026 年 1 月的官方文章还指出，面向 MediaTek 与 Qualcomm 的首批“生产级”NPU 集成已可用，并给出“最高可达 CPU 100×、GPU 10×”这类性能宣称（需注意这通常依赖模型结构、算子覆盖与具体硬件）。

在“模型来源”上，LiteRT 明确把自己定位为多框架端侧推理栈：官方文档写明支持从 PyTorch、TensorFlow、JAX 转换到 .tflite 或 .litertlm；GitHub 仓库也给出两条典型路径——经典模型通过 Torch Converter 转成 .tflite 并配合量化工具做资源约束优化；LLM 路线则通过 Generative Torch API 重新表述/转换，再接入 LiteRT-LM 进行端侧推理与编排。

从工程成熟度看，GitHub Release 显示 LiteRT v2.1.0 被标注为“beta release”，并声称 API 已稳定且达到与 TensorFlow Lite 的功能对齐（feature parity），同时把 GPU/NPU 加速作为关键增量：运行时侧加入自定义算子支持（custom op dispatcher）、CMake 构建、预编译 C++ SDK（libLiteRt.so）、以及 CompiledModel 的 Profiler/ErrorReporter/ResizeInputTensor 等接口；GPU 侧扩大 WebGPU/Dawn 与 OpenCL 覆盖，并为 Metal/WebGPU 增加异步执行。Release 文案同时“官方推荐开发者开始迁移到 LiteRT”。