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-Max	Kimi K3
架构	MoE	MoE
总参数	约2.4T	2.8T
激活参数	约95B	104B
上下文窗口	标称1M	1,048,576 Token
API	已上线（qwen3.8-max）	已上线（kimi-k3）
权重	截至8月5日，官方Hugging Face组织页未检索到正式仓库	已开放
原生精度	待正式模型卡	MXFP4权重 / MXFP8激活
自托管引擎	待正式权重与引擎适配	vLLM / SGLang / TokenSpeed
License	待正式仓库	Kimi K3 License

2. MoE参数如何进入资源规划

MoE通过路由器为每个Token选择部分专家。总参数体现完整模型规模，激活参数可近似反映当前Token路由后参与计算的参数规模，是资源规划的重要参考，但不能直接等同于实际FLOPs、显存占用或吞吐。

从部署角度，可以把资源拆成以下部分：

模型运行资源 = 权重驻留 + 量化元数据 + 运行时与算子工作区 + 通信缓冲区 + KV Cache + 多模态模块 + 安全余量。

完整权重集合仍需分布在集群可访问的GPU显存、主机内存或其他层级中；常用权重的驻留、分片与卸载策略由推理引擎和并行方案决定。

原始权重字节量可用“总参数量×平均有效位宽÷8”做数量级估算。模型文件还可能包含共享缩放因子、非量化张量和分片元数据；运行时、通信工作区和长上下文会继续增加资源。因此，该结果只是存储估算入口，GPU数量仍由目标环境测试确定。

3. 权重与精度

Kimi K3

Kimi K3从SFT阶段开始采用量化感知训练，官方配置为MXFP4权重、MXFP8激活。MXFP4不等同于通用INT4，实际文件也不能简单按每参数0.5字节计算；指定GPU上的运行效率需要由框架算子、驱动和硬件共同验证。

Kimi K3采用自定义许可证，部分MaaS和大规模商业产品存在额外条件。企业应根据实际使用方式核对官方原文，必要时完成内部合规确认。

在实际项目中应检查：

• 官方权重分片及总文件体积；
• 加载时CPU内存和GPU显存峰值；
• 是否出现算子或精度回退；
• 多节点分发和重启时间；
• 目标GPU是否在官方或厂商适配范围内。

Qwen3.8-Max

API能力不代表开放权重版本的文件和精度已经确定。截至2026年8月5日，Qwen官方Hugging Face组织页尚未检索到Qwen3.8-Max正式仓库；许可证、权重格式、量化版本、模型配置和文件体积仍以正式模型卡与仓库为准。

在正式权重发布前，不应根据总参数或API表现推算文件体积、精度格式及GPU卡数；这些结论应在权重分片、目标引擎和目标硬件明确后验证。

4. 推理框架验证

Kimi K3官方给出vLLM、SGLang和TokenSpeed部署入口。选择引擎时，应从“能够启动”继续扩展到以下检查：

1. 模型能否在锁定版本的镜像中稳定加载；
2. 文本、图像及项目所需输入是否完整支持；
3. reasoning_content能否正确返回和保留；
4. Tool Calling和结构化输出是否稳定；
5. 专家并行、张量并行与流水线并行是否适配目标拓扑；
6. 长上下文和高并发下是否发生OOM、超时或吞吐突降；
7. 升级框架后输出协议和模型行为是否发生变化。

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及成功请求/s；
• GPU显存与运行时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元/百万Token；Kimi官方平台公开标价为缓存命中输入2元、常规输入20元、输出100元/百万Token。价格随地域和政策变化，以实际接入页为准。API侧还需记录缓存、失败重试、RPM、TPM和并发限制；私有化侧则包含硬件、网络、机房、电力、运维、升级和冗余。

10. 当前结论

截至2026年8月5日：

• Kimi K3已经具备开展自托管可行性验证所需的权重、模型卡、部署入口和许可证；
• Qwen3.8-Max已经具备API业务PoC条件，自托管资源结论需在正式权重与模型卡发布后补齐；
• 两款模型的GPU资源模型都需要结合完整权重、精度、引擎、KV Cache、并行方式和目标SLA，不能由总参数直接换算；
• 企业更稳妥的顺序是：先验证真实任务，再判断API、混合或私有化路线，最后规划模型集群和Agent外围系统。