Qwen3.8-Max与Kimi K3都面向Coding、知识工作、多模态和长程Agent也都公布了万亿级总参数和约1M Token上下文窗口。截至2026年8月5日两款模型都可通过API开展业务验证但可用于自托管评估的公开材料处于不同阶段。阿里云百炼当前已经列出模型ID qwen3.8-max并提供多地域API接入与计费信息。官方发布信息显示该模型采用MoE架构总参数约2.4万亿单Token激活参数约950亿截至本文核验时Qwen官方Hugging Face组织页尚未检索到对应正式权重仓库。Kimi K3已经发布API、完整权重、技术报告和许可证。官方模型卡给出的规模为2.8万亿总参数、1040亿激活参数使用KDA与Gated MLA注意力结构原生采用MXFP4权重和MXFP8激活并给出vLLM、SGLang和TokenSpeed部署入口。因此本文比较的是当前部署准备度与验证方法不是未经统一环境复现的模型性能排名。1. 当前技术状态维度Qwen3.8-MaxKimi K3架构MoEMoE总参数约2.4T2.8T激活参数约95B104B上下文窗口标称1M1,048,576 TokenAPI已上线qwen3.8-max已上线kimi-k3权重截至8月5日官方Hugging Face组织页未检索到正式仓库已开放原生精度待正式模型卡MXFP4权重 / MXFP8激活自托管引擎待正式权重与引擎适配vLLM / SGLang / TokenSpeedLicense待正式仓库Kimi K3 License2. MoE参数如何进入资源规划MoE通过路由器为每个Token选择部分专家。总参数体现完整模型规模激活参数可近似反映当前Token路由后参与计算的参数规模是资源规划的重要参考但不能直接等同于实际FLOPs、显存占用或吞吐。从部署角度可以把资源拆成以下部分模型运行资源 权重驻留 量化元数据 运行时与算子工作区 通信缓冲区 KV Cache 多模态模块 安全余量。完整权重集合仍需分布在集群可访问的GPU显存、主机内存或其他层级中常用权重的驻留、分片与卸载策略由推理引擎和并行方案决定。原始权重字节量可用“总参数量×平均有效位宽÷8”做数量级估算。模型文件还可能包含共享缩放因子、非量化张量和分片元数据运行时、通信工作区和长上下文会继续增加资源。因此该结果只是存储估算入口GPU数量仍由目标环境测试确定。3. 权重与精度Kimi K3Kimi K3从SFT阶段开始采用量化感知训练官方配置为MXFP4权重、MXFP8激活。MXFP4不等同于通用INT4实际文件也不能简单按每参数0.5字节计算指定GPU上的运行效率需要由框架算子、驱动和硬件共同验证。Kimi K3采用自定义许可证部分MaaS和大规模商业产品存在额外条件。企业应根据实际使用方式核对官方原文必要时完成内部合规确认。在实际项目中应检查官方权重分片及总文件体积加载时CPU内存和GPU显存峰值是否出现算子或精度回退多节点分发和重启时间目标GPU是否在官方或厂商适配范围内。Qwen3.8-MaxAPI能力不代表开放权重版本的文件和精度已经确定。截至2026年8月5日Qwen官方Hugging Face组织页尚未检索到Qwen3.8-Max正式仓库许可证、权重格式、量化版本、模型配置和文件体积仍以正式模型卡与仓库为准。在正式权重发布前不应根据总参数或API表现推算文件体积、精度格式及GPU卡数这些结论应在权重分片、目标引擎和目标硬件明确后验证。4. 推理框架验证Kimi K3官方给出vLLM、SGLang和TokenSpeed部署入口。选择引擎时应从“能够启动”继续扩展到以下检查模型能否在锁定版本的镜像中稳定加载文本、图像及项目所需输入是否完整支持reasoning_content能否正确返回和保留Tool Calling和结构化输出是否稳定专家并行、张量并行与流水线并行是否适配目标拓扑长上下文和高并发下是否发生OOM、超时或吞吐突降升级框架后输出协议和模型行为是否发生变化。Qwen3.8-Max开放权重后需要对Transformers、vLLM、SGLang及厂商推理引擎执行同样流程。稳定加载、功能完整性、连续运行和故障恢复共同构成生产适配依据。5. 单机与多节点拓扑超大MoE的通信特征与Dense模型不同。除了张量并行和流水线并行专家并行可能引入更明显的跨GPU或跨节点通信。规划时至少需要回答每个节点放置哪些层或专家节点内GPU通过何种互连通信节点间是否具备RDMA能力RDMA采用InfiniBand还是基于以太网的RoCE以何种带宽和拓扑运行通信库、网卡、交换机与GPU拓扑是否匹配单请求时延和总吞吐哪个优先发生单节点故障后如何恢复。GPU总显存用于初步判断权重与运行空间是否具备装载条件吞吐、尾延迟和扩展效率还需结合互连、网络、引擎与并行方式测试。6. 1M上下文与KV Cache两款模型都公布了约1M上下文。工程上需要区分模型或接口能力上限与业务常态并按对应渠道文档确认输入、输出和多轮内容的计入方式。建议先统计真实业务中常用值、P95和最大上下文再按并发逐档测试。需要记录的指标包括TTFT P50、P95和P99单请求输出Token/s系统总输出Token/s及成功请求/sGPU显存与运行时KV Cache占用请求成功率和超时Prompt/Context Cache命中Token与计费影响压缩或截断次数多轮Agent的上下文增长速度。在Kimi兼容API的多轮工具调用流程中客户端应按官方接口文档保留所需的assistant message与tool_calls如启用思考字段还要按对应模型和接口要求处理reasoning_content。自托管时应验证引擎是否保留等价字段与消息语义。Qwen3.8-Max API的消息结构和思考参数以当前接入渠道文档为准。这些差异会影响Token、上下文和时延Agent服务层需要分别适配。7. Coding Agent为什么需要更多基础设施Coding Agent会同时进行模型推理、代码检索、文件读写、终端执行、依赖安装、测试和工具调用。完整服务通常需要GPU推理节点高核心数CPU与大容量内存高速本地NVMe、共享存储或对象存储Git服务、代码索引和依赖缓存容器、虚拟机或安全沙箱数据库、向量库和工具网关任务队列、超时、重试与人工接管日志、Tracing、指标监控和审计。因此Coding Agent的容量规划需要同步覆盖GPU推理以及CPU、内存、NVMe、沙箱和工具服务避免工作流受代码检索、容器启动、测试执行或工具并发限制。8. 企业PoC的四阶段参考流程阶段一建立任务与验收基线选择覆盖核心场景的代表性任务明确完成率、测试通过率、工具调用成功率、人工接管、结果可追溯性和安全边界。任务数量应按场景复杂度调整例如可从20—50个代表性任务起步但不作为固定门槛。阶段二开展API业务验证两款模型使用相同任务、提示与工具条件记录质量、TTFT、总耗时、Token消耗和单任务成本。该阶段先回答“模型是否适合业务”不据此推算私有化GPU数量。阶段三验证部署与完整Agent链路对已开放权重的版本依次核对许可证、权重分片、精度和引擎版本再验证加载、上下文与并发矩阵、工具调用、连续运行和故障恢复同时把CPU、NVMe、沙箱和工具服务纳入观测。Qwen3.8-Max在正式权重发布后补齐这一步。阶段四形成路线与容量建议结合业务效果、数据边界、负载稳定性、现有资源和可用性目标判断采用API、混合架构还是私有化。只有路线明确后才进入GPU、CPU、内存、存储、网络与冗余规划。以上是参考流程不预设固定完成周期。实际节奏取决于任务复杂度、资源准备度、权重开放状态和验收范围。建议交付物至少包括任务集与验收口径、测试环境与版本、结果记录、已验证事实、待验证项、风险边界和下一步路线。9. API与私有化如何比较API适合快速验证、波动负载和不希望维护超大集群的团队私有化适合数据边界明确、负载相对稳定、需要深度集成或控制运行环境的项目。也可以采用常规任务走API、敏感或稳定负载走本地的混合路线。比较时应使用相同业务任务并计算有效完成成本。截至2026年8月5日阿里云百炼华北2地域公开原价显示qwen3.8-max输入12元、输出36元/百万TokenKimi官方平台公开标价为缓存命中输入2元、常规输入20元、输出100元/百万Token。价格随地域和政策变化以实际接入页为准。API侧还需记录缓存、失败重试、RPM、TPM和并发限制私有化侧则包含硬件、网络、机房、电力、运维、升级和冗余。10. 当前结论截至2026年8月5日Kimi K3已经具备开展自托管可行性验证所需的权重、模型卡、部署入口和许可证Qwen3.8-Max已经具备API业务PoC条件自托管资源结论需在正式权重与模型卡发布后补齐两款模型的GPU资源模型都需要结合完整权重、精度、引擎、KV Cache、并行方式和目标SLA不能由总参数直接换算企业更稳妥的顺序是先验证真实任务再判断API、混合或私有化路线最后规划模型集群和Agent外围系统。