MAX v25.4 发布深度解读AMD GPU 正式支持、Python 调用 Mojo 与自定义算子生态升级【免费下载链接】mojoThe Modular Platform (includes MAX Mojo)项目地址: https://gitcode.com/GitHub_Trending/mo/mojo本文基于仓库内官方发布说明 docs/releases/v25.4.md 编写并结合当前仓库源码对推理服务、Python/Mojo API 与自定义算子等核心变更进行纵深解析。读者将掌握 v25.4 版本在 AMD GPU 支持、采样配置、子图 API、PyTorch 自定义算子CustomOpLibrary等方面的具体用法与底层实现脉络。版本概览与核心亮点MAX v25.42025-06-18 发布是本项目发展历程中的一个标志性版本AMD 数据中心 GPU 获得官方支持GenAI 部署首次可以在 NVIDIA 与 AMD 平台上使用同一套代码与容器运行同时开放了 CPU/GPU 内核的社区贡献通道并首次预览Python 调用 Mojo的互操作能力。以下是本版本三大核心亮点AMD GPU 官方支持可使用与 NVIDIA GPU 完全相同的代码和容器在 AMD MI300X、MI325X 上加速部署 MAX。这是可移植、高性能 GenAI 部署的关键一步——无需供应商锁定也无需针对特定平台做专门优化。接受 GPU 内核贡献上个月开源了驱动 MAX 框架的 CPU/GPU 内核代码后本版本正式开放内核贡献通道具体贡献指南见仓库内 max/kernels/CONTRIBUTING.md。预览Python 调用 MojoPython-to-Mojo 互操作 API只需将性能关键部分用 Mojo 编写即可像导入普通 Python 库一样从 Python 调用。Python API 侧新增max.mojo.importer模块作为承载。新增模型架构MAX modelsv25.4 为 MAX 推理框架新增了四个模型架构对应架构目录均可在当前仓库的 max/python/max/pipelines/architectures 下找到模型架构目录状态OLMo 2architectures/olmo2正式支持Google Gemma 3 多模态architectures/gemma3multimodal正式支持Qwen 3architectures/qwen3正式支持InternVL3architectures/internvl仍为进行中Work in Progress此外GGUF 量化 LLaMA 系列q4_0、q4_k、q6_k现在支持配合 paged KVCache 策略使用。这与本版本同时推进的 KVCache 策略调整方向一致见下文CONTINUOUS 策略弃用。MAX 推理服务器更新Inference serverInflight batching 不再要求 chunked prefillv25.4 之前max serve的 inflight batching动态批处理依赖 chunked prefill 机制本版本解除了这一耦合使动态批处理在预填充阶段拥有更高的调度灵活性有利于降低首 token 延迟与显存峰值。采样逻辑扩展与 per-request 采样配置本版本显著扩展了 token 采样逻辑新增并完善了以下采样超参数的支持top_k、min_p、min_new_tokens、temperature。更重要的是采样配置被扩展为 per-request按请求独立配置——不同的并发请求可以携带各自不同的采样超参数而不是沿用服务端的全局默认值。从当前仓库源码可以印证这一设计在底层图执行层面的落地max/python/max/pipelines/sampling/sampling.py 中采样图的输入类型明确按[batch]维度定义了 per-batch 的top_k、top_p、temperature、min_p、seed张量并包含max_k、min_top_p等标量输入sampling_config.py 中的SamplingConfig则集中管理采样阶段的可配置项包括in_dtype/out_dtype输入 token 与输出 logits 的数据类型默认float32enable_penalties是否应用 frequency / presence / repetition 惩罚enable_min_tokens是否启用min_tokens/min_new_tokens在达到计数前阻止模型输出停止 tokenenable_variable_logits允许采样图接收不同长度序列组成的 ragged 张量配合logit_offsets为 echo 与投机解码speculative decoding产生额外 logitssample_on_host是否在主机 CPU 上执行采样将 last-token logits 从设备拷回主机再做 top-k/argmax默认在模型设备上采样。这些字段共同构成了 v25.4 所宣布的扩展采样逻辑 per-request 配置的完整实现骨架。移除 TorchScript 与 torch MLIR 模型支持本版本正式移除了对 TorchScript 与 torch MLIR 模型的支持意味着模型导入路径全面向原生 MAX 图graph与自定义算子方案收敛。max CLI 新参数v25.4 为max命令行工具新增两个实用参数max generate --use-subgraphs允许在模型中使用子图subgraph。子图是图的函数——将重复出现的计算块例如 Transformer 层定义一次再在父图中多次调用编译器只需处理一次定义。从当前仓库源码 max/python/max/graph/graph.py 的Graph.add_subgraph()注释看对于如 Transformer 层重复数十次的模型子图化可将编译时间削减 50 倍以上代价是子图内外的内存分配无法共享峰值内存略升且编译器无法跨子图边界做算子融合。该参数已在 DeepSeek 系列架构中实际启用例如 architectures/deepseekV2/distributed_deepseekV2.py 与 architectures/deepseekV3/deepseekV3.py 均通过use_subgraphs控制。max serve --port为max serve指定监听端口号便于在容器化或多实例部署时显式管理端口。Python API 更新v25.4 的 Python API 变动是历次版本中较大的一次既有大量新增能力也包含一批破坏性移除。子图 API 落地add_subgraph / build_subgraph / call / fold本版本正式为图编程补齐了子图这一关键抽象四组新 API 协同工作Graph.add_subgraph()向当前图添加一个可复用子图。从源码 graph.py 可见其完整签名add_subgraph(name, forwardNone, input_types(), pathNone, custom_extensions[], devices[], is_device_graphFalse)返回子图对象。典型用法是在with graph.add_subgraph(add_one, input_types[input_type]) as sub:中定义子图计算再用ops.call(sub, ...)调用。Module.build_subgraph()为继承自Module的层创建子图。相比直接调用add_subgraph它自动处理权重前缀weight prefix问题因此对Module模型更友好参见 max/python/max/nn/layer/layer.py。ops.call执行一个子图。源码注释max/python/max/graph/ops/call.py明确指出其核心收益编译器只需处理一次子图定义可显著缩短编译时间。ops.fold将滑动块sliding blocks合并为更大的张量服务于窗口类注意力等需要重组张量的场景。max.nn 包与量化、加载相关 APImax.nn包新增大量 APIGraph构造函数新增KernelLibrary参数类型新增QuantizationConfig用于为qmatmul()等算子指定量化参数Module.load_state_dict()新增strict参数默认strictTrue时若state_dict含未使用键会报错strictFalse时忽略多余键。这帮助模型开发者快速定位模型中缺失的实现。masked_scatter 的破坏性变更ops.masked_scatter()现在必须显式命名out_dim因为它依赖数据data-dependent。示例ops.masked_scatter( inputs_embeds, video_mask, video_embeds, out_dimunmasked_inputs )KVCache 策略调整与其它移除项弃用CONTINUOUSKVCache 策略KVCacheStrategy统一改用PAGED策略——这也解释了上文 GGUF 量化模型支持 paged KVCache 的联动移除LLM构造函数的Settings参数服务端改为后台自动配置不再占用 HTTP 端口移除Graph.unique_symbolic_dim()移除max_to_torch_type()/torch_to_max_type()替换为DType.to_torch()/DType.from_torch()与 NumPy 对应方法对齐从InferenceSession移除stats_report属性与reset_stats_report方法原主要用于内部 PyTorch 调试移除朴素 KVCachenn.kv_cache.naive_cache以及nn.attention、nn.naive_attention_with_ropeops.select重命名为ops.where与 torch、numpy 的同名算子保持一致。Mojo APILayoutTensor 与旧 API 移除LayoutTensor 新增 size 方法Mojo 侧最实用的增量是LayoutTensor新增size方法用于获取张量元素总数避免了手动计算各维度乘积的繁琐写法。移除 max.driver / max.graph / max.engine / max.tensor延续 v25.3 对 Mojomax.driver、max.graph、max.engineAPI 的弃用本版本将它们从包与 API 文档中正式移除同时移除 Mojomax.tensorAPI含Tensor、TensorShape、TensorSpec。官方迁移建议用LayoutTensor替代原有Tensor相关用法。自定义算子PyTorch 调用 Mojo 内核CustomOpLibrary这是 v25.4 与Python 调用 Mojo亮点直接相关的核心能力。本版本新增max.torch模块与CustomOpLibrary类用于在 PyTorch 中调用 Mojo 编写的自定义内核。仓库内的完整示例位于 max/examples/pytorch_custom_ops从最基本的 hello world 到替换完整模型中的某个层都有覆盖。Mojo 侧注册自定义算子以官方发布说明中的grayscale灰度转换算子为例用 Mojo 编写并注册register(grayscale) struct Grayscale: staticmethod fn execute # The kind of device this is running on: cpu or gpu target: StaticString, raises: ...仓库内的真实实现 operations/grayscale.mojo 展示了完整的实现细节通过extensibility.register(grayscale)注册execute接受target: StaticString编译期参数cpu 或 gpu并在内核中使用标准的感知加权灰度公式gray 0.21*r 0.71*g 0.07*b权重基于人眼感知特性最终通过foreach[color_to_grayscale, targettarget, simd_width1]并行执行。Python 侧加载并调用在 PyTorch 中加载编译好的 Mojo 自定义算子包并配合torch.compile使用from max.torch import CustomOpLibrary op_library CustomOpLibrary(path/to/custom.mojopkg) torch.compile(backendbackend) def grayscale(pic): result pic.new_empty(pic.shape[:-1]) op_library.grayscale(result, pic) return result img (torch.rand(64, 64, 3) * 255).to(torch.uint8) result grayscale(img)需要说明的是仓库当前版本的示例 grayscale.py 使用from max.experimental.torch import CustomOpLibrary导入路径该能力在后续迭代中一度位于max.experimental.torch并以Path(__file__).parent / operations目录直接加载 Mojo 源内核实际使用时请以当前仓库代码与对应版本文档为准。自定义算子的其它变更错误信息改进当自定义算子参数被赋予类型不匹配的值时报错信息更清晰ops.custom()强制device参数现在必须显式指定算子执行设备如 CPU/GPU避免自定义算子自行推断执行设备——这种推断容易出错。GPU 编程支持v25.4 在 GPU 编程层面完成了两件大事AMD CDNA3 数据中心 GPU 完整支持具体为 MI300X 与 MI325X可使用与 NVIDIA 完全一致的代码路径AMD RDNA3 消费级 GPU 初始支持已为 AMD Radeon 780m 集成 GPU 指定基础调优参数。注意RDNA3 支持仅限 GPU 编程层面AI 模型推理在该架构上仍缺少部分 GPU 内核。结合本版本同时开放的内核贡献通道AMD 相关缺失内核的补齐正是社区贡献的重点方向之一详见 max/kernels/CONTRIBUTING.md。文档与教程生态v25.4 同步更新了文档体系builds.modular.com与max.modular.com统一了顶部导航栏以方便检索。新增内容围绕GPU 编程教学与AI 辅助开发两条主线GPU Puzzles新增 1D 卷积、softmax、attention、embedding、内核融合、自定义反向传播、GPU 函数式编程模式、warp 基础等谜题AI 编码助手使用指南讲解如何用 LLM 与编码助手如 Cursor、Claude Code加速 Modular 开发MLP block 图模块教程在 MAX 图中创建可复用Module组件PyTorch 自定义算子教程Beta用 Mojo 为 PyTorch 模型编写高性能 GPU 内核——对应能力正是上文介绍的CustomOpLibrary内核性能剖析在 NVIDIA GPU 上使用 Nsight Compute 剖析 Mojo 内核。重大更新方面GPU 自定义算子教程补充了 CPU/GPU 硬件特定函数写法矩阵乘自定义算子优化教程由 Recipe 迁移为完整修订版教程帮助提升 GPU 自定义算子性能。总结MAX v25.4 是一个平台化里程碑AMD MI300X/MI325X 的官方支持打破了 GenAI 部署对单一 GPU 厂商的依赖Python 调用 Mojo 的预览与CustomOpLibrary打通了 PyTorch 生态与 Mojo 高性能内核之间的壁垒子图 API 的落地则为大规模模型编译性能提供了新的优化维度。对于希望评估 MAX 平台、向 AMD GPU 迁移部署、或以 Mojo 编写 PyTorch 自定义算子的开发者而言v25.4 是值得深入研究与上手实践的版本。文中涉及的采样配置、子图与自定义算子实现均可直接在本仓库对应源码与示例目录中进一步查阅。【免费下载链接】mojoThe Modular Platform (includes MAX Mojo)项目地址: https://gitcode.com/GitHub_Trending/mo/mojo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 MAX v25.4 发布深度解读：AMD GPU 正式支持、Python 调用 Mojo 与自定义算子生态升级
MAX v25.4 发布深度解读AMD GPU 正式支持、Python 调用 Mojo 与自定义算子生态升级【免费下载链接】mojoThe Modular Platform (includes MAX Mojo)项目地址: https://gitcode.com/GitHub_Trending/mo/mojo本文基于仓库内官方发布说明 docs/releases/v25.4.md 编写并结合当前仓库源码对推理服务、Python/Mojo API 与自定义算子等核心变更进行纵深解析。读者将掌握 v25.4 版本在 AMD GPU 支持、采样配置、子图 API、PyTorch 自定义算子CustomOpLibrary等方面的具体用法与底层实现脉络。版本概览与核心亮点MAX v25.42025-06-18 发布是本项目发展历程中的一个标志性版本AMD 数据中心 GPU 获得官方支持GenAI 部署首次可以在 NVIDIA 与 AMD 平台上使用同一套代码与容器运行同时开放了 CPU/GPU 内核的社区贡献通道并首次预览Python 调用 Mojo的互操作能力。以下是本版本三大核心亮点AMD GPU 官方支持可使用与 NVIDIA GPU 完全相同的代码和容器在 AMD MI300X、MI325X 上加速部署 MAX。这是可移植、高性能 GenAI 部署的关键一步——无需供应商锁定也无需针对特定平台做专门优化。接受 GPU 内核贡献上个月开源了驱动 MAX 框架的 CPU/GPU 内核代码后本版本正式开放内核贡献通道具体贡献指南见仓库内 max/kernels/CONTRIBUTING.md。预览Python 调用 MojoPython-to-Mojo 互操作 API只需将性能关键部分用 Mojo 编写即可像导入普通 Python 库一样从 Python 调用。Python API 侧新增max.mojo.importer模块作为承载。新增模型架构MAX modelsv25.4 为 MAX 推理框架新增了四个模型架构对应架构目录均可在当前仓库的 max/python/max/pipelines/architectures 下找到模型架构目录状态OLMo 2architectures/olmo2正式支持Google Gemma 3 多模态architectures/gemma3multimodal正式支持Qwen 3architectures/qwen3正式支持InternVL3architectures/internvl仍为进行中Work in Progress此外GGUF 量化 LLaMA 系列q4_0、q4_k、q6_k现在支持配合 paged KVCache 策略使用。这与本版本同时推进的 KVCache 策略调整方向一致见下文CONTINUOUS 策略弃用。MAX 推理服务器更新Inference serverInflight batching 不再要求 chunked prefillv25.4 之前max serve的 inflight batching动态批处理依赖 chunked prefill 机制本版本解除了这一耦合使动态批处理在预填充阶段拥有更高的调度灵活性有利于降低首 token 延迟与显存峰值。采样逻辑扩展与 per-request 采样配置本版本显著扩展了 token 采样逻辑新增并完善了以下采样超参数的支持top_k、min_p、min_new_tokens、temperature。更重要的是采样配置被扩展为 per-request按请求独立配置——不同的并发请求可以携带各自不同的采样超参数而不是沿用服务端的全局默认值。从当前仓库源码可以印证这一设计在底层图执行层面的落地max/python/max/pipelines/sampling/sampling.py 中采样图的输入类型明确按[batch]维度定义了 per-batch 的top_k、top_p、temperature、min_p、seed张量并包含max_k、min_top_p等标量输入sampling_config.py 中的SamplingConfig则集中管理采样阶段的可配置项包括in_dtype/out_dtype输入 token 与输出 logits 的数据类型默认float32enable_penalties是否应用 frequency / presence / repetition 惩罚enable_min_tokens是否启用min_tokens/min_new_tokens在达到计数前阻止模型输出停止 tokenenable_variable_logits允许采样图接收不同长度序列组成的 ragged 张量配合logit_offsets为 echo 与投机解码speculative decoding产生额外 logitssample_on_host是否在主机 CPU 上执行采样将 last-token logits 从设备拷回主机再做 top-k/argmax默认在模型设备上采样。这些字段共同构成了 v25.4 所宣布的扩展采样逻辑 per-request 配置的完整实现骨架。移除 TorchScript 与 torch MLIR 模型支持本版本正式移除了对 TorchScript 与 torch MLIR 模型的支持意味着模型导入路径全面向原生 MAX 图graph与自定义算子方案收敛。max CLI 新参数v25.4 为max命令行工具新增两个实用参数max generate --use-subgraphs允许在模型中使用子图subgraph。子图是图的函数——将重复出现的计算块例如 Transformer 层定义一次再在父图中多次调用编译器只需处理一次定义。从当前仓库源码 max/python/max/graph/graph.py 的Graph.add_subgraph()注释看对于如 Transformer 层重复数十次的模型子图化可将编译时间削减 50 倍以上代价是子图内外的内存分配无法共享峰值内存略升且编译器无法跨子图边界做算子融合。该参数已在 DeepSeek 系列架构中实际启用例如 architectures/deepseekV2/distributed_deepseekV2.py 与 architectures/deepseekV3/deepseekV3.py 均通过use_subgraphs控制。max serve --port为max serve指定监听端口号便于在容器化或多实例部署时显式管理端口。Python API 更新v25.4 的 Python API 变动是历次版本中较大的一次既有大量新增能力也包含一批破坏性移除。子图 API 落地add_subgraph / build_subgraph / call / fold本版本正式为图编程补齐了子图这一关键抽象四组新 API 协同工作Graph.add_subgraph()向当前图添加一个可复用子图。从源码 graph.py 可见其完整签名add_subgraph(name, forwardNone, input_types(), pathNone, custom_extensions[], devices[], is_device_graphFalse)返回子图对象。典型用法是在with graph.add_subgraph(add_one, input_types[input_type]) as sub:中定义子图计算再用ops.call(sub, ...)调用。Module.build_subgraph()为继承自Module的层创建子图。相比直接调用add_subgraph它自动处理权重前缀weight prefix问题因此对Module模型更友好参见 max/python/max/nn/layer/layer.py。ops.call执行一个子图。源码注释max/python/max/graph/ops/call.py明确指出其核心收益编译器只需处理一次子图定义可显著缩短编译时间。ops.fold将滑动块sliding blocks合并为更大的张量服务于窗口类注意力等需要重组张量的场景。max.nn 包与量化、加载相关 APImax.nn包新增大量 APIGraph构造函数新增KernelLibrary参数类型新增QuantizationConfig用于为qmatmul()等算子指定量化参数Module.load_state_dict()新增strict参数默认strictTrue时若state_dict含未使用键会报错strictFalse时忽略多余键。这帮助模型开发者快速定位模型中缺失的实现。masked_scatter 的破坏性变更ops.masked_scatter()现在必须显式命名out_dim因为它依赖数据data-dependent。示例ops.masked_scatter( inputs_embeds, video_mask, video_embeds, out_dimunmasked_inputs )KVCache 策略调整与其它移除项弃用CONTINUOUSKVCache 策略KVCacheStrategy统一改用PAGED策略——这也解释了上文 GGUF 量化模型支持 paged KVCache 的联动移除LLM构造函数的Settings参数服务端改为后台自动配置不再占用 HTTP 端口移除Graph.unique_symbolic_dim()移除max_to_torch_type()/torch_to_max_type()替换为DType.to_torch()/DType.from_torch()与 NumPy 对应方法对齐从InferenceSession移除stats_report属性与reset_stats_report方法原主要用于内部 PyTorch 调试移除朴素 KVCachenn.kv_cache.naive_cache以及nn.attention、nn.naive_attention_with_ropeops.select重命名为ops.where与 torch、numpy 的同名算子保持一致。Mojo APILayoutTensor 与旧 API 移除LayoutTensor 新增 size 方法Mojo 侧最实用的增量是LayoutTensor新增size方法用于获取张量元素总数避免了手动计算各维度乘积的繁琐写法。移除 max.driver / max.graph / max.engine / max.tensor延续 v25.3 对 Mojomax.driver、max.graph、max.engineAPI 的弃用本版本将它们从包与 API 文档中正式移除同时移除 Mojomax.tensorAPI含Tensor、TensorShape、TensorSpec。官方迁移建议用LayoutTensor替代原有Tensor相关用法。自定义算子PyTorch 调用 Mojo 内核CustomOpLibrary这是 v25.4 与Python 调用 Mojo亮点直接相关的核心能力。本版本新增max.torch模块与CustomOpLibrary类用于在 PyTorch 中调用 Mojo 编写的自定义内核。仓库内的完整示例位于 max/examples/pytorch_custom_ops从最基本的 hello world 到替换完整模型中的某个层都有覆盖。Mojo 侧注册自定义算子以官方发布说明中的grayscale灰度转换算子为例用 Mojo 编写并注册register(grayscale) struct Grayscale: staticmethod fn execute # The kind of device this is running on: cpu or gpu target: StaticString, raises: ...仓库内的真实实现 operations/grayscale.mojo 展示了完整的实现细节通过extensibility.register(grayscale)注册execute接受target: StaticString编译期参数cpu 或 gpu并在内核中使用标准的感知加权灰度公式gray 0.21*r 0.71*g 0.07*b权重基于人眼感知特性最终通过foreach[color_to_grayscale, targettarget, simd_width1]并行执行。Python 侧加载并调用在 PyTorch 中加载编译好的 Mojo 自定义算子包并配合torch.compile使用from max.torch import CustomOpLibrary op_library CustomOpLibrary(path/to/custom.mojopkg) torch.compile(backendbackend) def grayscale(pic): result pic.new_empty(pic.shape[:-1]) op_library.grayscale(result, pic) return result img (torch.rand(64, 64, 3) * 255).to(torch.uint8) result grayscale(img)需要说明的是仓库当前版本的示例 grayscale.py 使用from max.experimental.torch import CustomOpLibrary导入路径该能力在后续迭代中一度位于max.experimental.torch并以Path(__file__).parent / operations目录直接加载 Mojo 源内核实际使用时请以当前仓库代码与对应版本文档为准。自定义算子的其它变更错误信息改进当自定义算子参数被赋予类型不匹配的值时报错信息更清晰ops.custom()强制device参数现在必须显式指定算子执行设备如 CPU/GPU避免自定义算子自行推断执行设备——这种推断容易出错。GPU 编程支持v25.4 在 GPU 编程层面完成了两件大事AMD CDNA3 数据中心 GPU 完整支持具体为 MI300X 与 MI325X可使用与 NVIDIA 完全一致的代码路径AMD RDNA3 消费级 GPU 初始支持已为 AMD Radeon 780m 集成 GPU 指定基础调优参数。注意RDNA3 支持仅限 GPU 编程层面AI 模型推理在该架构上仍缺少部分 GPU 内核。结合本版本同时开放的内核贡献通道AMD 相关缺失内核的补齐正是社区贡献的重点方向之一详见 max/kernels/CONTRIBUTING.md。文档与教程生态v25.4 同步更新了文档体系builds.modular.com与max.modular.com统一了顶部导航栏以方便检索。新增内容围绕GPU 编程教学与AI 辅助开发两条主线GPU Puzzles新增 1D 卷积、softmax、attention、embedding、内核融合、自定义反向传播、GPU 函数式编程模式、warp 基础等谜题AI 编码助手使用指南讲解如何用 LLM 与编码助手如 Cursor、Claude Code加速 Modular 开发MLP block 图模块教程在 MAX 图中创建可复用Module组件PyTorch 自定义算子教程Beta用 Mojo 为 PyTorch 模型编写高性能 GPU 内核——对应能力正是上文介绍的CustomOpLibrary内核性能剖析在 NVIDIA GPU 上使用 Nsight Compute 剖析 Mojo 内核。重大更新方面GPU 自定义算子教程补充了 CPU/GPU 硬件特定函数写法矩阵乘自定义算子优化教程由 Recipe 迁移为完整修订版教程帮助提升 GPU 自定义算子性能。总结MAX v25.4 是一个平台化里程碑AMD MI300X/MI325X 的官方支持打破了 GenAI 部署对单一 GPU 厂商的依赖Python 调用 Mojo 的预览与CustomOpLibrary打通了 PyTorch 生态与 Mojo 高性能内核之间的壁垒子图 API 的落地则为大规模模型编译性能提供了新的优化维度。对于希望评估 MAX 平台、向 AMD GPU 迁移部署、或以 Mojo 编写 PyTorch 自定义算子的开发者而言v25.4 是值得深入研究与上手实践的版本。文中涉及的采样配置、子图与自定义算子实现均可直接在本仓库对应源码与示例目录中进一步查阅。【免费下载链接】mojoThe Modular Platform (includes MAX Mojo)项目地址: https://gitcode.com/GitHub_Trending/mo/mojo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考